Если сайт снова работает, не пытайтесь компенсировать просадку переписыванием контента, закупкой ссылок или другими SEO-изменениями: сначала восстановите стабильную доступность страниц для поисковых роботов и проверьте их индексирование.
Четыре дня полной недоступности уже могут объяснить резкое падение видимости. Google рассматривает ошибки 5xx как временную проблему и сначала сокращает частоту обхода, но если такие ответы сохраняются несколько дней, ранее проиндексированные URL могут начать выпадать из индекса. Google отдельно рекомендует использовать 503 только для кратковременной остановки сайта примерно на 1–2 дня.
У Яндекса механизм отличается в деталях, но практическое последствие похожее: страницы, от которых робот получает 4xx или 5xx вместо 200 OK, могут перестать участвовать в поиске. В Вебмастере Яндекс прямо рекомендует при резком падении позиций проверять историю обхода и коды ответа проблемных URL.
Первое, что нужно выяснить, — что именно сервер отдавал поисковым роботам во время аварии. Недостаточно знать, что сайт «не открывался». Посмотрите серверные логи и статистику обхода в Google Search Console и Яндекс Вебмастере.
Сценарии принципиально различаются:
- 500, 502 или 503 означают серверную ошибку. Поисковик понимает, что проблема может быть временной, но при длительной недоступности начинает сокращать обход и может исключать URL из поиска;
- 404 или 410 сообщают, что страницы не существуют;
- 403 означает запрет доступа;
- редирект на страницу хостинга или другой URL заставляет робота обрабатывать уже другую схему;
- 200 OK со страницей ошибки тоже плохой вариант: Google может определить такую страницу как soft 404 либо обработать полученный вместо товара или категории контент.
После восстановления хостинга проверьте не только главную страницу. Возьмите выборку из главной, основных категорий, карточек товаров и страниц, которые до сбоя получали поисковый трафик. Все рабочие URL должны стабильно возвращать 200 OK и тот же контент, который был доступен до аварии.
Одновременно проверьте:
- не появился ли
noindex; - не изменился ли
canonical; - доступны ли
robots.txtи sitemap; - не возникли ли ошибочные редиректы;
- не блокирует ли CDN, WAF или система защиты Googlebot и YandexBot;
- корректно ли работает HTTPS;
- нет ли периодических 5xx и таймаутов после формального восстановления сайта.
Особенно важно проверить именно стабильность. Если страница один раз отвечает 200, а часть последующих запросов получает 502 или 503, поисковые роботы продолжат видеть сайт как проблемный.
После этого имеет смысл ускорить повторное обнаружение восстановленных страниц. В Google Search Console проверьте через инспекцию URL несколько наиболее важных страниц и запросите индексирование там, где это требуется. Sitemap должен быть доступен и содержать актуальные канонические URL.
В Яндекс Вебмастере проверьте «Статистику обхода», «Страницы в поиске» и отправьте основные выпавшие страницы на переобход. Яндекс указывает, что после устранения проблемы и восстановления ответа 200 OK возвращение страницы в поиск может занять до двух недель, но это срок обработки страницы, а не обещание возврата прежних позиций.
Не стоит одновременно массово менять Title, тексты, структуру URL, перелинковку и другие элементы страниц. Если причиной просадки действительно была недоступность, такие изменения не ускорят восстановление, зато станет значительно сложнее определить, что происходит после повторного обхода.
Дальше отслеживайте три вещи отдельно: обход, индексирование и позиции. Сначала робот должен снова нормально получать страницы, затем поисковая система должна обработать их и вернуть в индекс. Только после этого имеет смысл оценивать восстановление видимости.
Фиксированного срока возврата прежних позиций нет. Даже возвращение URL в индекс не означает автоматического восстановления ровно на тех же местах, где они находились до аварии.
Если страницы уже повторно обошлись, стабильно возвращают 200 OK, находятся в индексе, но массовая потеря позиций сохраняется, тогда простой хостинга перестает быть достаточным объяснением. Нужно отдельно проверять совпадение даты падения с изменениями поисковой выдачи, технические изменения на сайте, каноникализацию, внутреннюю перелинковку, взлом или другие события, произошедшие одновременно со сбоем.
На будущее для плановых кратких остановок Google рекомендует возвращать 503 Service Unavailable, желательно с Retry-After, а не 404, 403, noindex или полное закрытие сайта через robots.txt. Если предполагается недоступность дольше одного-двух дней, лучше сохранить доступную статическую версию важных страниц, чем полностью отключать сайт.