Простой сайта и позиции: что делают Яндекс и Google при 404, 5xx и 503 и как закрывать сайт на работы правильно

Сайт лежал ночь, а утром из поиска пропали страницы — чаще всего виноват не сам простой, а код ответа, который получали роботы. Разбираем по справкам Яндекса и Google, через сколько страница выпадает из индекса при 404, чем 5xx отличается от 4xx, почему на время работ нужен именно 503 с Retry-After, и даём конфиги nginx и Apache с проверкой через curl и логи.

Простой сайта сам по себе не снижает позиции: поисковики реагируют не на факт недоступности, а на HTTP-код, который получает робот, и на длительность. Коды 404, 403 и 410 означают «страницы нет» — Яндекс удаляет такую страницу из базы в течение недели, Google начинает выбрасывать URL из индекса через пару дней. Коды 5xx и 429 означают «временная проблема» — робот замедляет обход и несколько дней ждёт, прежде чем что-то удалять. Поэтому на время технических работ сайт должен отдавать 503 Service Unavailable с заголовком Retry-After, а не 404 и не заглушку с кодом 200.

Как Яндекс реагирует на 404, 403 и 410: удаление за неделю, возврат до трёх недель

Для Яндекса 404, 403 и 410 — официальный способ удалить страницу из поиска, а не «временная ошибка». Справка Вебмастера «Как удалить страницы из поиска» перечисляет эти коды рядом с запретом в robots.txt и метатегом noindex: «Из поисковой базы страница будет удалена в течение недели после того, как робот обнаружит ваши указания».

Вывод для простоя: если веб-сервер отдавал 404 (приложение остановлено, nginx отвечает стандартной страницей), робот воспринимает это как удаление. Пострадают URL, которые он успел обойти за окно простоя, — а трафиковые страницы обходятся чаще всех. Сводка по справке Вебмастера на сентябрь 2026:

Асимметрия важна: выпасть — неделя, вернуться — до двух-трёх недель. Для 5xx Яндекс сроков не публикует: в справочнике кодов 503 описан как «временная перегрузка или отключение на техническое обслуживание сервера» с рекомендацией «при плановых технических работах обеспечьте быстрое восстановление работоспособности сервера».

Как Google реагирует на 4xx и 5xx: удаление против замедления обхода

Google делит коды на две группы с противоположными последствиями. В документации «Как HTTP-коды влияют на роботов Google» (данные таблицы ниже — оттуда, из блога февраля 2017 года и ответов Мюллера) сказано: URL с 4xx не индексируются, а уже проиндексированные URL, начавшие отдавать 4xx, удаляются из индекса; 5xx и 429, напротив, заставляют роботов временно замедлить обход, а «уже проиндексированные URL сохраняются в индексе, но в конечном счёте удаляются» (eventually dropped).

Сроков в документации нет, их называл Джон Мюллер. Март 2020 года: «мы можем начать выбрасывать URL через пару дней; это происходит поштучно, по каждому URL». 2021 год, вопрос о пяти днях простоя: при 5xx или недоступности «мы повторяем попытки в течение примерно суток; ничего не произойдёт, пока не пройдёт несколько дней»; при 4xx «мы начнём выбрасывать эти URL из индекса — падения позиций нет, но когда страницы не в индексе, трафик падает»; заметное падение индексации видно «за первую неделю или около того», возврат занимает «неделю-две».

Ещё одна цифра — из документа Google о снижении скорости обхода: отдавать 500, 503 или 429 допустимо «на короткий период, например пару часов или 1–2 дня»; дольше — «если Googlebot наблюдает эти коды на одном и том же URL несколько дней, URL может быть удалён из индекса». Замедление касается всего хоста.

Почему 503 с Retry-After правильнее, чем 404 и заглушка с кодом 200

503 — единственный код, который оба поисковика читают как «временно недоступно, приходите позже», а не «страницы нет» и не «вот новое содержимое». Google пишет это с 2011 года: «вместо кода 404 или страницы с ошибкой и кодом 200 лучше вернуть 503, который сообщает роботам, что простой временный»; в 2017 году добавлено: «без кода 503 заглушка была бы проиндексирована как содержимое вашего сайта».

Retry-After — заголовок из RFC 9110 (раздел 10.2.3): при 503 он «указывает, как долго сервис предположительно будет недоступен», значение — HTTP-дата или число секунд. Google рекомендует его в документе о приостановке бизнеса и в блоге 2011 года пишет, что Googlebot «может использовать» его, чтобы решить, когда перепроверить URL. Яндекс заголовок не читает: в справочнике кодов, в описании 429, сказано, что ответ «может сопровождаться заголовком Retry-After... Яндекс не учитывает этот заголовок». Ставить его нужно всё равно — для Google и клиентов, уважающих стандарт, — но рассчитывать, что он отодвинет визит робота Яндекса, нельзя.

Сводная таблица «код × Яндекс × Google × что делать» для ситуации простоя, на сентябрь 2026:

Что происходит с robots.txt во время работ и почему он должен отдавать 200

Файл robots.txt нужно исключить из заглушки: он должен отдавать 200 с обычным содержимым. Если robots.txt возвращает 5xx, Google по документации «первые 12 часов прекращает обход сайта, но продолжает пытаться получить robots.txt», затем «в течение следующих 30 дней использует последнюю удачную версию» и лишь потом ведёт себя так, будто файла нет. Документ о приостановке бизнеса формулирует прямо: «не блокируйте robots.txt кодом 503».

У Яндекса логика другая: по справке, robots.txt учитывается, только если сервер отвечает 200 OK, а «если файл не соответствует требованиям, сайт считается открытым для индексирования». То есть 503 на robots.txt для Яндекса — не пауза обхода, а снятие всех Disallow: робот пойдёт в закрытые разделы, как только они откроются. Ни один из сценариев владельцу не нужен, поэтому location для robots.txt (и sitemap.xml) должен обходить правило заглушки — как в конфигах ниже.

Сколько можно лежать: длительность простоя и что происходит с индексом

При коде 503 безопасное окно — до 1–2 суток, критическая граница — неделя. Сводка ниже — для сценария «сайт отдаёт 503 или недоступен»; если сервер отдавал 404, отсчёт для Яндекса начинается сразу.

Мюллер в 2021 году подчёркивал: простой — «чисто техническая проблема, алгоритмы не воспринимают её как проблему качества». Если позиции не вернулись через неделю-две после восстановления, причина не в простое. Как сайт лежит для роботов и части регионов, оставаясь здоровым из офиса, — в кейсе про региональные 404 на CDN: страницы выпадали из топ-10, потому что робот получал 404, пока мониторинг из Москвы показывал 100 % аптайма.

Как настроить 503 на время работ в nginx

Схема: файл-флаг включает режим работ без перезагрузки конфига, error_page подставляет страницу, не меняя код 503, robots.txt и ваш IP исключены из правила. Ключевая деталь — параметр always у add_header: по документации nginx без него заголовок добавляется только к ответам 200, 201, 204, 206 и редиректам, к 503 — нет (always есть с версии 1.7.5).

# /etc/nginx/conf.d/maintenance.conf (фрагмент server {})

# свои адреса пускаем на живой сайт
geo $maintenance_allowed {
    default        0;
    203.0.113.5    1;      # офис
    198.51.100.0/24 1;     # VPN
}

server {
    listen 443 ssl;
    server_name example.com;
    root /var/www/example.com/public;

    # страница заглушки: код остаётся 503, меняется только тело
    error_page 503 @maintenance;

    # robots.txt отдаём всегда с кодом 200
    location = /robots.txt {
        try_files $uri =404;
    }

    location / {
        # режим работ включается созданием файла-флага
        set $maint 0;
        if (-f /var/www/maintenance.flag) { set $maint 1; }
        if ($maintenance_allowed) { set $maint 0; }
        if ($maint) { return 503; }

        try_files $uri $uri/ /index.php?$args;
    }

    location @maintenance {
        root /var/www/maintenance;
        # без always заголовок к 503 не добавится
        add_header Retry-After 3600 always;
        add_header Cache-Control "no-store" always;
        rewrite ^ /503.html break;
    }
}

Включение — sudo touch /var/www/maintenance.flag, выключение — rm этого файла, без nginx -s reload; конфиг перед этим проверяется командой nginx -t.

Если перед nginx стоит CDN, убедитесь, что он не кэширует 503 и не подменяет его своей страницей — Cache-Control: no-store в конфиге для этого. Почему 503 бывает без ваших работ — в статье об ошибке 503.

Как настроить 503 на время работ в Apache через .htaccess

Код задаётся флагом R у RewriteRule: по документации mod_rewrite «может быть указан любой корректный код состояния HTTP», а если он вне диапазона 300–399, «строка подстановки отбрасывается, и переписывание останавливается, как при флаге L». Страницу подставляет ErrorDocument, заголовок — Header always (без always mod_headers не трогает ответы с ошибками).

# .htaccess в корне сайта (нужны mod_rewrite и mod_headers)
RewriteEngine On

# страница заглушки и заголовок для всех ответов 503
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"
Header always set Cache-Control "no-store" "expr=%{REQUEST_STATUS} == 503"

# пропускаем свои IP
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.5$
# не трогаем саму заглушку, robots.txt и sitemap
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} !^/sitemap\.xml$
# включается, пока существует файл-флаг
RewriteCond %{DOCUMENT_ROOT}/maintenance.flag -f
RewriteRule ^ - [R=503,L]

Условие expr требует Apache 2.4. Если заглушку формирует приложение, код выставляется из него: в примере Google 2011 года это header('HTTP/1.1 503 Service Temporarily Unavailable') и header('Retry-After: ...') с датой в формате HTTP.

Как проверить заглушку глазами робота: curl и логи

Проверять нужно не в браузере, а так, как запрашивает робот: с внешнего адреса, с User-Agent робота, глядя на код и заголовки. Два запроса покрывают главное — обычная страница и robots.txt.

# запрос от имени робота Яндекса (снаружи, не из офиса)
UA="Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
curl -sI -A "$UA" https://example.com/catalog/

# пример вывода: код 503, есть Retry-After, нет кэширования
HTTP/2 503
server: nginx
date: Thu, 24 Sep 2026 21:10:03 GMT
content-type: text/html
retry-after: 3600
cache-control: no-store

# robots.txt должен остаться 200
curl -sI https://example.com/robots.txt | head -1
# пример вывода
HTTP/2 200

Второй источник правды — access-лог за окно работ: какие коды роботы получили на самом деле, включая минуты между остановкой приложения и включением заглушки.

# коды ответов роботам за время работ (формат combined,
# код - 9-е поле)
grep -E 'YandexBot|Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn
# пример вывода
   1842 503
     37 200
      4 404

# какие URL робот получил с 404 - их нужно отправить на переобход
grep -E 'YandexBot|Googlebot' /var/log/nginx/access.log \
  | awk '$9==404 {print $7}' | sort | uniq -c | sort -rn | head

Четыре 404 в примере — URL, которые Яндекс через неделю может удалить; их отправляют на переобход первыми.

Как закрыть сайт на технические работы: чек-лист

Главное правило: заглушка включается до остановки приложения и выключается после проверки снаружи, а не наоборот.

1. Запланируйте окно на время минимального трафика и уложите его в сутки: по документам Google 1–2 дня — предел. Если работы длиннее, оставьте сайт онлайн и отключите только затронутую функциональность — корзину, кабинет, поиск.
2. Подготовьте статическую заглушку без зависимостей от приложения и базы и правило 503 с Retry-After в nginx или .htaccess по примерам выше, исключив robots.txt, sitemap.xml и IP команды. Проверьте конфиг до начала окна.
3. Включите заглушку файлом-флагом и только затем останавливайте приложение, базу или деплой. Иначе между остановкой и включением заглушки сервер несколько минут отдаёт 502 или 404 — эти минуты потом видны в логах роботов.
4. Сразу проверьте снаружи через curl -I с User-Agent YandexBot и Googlebot: код 503, Retry-After на месте, robots.txt отвечает 200. Если перед сайтом CDN — из нескольких регионов, чтобы узлы не отдавали закэшированную версию с другим кодом.
5. При полном отключении сервера или переезде в другой дата-центр за несколько дней снизьте TTL DNS, поднимите временный сервер с 503 на все URL и переключите DNS на него на время работ — рекомендация Google из поста 2017 года.
6. После работ проверьте сайт с разрешённого IP — главную, карточки, поиск, заказ — и только потом удалите файл-флаг. Убедитесь curl-запросом снаружи, что страницы отдают 200, а не 503 из кэша, и сохраните access-лог за окно работ.

Что делать после восстановления: переобход, Search Console и логи роботов

После короткого простоя с корректным 503 делать почти ничего не нужно — оба поисковика вернутся сами. Действовать стоит, если простой был дольше суток или в логах роботов есть 404, 403 и 200-заглушки: тогда нужно как можно быстрее показать роботу живые страницы, чтобы прервать отсчёт «недели до удаления» у Яндекса и «пары дней» у Google.

Логи роботов после восстановления нужны не меньше: если частота запросов Googlebot через несколько дней вдвое ниже обычной, скорость обхода ещё восстанавливается. Общий порядок действий при падении — в статье «Сайт упал: что делать».

Как узнать о простое раньше робота

Большинство простоев внеплановые, и робот узнаёт о них раньше владельца. Разница между «лежал 20 минут» и «лежал до утра» для индекса принципиальна, а поймать падение за минуты можно только регулярными проверками снаружи.

Пруфен выполняет HTTP-проверки с интервалом от 2 минут из 20 точек мониторинга — 17 в России, а также Минск, Астана и Испания. В настройках задаётся ожидаемый код ответа: на время работ его можно переключить на 503 — мониторинг подтвердит, что заглушка отдаётся из всех регионов, и поднимет тревогу, если узел CDN отдаёт 200 из кэша или 404. В настройках HTTP-проверки есть пресеты User-Agent YandexBot и Googlebot — проверяется то, что видит робот, а не браузер.

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

Через сколько Яндекс удаляет страницу, которая отдаёт 404?

По справке Вебмастера — в течение недели после того, как робот обнаружит код 404, 403 или 410. Отсчёт идёт от визита робота, а не от момента поломки, поэтому у трафиковых страниц он начинается раньше. Возврат занимает до двух недель после переобхода, а после снятия запрета robots.txt или noindex — до трёх недель.

Влияет ли короткий простой на позиции, если сайт отдавал 503?

Несколько часов при коде 503 на позиции не влияют: Google повторяет попытки около суток и не трогает индекс, пока не пройдёт несколько дней, Яндекс трактует 503 как временное отключение на обслуживание. Проблемы начинаются, когда простой длится дольше 1–2 дней или когда вместо 503 сервер отдавал 404 или 200-заглушку.

Можно ли на время работ закрыть сайт паролем или по IP?

Для команды — да, для всех остальных — нет. HTTP-авторизация отдаёт роботу 401, белый список IP — 403; для Яндекса 403 входит в тройку кодов удаления наравне с 404 и 410, а Google просит не использовать 401 и 403 для ограничения обхода. Правильная схема — свои адреса на рабочий сайт, всем остальным 503.

Учитывает ли Яндекс заголовок Retry-After?

Нет: в справочнике кодов Вебмастера, в описании 429, сказано, что «Яндекс не учитывает этот заголовок». Google, напротив, рекомендует его при 503 и пишет, что Googlebot может использовать его для планирования повторного обхода. Ставить его стоит в любом случае, но ускорить возвращение робота Яндекса он не поможет — для этого есть переобход в Вебмастере.