Сайт отвечает 200, заявки идут, а в отчёте поисковой системы появляется рост «Заблокировано robots.txt». Такое случается после релиза, когда вместе с кодом приезжает staging-файл с Disallow: /. Для посетителя всё выглядит исправно, поэтому проблема может жить незаметно.
Первое, что я бы проверил, — production-файл, а не копию в репозитории. Нужны HTTP-заголовки, конечный URL и содержимое, которое реально получает внешний робот.
Скачайте robots.txt с production
curl -sS -D robots-headers.txt -o robots-production.txt https://example.ru/robots.txt
cat robots-headers.txt
cat robots-production.txtPASS: конечный ответ 200, содержимое текстовое, файл относится к нужному хосту. FAIL: 301 на другой домен, 5xx, HTML страницы ошибки или полный запрет из staging.
Проверьте и вариант www, если он существует. Правила robots относятся к конкретному хосту и протоколу. Не делайте вывод по одному зеркалу.
Найдите группу и конкретное совпавшее правило
Файл читают группами User-agent. Если есть отдельные секции для Googlebot и YandexBot, итог может отличаться. Проверяйте не «сайт вообще», а конкретный URL: главную, страницу услуги, карточку и служебный путь.
User-agent: *
Disallow: /admin/
Disallow: /search?
# Аварийный staging-вариант, который нельзя выпускать:
# User-agent: *
# Disallow: /| Проверка | PASS | FAIL |
|---|---|---|
| / | Разрешена | Совпало Disallow: / |
| /services/ | Разрешена | Закрыта широким /service |
| /admin/ | Закрыта по плану | Открыта при требовании закрыть обход |
| CSS/JS | Робот может отрисовать страницу | Критичные ресурсы закрыты |
Используйте robots.txt report в Search Console и инструменты Яндекс Вебмастера для уже доступного production-файла. Локальный парсер полезен до релиза, но не доказывает, что нужная версия попала на сервер.
Отделите robots.txt от noindex
robots.txt регулирует обход. Meta robots и заголовок X-Robots-Tag регулируют индексацию при доступном ответе. Если закрыть URL от обхода, поисковик может не увидеть добавленный noindex. Поэтому «поставим Disallow, чтобы удалить страницу» — плохая аварийная стратегия.
curl -sS -I https://example.ru/services/example
curl -sS https://example.ru/services/example |
grep -iE 'robots|canonical'Проверьте ответ 200, отсутствие нежелательного X-Robots-Tag: noindex, meta robots и self-canonical отдельно. Один зелёный тест robots.txt не закрывает весь SEO-контур.
Найдите источник неправильного файла
- Зафиксируйте активный commit и build ID.
- Сравните production robots.txt с файлом в этом commit.
- Проверьте шаблон, environment switch и шаг копирования static assets.
- Исправьте источник и соберите новый immutable release.
- После переключения повторите внешние проверки.
git show HEAD:public/robots.txt
git diff HEAD~1 -- public/robots.txtЕсли файл генерируется динамически, зафиксируйте значения production environment без секретов. Частая ошибка — условие вида «если переменная не задана, закрыть всё», которое безопасно для staging, но опасно при пропущенной переменной в production.
Не правьте активный release вручную
Ручная правка быстро открывает обход, но создаёт вторую версию production, которой нет в Git. Следующий deploy вернёт запрет. Если ситуация аварийная, временное исправление допустимо только вместе с немедленным исправлением источника и контрольным релизом.
Чек-лист после исправления
- robots.txt отвечает 200 на каждом каноническом хосте.
- Googlebot и YandexBot разрешены на ключевых URL.
- Служебные разделы закрыты ожидаемо.
- Meta robots и X-Robots-Tag проверены отдельно.
- Self-canonical не изменился.
- Sitemap указывает на живые разрешённые URL.
- Файл совпадает с активным commit.
Добавьте robots.txt в release gate
Один ручной инцидент лучше превратить в автоматическую проверку. До переключения release скачайте собранный robots.txt и прогоните список критичных URL для Googlebot и YandexBot. Сборка должна падать, если главная, блог или коммерческие страницы совпали с запрещающим правилом.
После deploy повторите внешний тест. Проверка файла внутри build-каталога не ловит ошибку reverse proxy, CDN или неверного symlink. В отчёт запишите активный SHA, хеш robots.txt и результат для пяти контрольных URL. Тогда следующий инцидент сравнивается с фактами, а не с памятью команды.
Что мониторить после релиза
Проверяйте HTTP-код robots.txt, изменение его хеша и доступность ключевых URL. PASS: изменение файла связано с известным commit. FAIL: хеш поменялся без релиза или файл стал отвечать HTML. Такая проверка дёшева и ловит проблему раньше, чем она появится в отчётах обхода.
Типичные ошибки
Проверять браузером только содержимое. Редирект или неверный content type останутся незамеченными.
Читать правила на глаз. Длинные группы и широкие префиксы лучше проверять на конкретных URL.
Закрывать дубли. Для выбора основной версии используйте canonical и редиректы, а не запрет обхода нужного сигнала.
Забывать ресурсы. Закрытые CSS и JS мешают поисковику увидеть страницу так, как её видит пользователь.
Что делать, если не помогло
Сохраните четыре артефакта: production robots.txt, заголовки целевого URL, HTML с meta robots/canonical и ID активного release. Если robots разрешает URL, переходите к noindex, X-Robots-Tag и HTTP-коду. После релиза используйте проверку canonical и полный сценарий приёмочного тестирования сайта. CTR1 может проверить сайт и его release-процесс, чтобы staging-настройки не попадали в production.
