Почему Google всё ещё считает сайт опасным после очистки

Если Google показывает предупреждение после очистки, сначала выясните, какой именно сигнал остался: взломанный URL, вредоносная загрузка или запись в Search Console. Проверьте весь сайт и точку входа, затем отправьте запрос на проверку в Security Issues. Повторная индексация сама по себе не снимает предупреждение и не гарантирует срок.

1. Почему предупреждение Google не исчезло после очистки

Когда владелец видит прежнюю пометку Google после чистки, первая версия обычно звучит так: «у поисковика старый кэш». Это удобное объяснение, но оно часто уводит от причины. Google отдельно показывает обнаруженные проблемы безопасности в Search Console, а изменения в поиске и предупреждения могут обновляться с задержкой. Старый результат в выдаче не доказывает, что на сервере сохранился кэш вредоносной страницы. И наоборот: отсутствие красной плашки в одном браузере не доказывает, что инцидент закрыт. Я сначала открываю проверку безопасности сайта и отчёт Security Issues, читаю тип проблемы и примеры URL, затем проверяю эти адреса снаружи. Если предупреждение видит только часть посетителей, сравниваю ответы сайта из разных сетей и для обычного браузера и Googlebot. Так обнаруживается CDN или прокси-кэш, когда он действительно отдаёт старую копию. Но кэш очищают после проверки источника и правила, иначе через минуту он заполнится тем же содержимым. Запрос на повторное сканирование страниц — отдельный инструмент обнаружения изменений; он не равен запросу на пересмотр предупреждения о безопасности.

В базе знаний есть практическое правило: после очистки отправить запрос на перепроверку сайта. Я применяю его только после того, как убедился, что изменённые страницы больше не отдают вредоносный контент и входная уязвимость закрыта. Для единичного обновлённого URL Google предлагает URL Inspection; массовую проверку таким способом не ускорить, у инструмента есть квоты, а повторные запросы не заставляют робота прийти быстрее. При большом числе адресов полезнее поддерживать карту сайта и дать Google заново обойти сайт. На это могут уйти дни или недели, и включение в результаты не гарантируется. Если устаревший контент раздаёт CDN, очищаю именно его кэш и проверяю ответ повторно. Не путайте: CDN-кэш — наша инфраструктура, индекс Google — система поисковика. Первая команда — в панели CDN, вторая — доступна через инструменты Google, но ни одна не служит волшебной кнопкой «снять бан».

• Откройте Security Issues и зафиксируйте тип проблемы и примеры URL.
• Проверьте фактический ответ этих страниц и кэш CDN.
• После устранения причины запросите нужную проверку в Search Console.

2. Как проверить файлы CMS и не оставить повторный вход

Самый надёжный путь после взлома — не искать одну подозрительную строку в тысячах файлов, а определить масштаб изменений и восстановить доверенные компоненты. Экспертная база рекомендует переустановить CMS и плагины и обновить их после удаления вредоносного кода. Это разумная отправная точка, но не универсальная команда «заменить всё»: ядро, темы, плагины и пользовательские загрузки требуют разного обращения. Для WordPress официальная памятка допускает замену каталогов wp-admin и wp-includes файлами той же версии; отдельно требует внимательно проверить wp-content и .htaccess. Простая переустановка поверх каталога может оставить добавленные злоумышленником новые файлы. Поэтому я сохраняю копию для расследования, сверяю версию и происхождение пакетов, заменяю системные файлы чистыми и отдельно проверяю каталоги расширений. Если владелец сайта не знает версию или источник файлов, сначала фиксирую состояние и уточняю это у хостинга. Слепое обновление в разгар инцидента способно добавить поломку к уже существующей проблеме.

В базе есть ещё одна полезная деталь; подробнее о очистке сайта от вредоносного кода: целостность файлов ядра WordPress можно проверять сравнением с официальным источником. Дифф помогает найти отклонения, но не ставит диагноз автоматически: локальные изменения бывают легитимными, а вредоносный файл может быть новым и потому отсутствовать в исходном наборе. Сверяю контрольные данные именно для установленной версии, проверяю владельцев и время изменения файлов, сопоставляю результат с логами и списком установленных расширений. Не оставляю пароль доступа к хостингу, CMS и базе прежним после восстановления: меняю секреты и проверяю учётные записи. Если на сайте есть резервные копии, сначала выясняю, кто и когда их создал. Архив в web-доступном каталоге — это не резервная копия, а иногда ещё один способ отдать наружу конфигурацию или старый заражённый код. Удалять архивы без проверки тоже не нужно: сначала сохраняю доказательства, потом убираю ненужные публичные копии.

• Сохраните копию для расследования и установите версии CMS и расширений.
• Сверьте системные файлы с дистрибутивом той же версии.
• Проверьте темы, плагины, учётные записи и резервные копии.

3. Чем запрос на проверку отличается от переиндексации

В интерфейсе Search Console важны два разных действия, которые исходная статья смешивала. Для предупреждения о взломе Google предлагает отчёт Security Issues и кнопку Request a review, когда сайт полностью очищен. Для повторного обхода конкретной страницы существует URL Inspection. Никакого универсального флажка «Проблема исправлена» для всех ситуаций обещать нельзя: названия и доступные действия зависят от типа сообщения и текущего интерфейса. Я открываю отчёт, выписываю категории и примеры URL, затем в заявке коротко описываю, что удалено и какую уязвимость закрыли. В качестве подтверждения полезны конкретные действия: удалены внедрённые страницы, заменён изменённый компонент, обновлено расширение, закрыта открытая точка входа. Пустое «всё исправили» не помогает проверяющему и не даёт владельцу сайта полезного журнала работ.

До отправки заявки проверяю не только главную страницу. Сверяю перечисленные Google примеры URL с реальной выдачей сервера, ищу неожиданные страницы и проверяю шаблоны, загрузки и точки входа, через которые могло вернуться внедрение. В базе знаний отдельно отмечены анализ исходного кода страниц через Search Console и обновление CMS с дополнениями после очистки; это хорошие контрольные шаги. Но утверждение, будто Google хранит отдельные «основной, мобильный и структурированный индексы» и каждый нужно вручную очистить, неверно. Google использует мобильный вариант для индексирования, но структурированные данные — не отдельный индекс. Не требуется посылать запрос на каждую версию, которой не существует как отдельного URL. Если проблема обнаружена повторно, не отправляю заявку снова с тем же текстом: изучаю новый пример и ищу незакрытый путь. Google предупреждает, что неустранённая проблема может продлить период предупреждения. По материалам Google, проверка вредоносной активности часто занимает несколько дней, а спам-взлом может занять недели.

• Сначала устраните заражение и уязвимость, затем подготовьте описание работ.
• Для предупреждения используйте Security Issues → Request a review.
• URL Inspection применяйте для запроса обхода отдельных изменённых страниц.

4. Как найти редирект, который видит только робот

Редирект в браузере не всегда виден при обычной проверке: поведение может зависеть от URL, cookie, заголовка User-Agent, реферера или состояния сессии. Но сам факт ответа 301 или 302 не доказывает взлом: такие ответы используют и обычные перенаправления сайта. Я сравниваю цепочку переходов для примеров из отчёта и для нормального URL, смотрю заголовки и тело ответа, затем проверяю правила веб-сервера, конфигурацию CMS и журналы доступа. В базе подтверждается, что cloaking означает показ разного контента разным посетителям; также есть типичный риск ошибочного WAF-правила, которое блокирует Googlebot по User-Agent. Поэтому нельзя удалять все условия для роботов наугад: сначала устанавливаю, кто именно меняет ответ и почему. Поддельный User-Agent в curl полезен как первичный тест, но он не доказывает, что запрос действительно пришёл от Googlebot. Для расследования сверяю время запросов, исходные адреса и записи веб-сервера.

Изменённый .htaccess — частая точка проверки в WordPress, что подчёркивает и официальная памятка проекта. Для Nginx смотрю активную конфигурацию и подключённые фрагменты, для Apache — файл сайта и локальные правила каталогов; точное расположение зависит от хостинга. Не вставляю случайный «чистый» конфиг из интернета: можно убрать нужную маршрутизацию или правила приложения. Проверяю неожиданные условия по User-Agent, рефереру, cookie, географии и обращениям к скриптам, затем сопоставляю с легитимным конфигом из резервной копии или системы контроля версий. Логи доступа помогают найти запросы, но не объясняют их смысл без контекста. Если ответ сервера отличается только для поискового робота, это повод проверить cloaking и настройки WAF, а не автоматически объявлять сайт заражённым. После исправления повторяю запросы с теми же условиями и убеждаюсь, что редирект не появляется снова.

• Сравните ответы с разными URL и условиями запроса.
• Проверьте активные правила Apache/Nginx и настройки WAF.
• Подтвердите исправление повторными запросами и журналами.

5. Что проверить на поддоменах и старых копиях сайта

Поддомены и старые копии сайта важны не потому, что Google автоматически считает их одной заражённой площадкой, а потому, что там могут оставаться доступные вредоносные URL, забытая CMS или уязвимый вход. Я составляю список имён из DNS, конфигураций хостинга, сертификатов и Search Console, затем отмечаю, какие из них действительно обслуживают сайт. Особое внимание — тестовым стендам и старым версиям: у них часто давно не обновлялись плагины, зато из интернета они доступны. База знаний напоминает проверять расширения сайта и обращаться к примерам URL из отчёта; это намного полезнее, чем заявлять, что один заражённый поддомен обязательно «тянет вниз весь домен». Влияние зависит от обнаруженной проблемы и конкретных адресов. Если ресурс больше не нужен, безопаснее удалить его или закрыть доступ с проверкой, что не осталось публичных файлов и DNS-записей, указывающих на забытый сервер.

robots.txt тоже не является хранилищем вредоносных директив. Ошибочное правило может помешать обходу нужных страниц, а блокировка обхода не удаляет страницу из поиска и не очищает заражение. Поэтому проверяю его отдельно от CMS и не добавляю запрет для Googlebot как способ «спрятать» инцидент. Google прямо указывает: URL, закрытый robots.txt, всё ещё может появляться в результатах, а для запрета индексации нужны другие механизмы; при активном расследовании сначала важнее устранить вредный контент и закрыть причину взлома. При аудите веб-безопасности проверяю также доступные архивы, старые виртуальные хосты, резервные файлы и ссылки на них. В условном кейсе «Горизонт-Логистик» проверка перечисленных в Search Console адресов обнаружила старую публичную копию сайта. Мы убрали доступ к ней после сохранения материалов для расследования и закрыли забытое расширение. Это правдоподобный сценарий, но не универсальное объяснение всех предупреждений.

• Сверьте примеры URL с поддоменами и старыми виртуальными хостами.
• Проверьте тестовые CMS, архивы и доступные резервные копии.
• Не прячьте заражённый URL в robots.txt: устраните причину и контент.

Частые вопросы