Тестовая копия правильно запрещает весь обход, но при релизе тот же robots.txt попадает на рабочий домен. Проблема находится в конфигурации среды, а не в оформлении файла. Приёмка должна обращаться к публичному адресу после сборки и очистки нужного кеша.
Матрица production, staging и временных preview
Для production и staging определите разные ожидаемые правила. Тестовый сайт с приватной информацией защищайте доступом, а не одним Disallow. Проверяйте фактический хост запроса, поскольку окружение сборки и окружение запуска могут различаться.
Правила robots.txt действуют для конкретных хоста, протокола и порта. Официальная документация.
В небольшом проекте может быть три адреса: example.com, staging.example.com и случайный preview-домен. У каждого своё назначение и собственная политика. Перечислите нужные публичные пути production и запреты тестовой копии. Preview может содержать клиентские данные, поэтому сначала решите вопрос авторизации. Не превращайте проверку в универсальное условие «robots не должен содержать Disallow»: для тестового окружения ограничение бывает намеренным. Условия приёмки должны одновременно предотвращать закрытие рабочего сайта и случайное открытие копии.
Что должен отдавать каждый домен
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| Production | Публичные страницы | Обход нужных путей | Проверить ответ после релиза |
| Staging | Тестовый контент | Отдельные ограничения | Не копировать production |
| Preview | Временная сборка | Проверить политику доступа | Не считать домен рабочим |
| CDN кеш | Старая конфигурация | Сверить тело ответа | Очистить нужный ключ |
Сохраните ожидаемое тело файла для каждого хоста. Проверяйте /robots.txt от корня нужного origin, а не похожий файл в подпапке. При HTTPS и отдельном порте учитывайте конкретный адрес запроса. Добавьте строку Sitemap, если она используется: тестовая копия не должна случайно ссылаться на собственную карту как на рабочий источник. Матрица включает также публичный статус ответа и тип содержимого. Ответ 200 с HTML-страницей приложения не является подтверждением того, что опубликован нужный текстовый файл.
Найдите источник robots.txt в сборке и сервере
Сравните ответ /robots.txt на обоих доменах, заголовки кеша и источник генерации. Проверьте, не встроена ли настройка staging в готовый артефакт, не перехватывает ли путь CDN и не опубликован ли статический файл поверх маршрута CMS.
Проверьте возможные источники по одному: статический файл проекта, маршрут CMS, reverse proxy и правило CDN. Не переименовывайте файлы наугад. Сначала сравните публичное тело с тем, что создаёт предполагаемый источник. В некоторых системах настройка окружения применяется во время сборки, поэтому переменная запуска уже не изменит встроенный файл. В других robots генерируется при запросе, а CDN сохраняет его. Отличие этих механизмов определяет, нужно ли пересобирать приложение или только исправить runtime-настройку и инвалидировать соответствующий кеш.
Проверьте перенос готового артефакта
Учебный релиз проверяет example.com и staging.example.com. В списке ожиданий у первого разрешены публичные услуги, у второго остаются ограничения тестовой среды. Перестановка файлов между хостами должна приводить к провалу проверки.
Учебная проверка выпускает staging-артефакт на тестовый публичный домен и проверяет, какие правила он содержит. Затем тот же артефакт нельзя автоматически считать пригодным для production. Добавьте отдельное ожидание на рабочий хост. Если CI сохраняет статические файлы между сборками, проверьте очистку выходного каталога. Если deployment копирует public целиком, выясните, не попадает ли туда локальная заглушка robots.txt. Эта проверка относится к составу артефакта; успешная работа стартовой страницы не подтверждает правильную политику обхода.
Привяжите политику к явной среде
Привяжите правила к явной конфигурации окружения. Добавьте перед релизом проверку ожидаемого ответа для каждого хоста; после публикации повторите её через публичный маршрут, которым пользуется робот.
Используйте явную настройку среды, проверяемую в коде и релизном процессе. Не определяйте production только по наличию слова staging в произвольном заголовке Host. В согласованном списке доменов укажите рабочий адрес и допустимые тестовые адреса. Для неизвестного окружения выбирайте заранее принятую безопасную политику, а не случайное значение по умолчанию. Если приложение поддерживает несколько production-хостов, опишите каждый отдельно. Тогда добавление домена станет проверяемым изменением и не унаследует robots от первого подходящего сайта.
Почему очистка кеша не исправляет конфигурацию
Копирование production-правил обратно на staging тоже опасно: тестовые страницы станут доступны обходу. Автоматическая проверка должна знать оба ожидания, а не требовать отсутствия Disallow везде.
Очистка CDN помогает получить новую версию, но не изменяет сам генератор. После purge снова запросите файл и сравните его содержимое с ожиданием. Посмотрите Age, Cache-Control и доступные диагностические заголовки кеша, если они есть. Не утверждайте, что отсутствие Age означает отсутствие кеша: конкретная инфраструктура может не выдавать такой заголовок. Если ответ снова старый, проверьте происхождение файла и ключ кеша. Удаление всех кешей сайта редко требуется для исправления одного текстового маршрута и затрудняет диагностику.
Проверка после релиза и смены домена
После релиза откройте /robots.txt напрямую через рабочий публичный маршрут. Проверьте точные запреты, sitemap и один разрешённый контрольный путь. Затем повторите проверку staging, чтобы исключить обратную ошибку. При смене домена проверьте старый хост и новый: общий nginx-шаблон может отдавать им один файл. В журнал приёмки запишите версии артефакта и время публичного запроса. Состояние поискового обхода оценивайте отдельно, поскольку робот может использовать ранее полученные правила. Такая запись помогает отличить текущий дефект среды от старого наблюдения.
Критерии завершения проверки
Рабочий сайт отдаёт согласованные production-правила, тестовый — собственные ограничения и авторизацию при необходимости. Sitemap содержит только нужный публичный домен, кеш не возвращает предыдущую версию.
- Production: Проверить ответ после релиза. Зафиксируйте фактический результат и адрес проверенного сценария.
- Staging: Не копировать production. Зафиксируйте фактический результат и адрес проверенного сценария.
- Preview: Не считать домен рабочим. Зафиксируйте фактический результат и адрес проверенного сценария.
- CDN кеш: Очистить нужный ключ. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Что проверить на сайте сразу после публикации изменений и 7 ошибок в robots.txt, которые убивают индексацию. Отдельные проверки сайта собраны на странице технического аудита reChecker.