Короткий ответ
Если robots.txt отдаёт 404, Google считает, что файла нет и запретов нет. Все ваши Disallow перестают работать сразу. Если он отдаёт 5xx, Google останавливает сканирование сайта на 12 часов, затем до 30 дней живёт на последней удачной копии файла. Редирект Googlebot проходит, причём минимум пять переходов подряд, а потом считает результат ответом 404.
Отсюда неочевидный вывод. Опасна не столько недоступность файла, сколько тихая потеря правил: 404 снимает их мгновенно, а затяжная ошибка снимает через 30 дней. Сайт при этом работает, и никто ничего не замечает.
Что Google делает с каждым ответом
Правила ниже взяты из документации Google о том, как он разбирает robots.txt. Я открыл её 9 ноября 2026 года и сверил все пункты таблицы. Что я мерил сам, отмечено в следующем разделе.
| Ответ на /robots.txt | Что делает Google | Что это значит для сайта |
|---|---|---|
| 2xx | Обрабатывает файл как есть, кеширует, как правило, до 24 часов | Работает как задумано |
| 3xx | Проходит минимум пять переходов, потом считает результат ответом 404 | Один переход (http на https) безопасен; длинная цепочка равна отсутствию файла |
| 4xx, кроме 429 | Считает, что действующего файла нет | Все Disallow перестают действовать |
| 5xx, первые 12 часов | Останавливает сканирование сайта, повторяя запрос файла | Новые страницы в этот срок не обходятся |
| 5xx, до 30 дней | Использует последнюю удачную копию, продолжая пытаться получить новую | Правила держатся, если копия была |
| 5xx дольше 30 дней | При доступном в целом сайте считает, что файла нет | Правила снимаются |
Про 429 страница документации ничего не говорит, только исключает его из правила 4xx. Что Google делает именно с ним, она не уточняет, поэтому я отношу его к ошибкам сервера как рабочее допущение, а не как факт.
Ещё три ограничения. Файл больше 500 КиБ Google читает не весь: всё, что после этой отметки, игнорируется. Кеш обычно живёт до 24 часов и может держаться дольше, когда обновить файл не удаётся. А правила действуют только для того хоста, протокола и порта, где лежит файл: у https://adlab.ee и https://www.adlab.ee это разные файлы.
Как это выглядит на adlab.ee: замер 9 ноября 2026
Я прогнал curl -I по шести вариантам адреса. Файл https://adlab.ee/robots.txt отдаёт 200 с типом text/plain, весит 77 байт и содержит три значащие строки: Allow: /, Disallow: /dl/ и ссылку на sitemap. Заголовок Cache-Control: public, max-age=14400 разрешает Cloudflare и браузерам держать копию 4 часа.
Четыре из пяти остальных адресов (оба с http, https://www и адрес со слешем на конце) отвечают 308 и один раз перенаправляют на https://adlab.ee/robots.txt. Лимит Google в пять переходов даёт запас в четыре. Пятый, /Robots.txt с заглавной R, отдаёт 404, поэтому регистр в имени файла надо держать строчным.
Чего я не мерил: 5xx и 429. Ронять robots.txt на живом сайте ради эксперимента я не буду, поэтому строки таблицы про 12 часов и 30 дней опираются на документацию Google, а не на мои наблюдения.
Откуда на самом деле берётся 5xx и 404
В моей практике файл ломается не сам по себе, а вместе с чем-то ещё: релизом, плагином, миграцией. Пять сценариев, и каждый заканчивается одним из кодов 403, 404, 429 или 5xx:
- Режим обслуживания на 503 для всего сайта. Google рекомендует 503 при коротких остановках, и для страниц это верно. Но если заглушка накрывает и
/robots.txt, работает правило 12 часов: обход встаёт. Файл лучше исключить из заглушки. - Защита от ботов и ограничение частоты. CDN или файрвол отвечает 429 или 403 на запросы без браузерных заголовков. 403 для Google равен 404, то есть файл «пропал» вместе со всеми запретами.
- Виртуальный файл в CMS. WordPress отдаёт
robots.txtдинамически, если физического файла нет. Сломанный плагин превращает его в 500, при том что остальные страницы работают из кеша. - Релиз со стейджинга. Тестовый
Disallow: /уезжает на рабочий сайт. Файл отдаёт 200, и это самый дорогой случай; я разбирал его в статье про стейджинг и прод. - Цепочка редиректов у файла. Миграция домена добавила звено, потом второе, и до конечного файла стало больше пяти переходов. Как искать такие цепочки, описано в разборе цепочек редиректов.
Если страница, закрытая правилом Disallow, остаётся в выдаче Google, а не пропадает, причина в том, что закрытие обхода не равно запрету индексации (noindex). Эту разницу я описывал в статье про sitemap.xml и robots.txt.
Как проверить за минуту
Один раз прогоните четыре варианта адреса и убедитесь, что у каждого один переход и финальный 200:
for u in http://site.ee https://site.ee http://www.site.ee https://www.site.ee; do
echo "== $u"; curl -sI -m 15 "$u/robots.txt" | grep -iE "^(HTTP|location|content-type)"
done
Затем проверьте три места:
- Тип содержимого. Нужен
text/plain, а неtext/html. HTML-заглушка с кодом 200 маскирует проблему. - Отчёт robots.txt в Search Console. Он показывает последнюю прочитанную версию файла, время обхода и ошибки.
- Статистика сканирования. В блоке «Состояние хоста» видно, были ли сбои при получении robots.txt. Серия сбоев за сутки совпадает с остановкой обхода.
И последний шаг: поставьте на код ответа /robots.txt отдельный мониторинг с оповещением. Проверка раз в 5 минут обойдётся в 288 запросов в сутки на 77 байт, а отчёт Search Console узнаёт о сбое с запозданием в дни.
Кому это не нужно
Сайту без robots.txt и без единого Disallow (маленькая визитка, где закрывать нечего) 404 на этом адресе не вредит, и чинить тут нечего. Достаточно, чтобы файл не отдавал 5xx.
Границы моих выводов: правила в таблице описывают Google. Яндекс и Bing разбирают коды ответа по-своему, их документацию я здесь не проверял. Схема с 12 часами и 30 днями взята из документации, а не из моего эксперимента. Для сайта с большим каталогом, где краулинговый бюджет ограничен, цена остановки обхода выше, чем для блога на сто страниц. А если вы ищете, почему страницы вообще пропали из поиска, начните с причин, по которым Google не индексирует страницы: robots.txt там лишь одна из версий. Если нужен разбор таких вещей на вашем проекте, я включаю его в технический SEO-аудит.
