Что такое robots.txt и как управлять обходом сайта без критических ошибок

robots.txt — публичный текстовый файл, в котором задаются правила обхода URL для поисковых и других роботов. Он сообщает совместимому краулеру, какие пути разрешено или запрещено запрашивать, но не управляет доступом пользователей к страницам и не гарантирует удаление URL из поисковой выдачи.

Файл нужен не каждому сайту. Если специальных ограничений обхода нет, можно не создавать его вовсе. Если файл используется, каждое правило должно иметь понятную цель и набор контрольных URL: один неосторожный Disallow: / способен остановить обход всего хоста указанным роботом.

Robots.txt управляет сканированием URL, но не гарантирует их удаление из поиска

Главный миф состоит в том, что запрет в robots.txt якобы «закрывает страницу от индексации». Он возник из-за смешения двух процессов: сканирования, когда робот запрашивает URL и получает содержимое, и индексирования, когда поисковая система решает, хранить ли сведения о странице и показывать ли её в поиске.

Disallow ограничивает запрос содержимого по указанному пути. Поисковик при этом может узнать сам URL из внутренних или внешних ссылок и сохранить его как известный адрес. Google прямо предупреждает, что запрещённый к обходу URL может появиться в результатах без описания, а Яндекс указывает, что ограниченные в robots.txt страницы могут участвовать в поиске.

Исключение зависит от типа ресурса и конкретной поисковой системы. Например, Google допускает использование robots.txt для ограничения появления отдельных медиафайлов в поиске, но для обычной HTML-страницы файл нельзя считать средством гарантированного удаления. Поэтому сначала формулируют задачу: сократить обход, убрать страницу из поиска, объединить дубли или закрыть контент от посторонних.

Что происходит после запрета обхода URL

После запрета робот сопоставляет URL с правилами и, если найден применимый Disallow, не запрашивает содержимое страницы. Это означает, что он не увидит текст, метатеги и другие сигналы, находящиеся внутри HTML.

URL при этом может остаться известным поисковику. Источником могут быть ссылки с других страниц, Sitemap, старые данные индекса или внешние сайты. В Google такой результат может отображаться без сниппета, потому что содержимое страницы не было получено.

Для удаления HTML-страницы обычно используют noindex, но робот должен получить страницу и прочитать этот сигнал. Одновременный Disallow блокирует доступ к метатегу или HTTP-заголовку, поэтому комбинация «запретить обход и добавить noindex» часто даёт противоположный ожидаемому результат.

Почему robots.txt не защищает закрытые разделы

robots.txt не ограничивает доступ к URL на уровне сервера. Файл доступен публично, а соблюдение правил зависит от конкретного робота: добросовестный краулер выполнит указания, произвольный скрипт может их проигнорировать.

Размещать в robots.txt пути к резервным копиям, внутренним панелям или конфиденциальным файлам как единственную меру защиты нельзя. Это не скрывает адреса и может, наоборот, перечислить интересующие пути. Для непубличного раздела нужны пароль, HTTP-аутентификация, ограничения доступа на сервере или корпоративный контур.

Если URL открывается в браузере без авторизации, наличие Disallow не делает его приватным. Это простой контрольный признак: защита должна срабатывать для любого неавторизованного клиента, а не только для поискового робота.

Robots.txt должен находиться в корне конкретного хоста и действует только в своей адресной области

Рабочий адрес файла имеет вид scheme://host:port/robots.txt. Для обычного HTTPS-сайта это, например, https://example.com/robots.txt. Файл в каталоге https://example.com/docs/robots.txt не управляет обходом сайта, потому что робот ищет его только в верхнем уровне конкретного адресного пространства.

Область действия определяется не только доменным именем. Учитываются протокол, хост и порт, поэтому https://example.com, http://example.com, https://www.example.com и https://shop.example.com проверяются как разные адреса.

Один файл не распространяется автоматически на поддомены, протоколы и порты

Файл https://example.com/robots.txt действует на URL внутри https://example.com/, но не распространяется автоматически на http://example.com/, https://www.example.com/, https://shop.example.com/ или нестандартный порт. Для каждого реально используемого хоста нужно проверить собственный публичный ответ.

При миграции опасно проверять только новый основной домен. Старый хост, www, поддомены, HTTP-версия и технические окружения могут отдавать другой файл или другой HTTP-статус.

Физический и CMS-генерируемый robots.txt проверяются по одному публичному URL

Для поискового робота не имеет значения, лежит ли файл на диске или формируется приложением. Источником истины остаётся ответ по адресу /robots.txt.

CMS, SEO-плагин, фреймворк или серверный маршрут могут создавать виртуальный файл. В такой конфигурации правка физического robots.txt ничего не изменит либо будет перезаписана при обновлении. Сначала выясняют, какой компонент формирует публичный ответ, затем меняют настройки именно там.

Проверка выполняется снаружи: открыть точный URL, получить содержимое обычным GET-запросом и убедиться, что сервер не возвращает HTML-страницу ошибки, заглушку хостинга или старую версию из кеша.

Наличие файла не равно корректной обработке: нужен проверяемый HTTP-ответ

Поисковый робот учитывает не только текст, но и результат запроса. У Google успешный ответ обрабатывается как файл правил, большинство ответов 4xx трактуются как отсутствие ограничений, а серверные ошибки могут временно остановить обход или заставить робота использовать сохранённую версию. Яндекс требует доступный файл с ответом 200 OK либо редирект на другой robots.txt, который возвращает 200 OK.

Из этого следует практическое правило: после публикации проверяют статус, цепочку редиректов, MIME-тип и фактическое содержимое. Открытие файла в браузере недостаточно, потому что браузер может следовать редиректам и не показывать промежуточные ошибки.

Для первичной проверки подойдёт команда:

curl -I https://example.com/robots.txt

Нормальный результат для прямой выдачи файла — успешный ответ без неожиданных перенаправлений. Если используется редирект, его нужно проверить до конечного robots.txt, а затем отдельно убедиться, что правила применяются в исходной адресной области.

User-agent, Disallow, Allow и Sitemap задают базовую логику файла

Минимальный robots.txt состоит из групп правил. User-agent выбирает робота, Disallow ограничивает обход пути, Allow разрешает более точное исключение, а Sitemap сообщает полный адрес XML-карты. Комментарий начинается с # и не участвует в обработке.

Пример, который запрещает обход внутреннего поиска, но оставляет доступной справочную страницу внутри каталога:

User-agent: *
Disallow: /search/
Allow: /search/help/

Sitemap: https://example.com/sitemap.xml

Этот фрагмент нельзя переносить на сайт без проверки структуры. Если /search/help/ не существует или каталог /search/ содержит ценные посадочные страницы, правило решает не ту задачу.

User-agent определяет, к какому роботу относится группа правил

User-agent: * задаёт группу для роботов, у которых нет более специфичной группы. Отдельный User-agent используют, когда конкретному краулеру нужны другие разрешения или запреты. Имена роботов нельзя придумывать по аналогии: их сверяют с документацией владельца краулера.

User-agent: *
Disallow: /temporary/

User-agent: Googlebot
Allow: /temporary/public-guide/
Disallow: /temporary/

Для Googlebot применяется его специфичная группа, а не сумма специфичной и общей групп. У Яндекса наличие группы User-agent: Yandex также меняет применение общей группы *, поэтому результат проверяют отдельно для каждого поисковика.

Пустая группа без Allow и Disallow не создаёт запрета. Равным образом пустое значение Disallow: не ограничивает обход: правило без пути игнорируется.

Disallow ограничивает путь, а Allow открывает более точное исключение

Каждый путь записывается отдельной строкой. Нельзя перечислить несколько каталогов через запятую и ожидать, что робот разделит их на самостоятельные правила.

User-agent: *
Disallow: /admin/
Disallow: /checkout/
Allow: /admin/public-manual/

Disallow: /admin/ относится к URL, путь которых начинается с /admin/. Allow: /admin/public-manual/ создаёт более точное разрешение для вложенного раздела. Результат зависит от совпадения полного пути, а не от того, какая строка расположена выше.

Начальный слеш имеет значение: правила сопоставляются с путём URL от корня. Значения путей чувствительны к регистру, поэтому /Catalog/ и /catalog/ могут обрабатываться по-разному.

Sitemap указывает карту сайта, но не заменяет правила обхода

Строка Sitemap содержит абсолютный URL, включая протокол и хост:

Sitemap: https://example.com/sitemap.xml

Карта помогает поисковику обнаружить значимые URL, но не отменяет Disallow, не гарантирует сканирование и не гарантирует попадание страницы в индекс. Google и Яндекс поддерживают указание Sitemap через robots.txt, при этом стандарт REP рассматривает такие записи как расширение, а не как правило Allow или Disallow.

Если URL одновременно указан в Sitemap и запрещён к обходу, возникает противоречие в конфигурации. Нужно определить, нужен ли этот URL поиску, а не пытаться «усилить» один сигнал другим.

Результат для URL зависит от совпадения пути, а не от визуального порядка строк

Робот выбирает применимое правило по совпадению пути. Базовый принцип стандарта — использовать наиболее специфичное, то есть наиболее длинное совпадение; при равных Allow и Disallow предпочтение отдаётся разрешению. Google и Яндекс также указывают, что порядок строк сам по себе не определяет приоритет.

Рассмотрим файл:

User-agent: *
Disallow: /catalog/
Allow: /catalog/manual/

Для /catalog/product-1/ действует общий запрет /catalog/. Для /catalog/manual/setup/ действует более длинное разрешение /catalog/manual/. Перестановка этих двух строк не должна менять результат у роботов, следующих описанной логике.

Символ * расширяет совпадение, а $ фиксирует конец URL

Символ * означает любую, в том числе пустую, последовательность символов. Символ $ фиксирует конец сопоставляемого URL. Оба символа определены стандартом REP и поддерживаются Google и Яндексом.

User-agent: *
Disallow: /*?sort=
Disallow: /*.pdf$

Первое правило совпадает с URL, где после любого пути встречается ?sort=. Оно не охватит все варианты параметров, например ?category=1&sort=price, поэтому массовые правила для параметров нужно строить на реальных URL, а не на одном примере.

Второе правило совпадает с адресами, оканчивающимися на .pdf. URL /file.pdf?download=1 под него не попадает, потому что после .pdf есть продолжение. Без $ совпадение было бы шире.

Более точное совпадение может переопределить общий запрет

Общий запрет можно сузить разрешающим исключением:

User-agent: *
Disallow: /files/
Allow: /files/public/

Для /files/private/report.pdf применяется Disallow: /files/. Для /files/public/report.pdf применяется более точный Allow: /files/public/.

При одинаковой длине совпадений стандарт рекомендует использовать Allow; Google и Яндекс описывают такую же логику для конфликта равных правил. Однако произвольные сторонние роботы могут реализовать протокол иначе, поэтому критичные ограничения нельзя строить только на предположении об их поведении.

Кодирование тоже влияет на результат. Для кириллических и специальных символов сопоставляют тот вид пути, который реально запрашивает робот; Яндекс требует кодированную запись кириллических путей, а стандарт описывает сравнение с учётом percent-encoding.

Проверять нужно реальные URL, а не только синтаксис строк

Синтаксически валидный файл может закрывать лишние страницы. До публикации составляют две выборки: URL, которые должны остаться доступными, и URL, обход которых нужно ограничить.

После проверки синтаксиса каждый URL прогоняют для конкретного user-agent. Это обнаруживает ошибку, которую не видно при чтении строк: слишком широкий префикс, неверный регистр, незакрытый вариант параметра или правило из другой группы.

Robots.txt, noindex, X-Robots-Tag, canonical и пароль решают разные задачи

Выбор начинается с цели. robots.txt управляет обходом, noindex управляет участием доступной страницы в поиске, X-Robots-Tag передаёт такой же сигнал в HTTP-заголовке, canonical указывает предпочтительную версию дублей, а пароль ограничивает фактический доступ.

Таблица не заменяет разбор конкретного URL. Для массового удаления, миграции или фасетной навигации сигналы могут пересекаться, поэтому сначала строят карту состояний: какой URL существует, доступен ли пользователю, должен ли сканироваться, должен ли индексироваться и есть ли у него каноническая версия.

Для удаления HTML-страницы из поиска робот должен увидеть noindex

Метатег noindex размещают в HTML страницы, которую робот может запросить:

<meta name="robots" content="noindex">

Google и Яндекс указывают, что правило не сработает, если URL одновременно закрыт в robots.txt: робот не получит страницу и не увидит метатег или заголовок.

Проверка состоит из трёх действий: URL разрешён к обходу, сервер возвращает ожидаемую страницу, а в полученном HTML присутствует noindex. После этого нужно дождаться повторного сканирования; загрузка изменения на сервер сама по себе не означает, что поисковик уже обработал сигнал.

Если страница содержит приватные данные, оставлять её открытой ради чтения noindex нельзя. В таком случае защита доступа важнее поискового сигнала: URL закрывают на сервере, а последствия для выдачи устраняют отдельными инструментами поисковика.

Для PDF и других не-HTML файлов подходит X-Robots-Tag

X-Robots-Tag передаётся в HTTP-заголовке ответа и подходит для ресурсов, у которых нет HTML-элемента <head>, включая PDF. Google и Яндекс документируют использование заголовка с noindex.

HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex

Проверять нужно конечный ответ самого файла, а не HTML-страницы со ссылкой на него. Команда curl -I https://example.com/file.pdf должна показать заголовок на нужном URL.

Как и метатег, X-Robots-Tag должен быть доступен роботу. Если PDF запрещён через Disallow, поисковик может не увидеть заголовок и сохранить адрес как известный URL.

Для дублей нужен canonical, а для приватного контента — контроль доступа

rel="canonical" сообщает поисковику предпочтительный URL среди одинаковых или близких по содержанию страниц. Это сигнал консолидации, а не запрет обхода и не команда удалить дубль немедленно. Google может выбрать другую каноническую версию, если остальные сигналы противоречат указанной.

Закрывать дубли в robots.txt до проверки canonical обычно невыгодно: робот может потерять доступ к содержимому и связи между версиями. Для фильтров и параметров решение принимают после анализа спроса, внутренней перелинковки, уникальности и текущего выбора канонических URL.

Приватный контент решает другую задачу. Если страницу не должны видеть посторонние, нужен отказ на уровне сервера. noindex и canonical не являются механизмами безопасности, а robots.txt соблюдают только совместимые роботы.

Google, Яндекс и стандарт robots.txt поддерживают не полностью одинаковые правила

RFC 9309 задаёт базовую модель Robots Exclusion Protocol, но поисковики добавляют собственные расширения и правила обработки. Поэтому старый шаблон нельзя считать актуальным только потому, что он когда-то работал в Google или Яндексе.

Эта матрица показывает минимально безопасную позицию: базовые правила строят на User-agent, Allow и Disallow; Sitemap используют как отдельный указатель; поисково-специфичные расширения добавляют только при подтверждённой задаче.

Базовые правила нужно сверять со стандартом и документацией поисковика

Стандарт задаёт общую семантику файла, включая расположение /robots.txt, группировку, сопоставление путей, спецсимволы и обработку доступности. Реальная поисковая система может документировать дополнительные ограничения, кеширование, статусы ответа и собственные директивы.

Поэтому для технического решения используют два уровня проверки. Сначала смотрят RFC, чтобы понять общую механику. Затем сверяют документацию конкретного робота, чтобы не переносить поведение Google на Яндекс или наоборот.

Слабое доказательство — статья с готовым файлом без даты обновления и без ссылки на текущую документацию. Особенно это касается Host, Crawl-delay, лимитов, обработки ошибок и имён отдельных роботов.

Clean-param относится к Яндексу и не заменяет общий контроль параметрических URL

Clean-param сообщает Яндексу, какие параметры не меняют содержимое страницы и могут игнорироваться при обработке дублей. Google не перечисляет эту запись среди поддерживаемых директив robots.txt.

User-agent: Yandex
Clean-param: ref /catalog/item

Такую строку добавляют только после подтверждения, что параметр ref действительно не меняет контент. Если параметр управляет сортировкой, фильтром, языком, городом, наличием или другим значимым состоянием страницы, безусловное игнорирование может объединить разные URL ошибочно.

Clean-param не заменяет архитектуру фасетной навигации, canonical, внутреннюю перелинковку и правила генерации URL. Он решает узкую задачу Яндекса и не должен использоваться как универсальная команда «закрыть все UTM и фильтры».

Host и Crawl-delay нельзя переносить из старых шаблонов без проверки

Crawl-delay не поддерживается Google, а Яндекс перестал учитывать директиву 22 февраля 2018 года и предлагает управлять скоростью обхода через Вебмастер.

Host не входит в RFC 9309, не поддерживается Google и отсутствует в текущем перечне директив Яндекса. Старую строку можно встретить в шаблонах, но считать её обязательной настройкой главного зеркала нельзя.

Наличие неподдерживаемой строки не обязательно ломает весь файл: парсеры обычно игнорируют неизвестные записи. Риск другой — владелец сайта считает задачу решённой, хотя поисковик не использует указание. Поэтому устаревшие строки лучше удалить после проверки зависимостей и заменить актуальными настройками домена, редиректов и инструментов вебмастера.

Закрывать служебные URL можно только после проверки их ценности и зависимостей

Массовый Disallow опасен не синтаксисом, а неправильной классификацией URL. Каталог с названием /filter/, /search/ или /assets/ может содержать как бесполезные комбинации, так и страницы и ресурсы, необходимые для поиска.

Риск проявляется в трёх формах: закрываются SEO-посадочные страницы, робот теряет доступ к CSS и JavaScript для интерпретации HTML либо перестаёт видеть сигналы noindex и canonical. Снизить риск можно только URL-инвентаризацией и проверкой зависимостей до публикации.

Если правило охватывает тысячи URL, фильтры каталога или общие директории ресурсов, нужна совместная проверка SEO-специалиста и разработчика. Нельзя внедрять массовый запрет по названию папки без списка затронутых адресов.

Корзину, внутренний поиск и технические страницы оценивают по функции, а не по названию каталога

Корзина, оформление заказа и результаты внутреннего поиска часто не нужны в органической выдаче, но это не делает любой похожий путь безопасным для блокировки. Сначала определяют, какие URL генерируются, куда ведут внутренние ссылки и не используются ли те же директории для публичных справочных страниц.

Для каждого класса URL фиксируют:

• назначение для пользователя;
• наличие поискового спроса;
• уникальность содержимого;
• внутренние и внешние ссылки;
• текущий статус индексирования;
• зависимость от общих CSS, JavaScript и API-ресурсов.

Если страница должна исчезнуть из поиска, но оставаться доступной пользователю, одного Disallow недостаточно. Если раздел содержит приватные данные, robots.txt вообще не должен быть основной защитой.

Фасетные фильтры могут быть дублями или SEO-посадочными страницами

Фильтры нельзя закрывать единым правилом до разделения полезных и бесполезных комбинаций. URL вида «категория + бренд» может отвечать отдельному спросу и иметь устойчивый ассортимент, а комбинация пяти малозначимых параметров — создавать бесконечные дубли.

Ценную посадочную страницу сохраняют доступной для обхода, дают ей стабильный URL, содержательный шаблон, внутренние ссылки и согласованные сигналы canonical. Технические комбинации ограничивают на уровне генерации ссылок, параметров, canonical, noindex или robots.txt — выбор зависит от того, должен ли робот увидеть содержимое и индексирующий сигнал.

Если невозможно объяснить, почему конкретная группа параметров должна быть закрыта и какой URL станет основной версией, правило ещё не готово к публикации.

CSS и JavaScript нельзя блокировать, если они нужны для интерпретации страницы

Блокировка ресурса допустима только тогда, когда его отсутствие не мешает роботу понять страницу. Google предупреждает, что закрытые стили и скрипты могут ухудшить анализ зависимых страниц.

До запрета каталога /assets/, /static/ или /wp-content/ проверяют, какие файлы загружаются на ключевых шаблонах. Если JavaScript формирует основной контент, ссылки, структурированные данные или состояние товара, закрытие файла меняет то, что доступно роботу.

Контроль выполняют не по расширению файла, а по роли ресурса. Декоративный скрипт и код, который выводит каталог, имеют разные последствия. При сомнении ресурс оставляют доступным до проверки рендеринга и серверных логов.

Симптомы ошибок robots.txt показывают, что проверять в первую очередь

Диагностика начинается с наблюдаемого симптома, а не с переписывания файла. Для каждого сбоя нужно проверить четыре уровня: какой robots.txt реально отдаётся, какой user-agent применяется, какое правило совпадает с URL и успел ли поисковик получить новую версию.

Если проблема появилась после релиза или миграции, сначала ищут массовое изменение: Disallow: /, другой хост, ошибочный статус, редирект или перезаписанный CMS-файл. Точечные правки canonical и метатегов до этой проверки могут замаскировать первопричину.

После релиза пропал обход: проверить Disallow: /, адрес файла и ответ сервера

Резкое падение запросов робота после выкладки чаще всего требует проверки production-файла. Возможные причины: тестовый Disallow: /, правило в специфичной группе, файл на другом хосте, серверная ошибка или редирект на чужую конфигурацию.

Порядок проверки:

1. Открыть /robots.txt на каждом рабочем протоколе, хосте и поддомене.
2. Проверить HTTP-ответ и конечный адрес после редиректов.
3. Найти группы User-agent и все правила, совпадающие с ключевыми URL.
4. Сравнить текущую версию с последней рабочей.
5. При полном запрете восстановить предыдущий файл и повторить проверки.

Если ошибка затрагивает весь сайт, не добавляйте хаотичные Allow для отдельных каталогов поверх неизвестной конфигурации. Сначала откатите критическое изменение, затем разберите причину.

URL остается в выдаче: проверить доступность noindex и ссылки на адрес

Сохранение URL в выдаче после Disallow не доказывает, что файл не работает. Поисковик может знать адрес по ссылкам, но не иметь доступа к содержимому и noindex.

Проверяют четыре элемента: разрешён ли обход URL, возвращает ли сервер нужную страницу, присутствует ли noindex в полученном HTML или заголовке и откуда поисковик продолжает находить адрес. Внутренние ссылки, Sitemap и внешние ссылки могут поддерживать обнаружение URL.

Если страница должна быть удалена, откройте её для робота на время чтения noindex только при отсутствии приватных данных. Для конфиденциального содержимого используйте серверную защиту и отдельные инструменты удаления, а не публичный доступ ради индексации.

Правило срабатывает неожиданно: проверить совпадение пути, регистр и кодирование

Неожиданный результат обычно связан с тем, что фактический URL совпал не с той строкой, которую смотрит человек. Причиной могут быть более длинный Allow, параметр, различие /Catalog/ и /catalog/, отсутствие начального слеша или кодированный путь.

Разберите URL посимвольно:

1. Выберите группу для конкретного user-agent.
2. Выпишите все совпадающие Allow и Disallow.
3. Сравните длину совпавших путей.
4. Проверьте $, *, регистр и percent-encoding.
5. Протестируйте соседние варианты URL, а не только один адрес.

Если Google и Яндекс дают разные результаты, не пытайтесь «починить» порядок строк. Сверьте поддержку директив и разделите группы только после понимания различий.

Новая версия не учитывается: проверить редирект, HTTP-ошибку и кеш

Загрузка нового файла на сервер не означает мгновенное применение. Робот должен повторно запросить robots.txt; Google обычно кеширует файл и при проблемах получения может использовать сохранённую версию дольше обычного.

Сначала убедитесь, что публичный URL уже отдаёт новый текст без CDN-кеша, редиректа на старый хост и серверной ошибки. Затем проверьте версию файла в доступных инструментах поисковика и сопоставьте время последнего получения с моментом публикации.

Не задавайте фиксированный срок ожидания для всех сайтов и роботов. Частота повторного запроса зависит от поисковика, состояния сервера и кеширования. Если старый критический запрет продолжает применяться, задача требует проверки логов, HTTP-ответов и инструментов вебмастера, а не пассивного ожидания.

Безопасная публикация robots.txt требует проверки до релиза и после скачивания поисковиком

Безопасный процесс строится вокруг контрольных URL и возможности отката. Валидатор синтаксиса не обнаружит, что вы закрыли коммерческий каталог корректно записанным правилом.

1. Зафиксировать цель. Для каждой строки записать, какие URL она должна запрещать или разрешать и почему.
2. Собрать контрольные адреса. Включить ожидаемо закрытые, ожидаемо открытые и пограничные URL с регистром, параметрами и вложенными путями.
3. Проверить matching до релиза. Прогнать адреса для Googlebot, Yandex и других действительно нужных роботов.
4. Проверить production-ответ. После выкладки проверить /robots.txt, HTTP-статус, редиректы и содержимое на каждом хосте.
5. Проверить поисковые инструменты. Убедиться, что поисковик видит файл и трактует контрольные URL ожидаемо; для Google доступен отчёт robots.txt, для Яндекса — анализ файла в Вебмастере.
6. Убедиться в получении новой версии. Сопоставить данные инструментов и серверных логов, не принимая локальную загрузку за применение.
7. Сохранить откат. Хранить предыдущую рабочую версию и процедуру быстрого восстановления при полном запрете.

Типовая ошибка процесса — тестовый сайт закрывают только Disallow: /, а затем этот файл попадает на production. Staging нужно закрывать авторизацией; Disallow можно оставить как дополнительный сигнал, но не как защиту.

До релиза проверить цель каждой строки и набор контрольных URL

Каждое правило должно иметь владельца и объяснимый результат. Формулировка «закрыть мусор» недостаточна: нужно перечислить типы URL, причину ограничения и страницу, которая останется основной.

Минимальный набор тестов включает:

• URL, который обязан остаться доступным;
• URL, который должен быть запрещён;
• вложенный URL под общим запретом;
• разрешённое исключение;
• адрес с параметрами;
• адрес с отличающимся регистром;
• URL критического CSS или JavaScript;
• главную страницу и основные категории.

Отдельная автоматическая проверка должна отклонять production-сборку при неожиданном Disallow: /. Это не заменяет ручной разбор, но блокирует наиболее разрушительную ошибку.

После релиза проверить публичный файл, HTTP-ответ и фактическое совпадение URL

Послерелизная проверка начинается с того же адреса, который запрашивает робот. Нужно получить заголовки и тело ответа, проверить отсутствие HTML-заглушки и убедиться, что CDN или прокси не возвращает старую версию.

Затем контрольные URL прогоняют в инструментах поисковиков. Для Google дополнительно проверяют URL Inspection и отчёты индексирования, если задача связана с noindex; для Яндекса — анализ robots.txt и проверку страницы.

Нормальный результат — совпадение трёх уровней: публичный файл содержит ожидаемые строки, тест URL показывает ожидаемое разрешение, а логи подтверждают получение новой версии роботом.

После миграции проверить каждый хост и подготовить откат критического запрета

Миграция меняет адресную область, редиректы и инфраструктуру выдачи файла. Проверять нужно старый домен, новый домен, www, поддомены, HTTP и HTTPS, потому что у каждого адреса может быть собственный robots.txt.

До переключения сохраните обе версии файла и таблицу контрольных URL. После переключения проверьте конечные ответы, цепочки редиректов, отсутствие тестовых запретов и доступ к CSS, JavaScript, canonical и noindex.

Если обнаружен полный запрет, откат выполняют сразу на уровне файла или маршрута, который формирует ответ. Массово менять canonical, Sitemap и метатеги до восстановления обхода нельзя: это усложнит диагностику и создаст новые конфликтующие сигналы.