Очистка и восстановление сайта на WordPress после SEO-взлома

Задача:

Клиент обратился с проблемой доступа к административной панели сайта — войти в админку было невозможно. Первоначально предполагалась ошибка с паролями, однако в ходе диагностики стало ясно, что проблема значительно глубже: сайт подвергся взлому и был заражен вредоносным кодом.

Основная задача заключалась в полном удалении вредоносного кода, восстановлении корректной работы сайта и минимизации ущерба для SEO-показателей.

С чем мы столкнулись:

Этот тип атаки чаще всего называют SEO-спамом (SEO Spam) или Search Engine Poisoning, а конкретный метод реализации — инъекцией внешнего контента (Content Injection) через Gateways или Doorways.

Вот подробности того, как это работает и почему это выглядит именно так.

Хакеры взламывают сайт (обычно через уязвимости в плагинах CMS вроде WordPress) и внедряют небольшой PHP-скрипт. Этот скрипт работает как «прокси» или «шлюз»:

Динамическая генерация. На вашем сервере физически нет этих страниц, вы не найдете их ни в админке, ни в БД. Когда поисковый робот или пользователь заходит по странному URL, скрипт «на лету» запрашивает содержимое с удаленного сервера злоумышленника (в данном случае — через GitHub или другой репозиторий/сервер).

Маскировка под URL. Параметры вроде /?s=… или /?query=… или /?u= используются, чтобы заставить движок (CMS) думать, что это просто результаты внутреннего поиска или динамические страницы, которые не требуют создания физических файлов.

Цель: использовать «авторитет» вашего домена в глазах Google/Yandex, чтобы проиндексировать тысячи страниц со ссылками на нелегальные казино, поддельные товары или фишинговые сайты. Сайт используется как донор для продвижения сторонних ресурсов. Вредоносный код автоматически генерировал сотни тысяч страниц с определенными параметрами URL. Эти страницы не имеют отношения к тематике сайта заказчика, содержат нерелевантные ключевые слова (одежда, рыболовные снасти, нижнее белье и т. д.) и при этом активно индексируются поисковыми системами, полностью разрушая SEO-профиль сайта. В поисковой выдаче по запросу site:[домен] отображаются не страницы клиента, а страницы стороннего зарубежного интернет-магазина. И за короткий период (около 10 дней) было создано более 600 000 мусорных URL.

Такая ситуация классически называется Spam URL Injection (или конкретно WordPress Search Spam, так как используется параметр ?s=).

Причина заражения — полное отсутствие базовой защиты: слабые пароли, отсутствие защиты от брутфорса и уязвимостей WordPress.

Вот восстановленная последовательность действий, которая обычно применяется в подобных кейсах, чтобы не навредить пораженному сайту еще больше.

Решение:

1. Этап локализации и «заморозка»

Прежде всего были экстренно заменены все пароли доступа. Затем мы выполнили полную переустановку WordPress: удалили и заново загрузили чистые директории WordPress и плагинов, установили чистый дистрибутив WordPress и все плагины, удалили все файлы с вредоносным кодом, поставили и настроили firewall WP Cerber, обеспечивающий защиту от брутфорс- и XSS-атак, а также SQL-инъекций, запрет сканирования пользователей, выполнение php скриптов, обеспечивающий защиту полей ввода (поиск, форма обратной связи), блокировку подозрительных запросов и сканирование системных файлов, защиту скриптов администрирования.

Далее мы защитили критически важные системные файлы: .htaccess, wp-config.php, index.php и прописали правила в .htaccess:

# Отключение XML-RPC
<Files xmlrpc.php>
	Order Allow,Deny
	Deny from all
</Files>

# Защита wp-config.php
<Files wp-config.php>
	order allow,deny
	deny from all
</Files>

<Files "wp-load.php">
  Order Allow,Deny
  Deny from all
</Files>

# Запрещаем eval, base64_decode, и другие опасные функции в URL
RewriteCond %{QUERY_STRING} (eval\() [OR]
RewriteCond %{QUERY_STRING} (base64_decode\()
RewriteRule .* - [F,L]

# Блокируем debug.log
<Files debug.log>
	Order Allow,Deny
	Deny from all
</Files>

Эти команды частично резервируют работу firewall, на случай его выхода из строя

2. Ответ сервера (410 Gone vs 404 Not Found)

Чтобы поисковик навсегда забыл об этих страницах, одного robots.txt мало.

Код 410 (Gone) – в отличие от 404 («не найдено»), код 410 прямо говорит роботу: «Эти страницы удалены навсегда, не возвращайся сюда».

Это настраивается через .htaccess. Пример правила, который можно использовать:

# Блок мусорных поисковых запросов
RewriteCond %{QUERY_STRING} ^s=.*$ [NC]
RewriteRule ^(.*)$ - [R=410,L]

3. Массовое удаление из индекса (Google Search Console)

Также мы провели работу с Google Search Console: через раздел «Удаление» инициировали исключение из поисковой выдачи URL с параметром “https://домен/?s=”. Это ключевой момент: Google понимает, что все, что начинается с этого пути, нужно скрыть из выдачи на 6 месяцев. Это дает «передышку», чтобы сайт не пугал пользователей в поиске.

А после очистки выдачи добавили правило Disallow: /?s= в файл robots.txt, запрещающие повторную индексацию этих URL.

Важный нюанс

Если вы закроете страницы в robots.txt ДО того, как Google их удалит, он не сможет зайти на них и увидеть код 410/404.

Идеальная схема:

1. Настроить сервер на отдачу 410 Gone для параметра ?s=.

2. Подать запрос на «Удаление префикса» в GSC.

3. Подождать неделю, пока роботы зафиксируют исчезновение.

4. И только потом закрывать в robots.txt.

Результаты

И в итоге количество проиндексированных страниц постепенно начало снижаться, мусорные страницы стали переходить из статуса «проиндексировано» в «страница просканирована, но пока не проиндексирована»; «заблокировано в файле robots.txt»; «не найдено (404)», а общее число страниц возвращалось к нормальным значениям.

Сайт был полностью очищен, восстановлен и защищен, а его SEO-профиль со временем вернулся к исходному состоянию без дальнейших санкций со стороны поисковых систем, но с утраченными результатами SEO-продвижения.

Выводы:

Вопросы безопасности необходимо решать на старте, а не после взлома! Базовая защита сайта, сложные пароли и контроль доступа — это не опция, а обязательный минимум. Также стоит уделить внимание выбору хостинга. Регулярная профилактика и грамотная настройка безопасности помогут всем избежать потери трафика, репутации и бюджета на экстренное восстановление.