У сайта случился сбой. CMS не отвечает, база лежит, каталог временно пустой или разработчики выкатывают обновление. В этот момент SEO обычно вспоминают последним: главное же сначала поднять сайт.
Но именно в такие часы поисковый робот может прийти на важные страницы и увидеть совсем не то, что должен. И если сервер начинает раздавать неправильные HTTP-коды, техническая авария превращается еще и в проблему с индексированием.
Я бы поэтому добавил реакцию поисковых роботов в обычный аварийный чек-лист сайта. Настраивается это один раз, а однажды может сэкономить много неприятной работы.
Что Яндекс делает с ответами сервера
Логика довольно прямолинейная. Когда робот приходит на URL, сервер сообщает ему не только содержимое страницы, но и HTTP-код ответа.
200 OK означает: страница доступна, ее можно обходить и обрабатывать. 3xx отправляет робота на другой адрес. А ответы 4xx и 5xx говорят, что с URL что-то не так.
В документации Яндекса есть важная деталь: страницы с 4xx и 5xx не включаются в поиск, а если страница уже была известна поиску, после очередного обхода она может быть удалена из него. Для временных проблем Яндекс отдельно советует использовать код 429.
Вот здесь и появляется практическая разница между нормальной аварийной настройкой и ситуацией, когда сервер просто отвечает чем придется.
Самая неприятная ошибка: отдавать 200 на страницу-заглушку
Представим интернет-магазин. База товаров временно недоступна, но веб-сервер продолжает отвечать. Вместо карточки товара он показывает посетителю сообщение вроде «Ведутся технические работы» и при этом возвращает 200 OK.
Для человека все понятно. Для робота это полноценная доступная страница.
В результате поисковик получает URL товара с совершенно другим содержимым. Если такое происходит массово, робот видит сотни или тысячи одинаковых заглушек вместо реальных страниц.
Это тот случай, когда внешне сайт вроде бы работает, а технически для поиска ситуация плохая. Поэтому во время аварии мало показать красивую страницу обслуживания. Важно проверить, какой HTTP-код реально получает робот.
Почему 404 во время сбоя еще хуже
404 означает, что страницы по этому адресу нет. Это правильный ответ для действительно удаленного URL, но очень плохой ответ для временно недоступной карточки товара, категории или статьи.
Я иногда встречаю схему, когда при ошибке приложения сервер отправляет пользователя на шаблон «Страница не найдена». Разработчику кажется, что это аккуратнее белого экрана. С точки зрения SEO мы только что сообщили поисковой системе, что существующая страница исчезла.
Если проблема затронула большой раздел, последствия могут быть заметны уже не на одном URL. Особенно неприятно, если робот активно обходит сайт именно в этот период.
Поэтому 404 и 410 должны оставаться кодами отсутствующих страниц, а не универсальным способом обработки любой ошибки.
А что с 500 и 503
Ответы 5xx честнее: они говорят, что проблема на стороне сервера. Но рассчитывать на то, что поисковик будет бесконечно хранить такие URL в прежнем состоянии, не стоит.
В актуальной документации Яндекс объединяет 4xx и 5xx в группу ответов, при которых страница не включается в поиск. Для ситуации, когда CMS временно работает неправильно и нужно не дать странице выпасть из поиска, Яндекс отдельно указывает на 429.
Это важный момент, потому что привычная рекомендация из общей веб-практики часто звучит как «на техработах отдавайте 503». Для Яндекса я бы не переносил ее механически. Если задача именно в сохранении уже известных страниц во время временной проблемы, ориентироваться стоит на текущую документацию самого Яндекса.
Зачем здесь 429
Код 429 обычно знаком разработчикам как Too Many Requests: сервер просит клиента снизить частоту запросов. Яндекс описывает его и как вариант на случай временных проблем с CMS.
Практический смысл понятен. Мы не говорим роботу, что URL удален. Мы сообщаем, что сейчас серверу тяжело и страницу лучше проверить позже.
Но превращать 429 в постоянный режим нельзя. Яндекс прямо предупреждает: если сайт долго отвечает этим кодом, это выглядит как постоянная проблема с нагрузкой и может привести к снижению скорости обхода.
То есть 429 — аварийный инструмент, а не способ спрятать хронически медленный сервер.
Что я бы настроил заранее
1. Отдельный режим обслуживания
У сайта должен быть понятный технический режим на случай обновлений и аварий. Не плагин, который просто рисует заглушку поверх сайта, а предсказуемое поведение сервера.
Нужно заранее знать, какой код получат обычный посетитель и поисковый робот, если приложение или база данных недоступны.
2. Не подменять ошибку успешным ответом
Если страница фактически не сформирована, не стоит маскировать проблему кодом 200. Особенно это касается каталогов, карточек товаров и посадочных страниц, где при сбое может исчезнуть основное содержимое.
Пустая карточка с 200 выглядит для мониторинга лучше, чем ошибка, но для поискового робота это может быть ложным сигналом, что сама страница изменилась.
3. Следить не только за главной
Обычный uptime-монитор часто проверяет один URL. Главная при этом может прекрасно открываться из кеша, пока карточки товаров возвращают ошибки.
Я бы контролировал хотя бы несколько типов страниц: главную, категорию, карточку товара или услуги, информационную страницу и один URL, который зависит от базы данных.
4. Проверять ответ именно для робота
После аварии полезно открыть в Яндекс Вебмастере проверку ответа сервера. Это снимает часть догадок: видно, доступна ли страница роботу и какой ответ он получает.
Если сайт использует CDN, WAF или агрессивную защиту от ботов, такая проверка особенно важна. Для владельца страница может открываться нормально, а робот получать блокировку.
Что делать сразу после восстановления
Первое — не бежать отправлять весь сайт на переобход. Сначала надо убедиться, что проблема действительно закончилась.
Я бы проверил несколько ключевых URL разных типов и посмотрел их HTTP-коды. Затем — robots.txt, доступность Sitemap и отсутствие случайного noindex, если во время работ менялись шаблоны или настройки окружения.
После этого стоит открыть статистику обхода в Вебмастере. Яндекс показывает страницы, которые робот посещал, и коды ответа сервера; данные обновляются ежедневно. Так можно понять, успел ли робот попасть на сайт в неудачный момент и насколько массовой была проблема.
Если пострадали конкретные важные страницы, их можно отправить на переобход. Инструмент для этого как раз предназначен для новых и обновленных URL. Но бессмысленно отправлять страницу, пока она все еще отвечает ошибкой.
Нужно ли паниковать из-за нескольких ошибок
Нет. Сам факт, что в статистике обхода появились отдельные 5xx, еще не означает катастрофу. Серверы иногда ошибаются, сеть тоже не идеальна.
Я бы смотрел на три вещи: сколько URL затронуто, сколько времени продолжалась проблема и какие именно страницы попали под нее.
Одно дело — робот один раз не получил второстепенную страницу. Другое — несколько часов весь каталог отвечал неправильным кодом. Реакция должна быть пропорциональна масштабу.
Отдельно про скорость обхода
Иногда после нагрузки хочется вручную задушить робота через настройку скорости обхода. Яндекс позволяет ее уменьшить, но сначала рекомендует разобраться, какие страницы робот запрашивает чаще всего.
Это разумный порядок. Если робот тратит запросы на служебные URL, дубли и бесконечные комбинации параметров, проблема не в самом роботе. Сначала лучше убрать лишние пути обхода, а уже потом ограничивать скорость.
По умолчанию Яндекс рассчитывает оптимальную скорость автоматически, стараясь получить максимум страниц без перегрузки сервера. Ручное значение при этом является рекомендацией, фактическая частота запросов может отличаться.
Короткий аварийный чек-лист
- проверить HTTP-код главной и нескольких типовых внутренних страниц;
- убедиться, что вместо ошибки сервер не раздает пустые страницы с 200;
- не превращать временный сбой в массовые 404;
- для временной проблемы учитывать рекомендацию Яндекса по 429;
- после восстановления проверить ответы через Вебмастер;
- посмотреть статистику обхода и масштаб ошибок;
- только после исправления отправлять действительно важные URL на переобход.
Что в итоге
Технический сбой сам по себе не обязан становиться SEO-проблемой. Намного опаснее неправильная реакция сервера: 200 с пустой заглушкой, массовый 404 или ошибка, которая продолжается часами без контроля.
Поэтому HTTP-коды во время аварии — не мелочь для разработчиков. Это способ объяснить поисковому роботу, что происходит с сайтом прямо сейчас.
И это как раз тот кусок технического SEO, который лучше настроить до первой серьезной аварии, а не после нее.