Что разрешает robots.txt и чего файл запретить не может

После релиза каталог пропал из отчётов поисковика. Команда проверяет страницы: они открываются, сервер отвечает, ссылки на месте. Причина находится в одной строке Disallow, которая должна была закрыть тестовый раздел, а закрыла рабочий. Так robots.txt из небольшого служебного файла превращается в точку риска для трафика.

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

Robots.txt отвечает на вопрос «можно ли роботу запросить этот URL», а не «может ли страница существовать в индексе».

Файл размещают строго по адресу /robots.txt в корне конкретного источника сайта. Для https://example.ru/ поисковый робот проверяет https://example.ru/robots.txt; файл в подкаталоге не управляет этим источником. Правила с другого поддомена, протокола или нестандартного порта автоматически не переносятся. Поэтому у основного домена, магазина на поддомене и тестового окружения могут быть разные файлы.

Robots.txt публичен. Его может открыть любой человек без доступа к панели управления. В нём нельзя хранить пароли, внутренние комментарии о резервных копиях или список секретных документов. Более того, строка Disallow: /contracts/ сама подскажет адрес интересного раздела, хотя и попросит добросовестного робота его не обходить.

Базовый протокол описан в RFC 9309. Крупные поисковые системы дополнительно документируют свою обработку правил и расширений. Не каждый автоматический клиент обязан следовать robots.txt: вредоносный сборщик может его проигнорировать. Защита персональных кабинетов, файлов клиентов и административных интерфейсов строится на аутентификации, авторизации и сетевых ограничениях, а не на вежливой просьбе к роботу.

Группа начинается с User-agent — имени робота, для которого действуют следующие строки. Значение * относится к роботам, для которых нет подходящей отдельной группы. В RFC совпадающие группы одного product token объединяются. Google выбирает наиболее точный подходящий user-agent, объединяет повторные группы для него и не добавляет к ним правила *; Яндекс применяет иерархию «конкретный робот → Yandex → *». Поэтому общая группа не обязательно дополняет специальную.

Disallow запрещает обход пути, а Allow разрешает путь внутри более широкого запрета. RFC требует выбирать самое длинное совпадающее правило и рекомендует Allow при равном совпадении; Google и Яндекс также отдают приоритет Allow при равной длине. Регистр пути учитывается, а порядок строк сам по себе приоритет не задаёт. * означает любую последовательность символов, $ — конец совпадения. Строка Sitemap указывает полный адрес XML-карты, но это поддерживаемое поисковиками расширение, а не основное правило Allow/Disallow RFC и не настройка отдельной группы.

Простой пример:

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

Путь после Allow или Disallow сопоставляется с адресом запроса от первого символа. Кодирование символов, слеши и параметры могут изменить результат. Чем сложнее шаблон файла, тем труднее команде предсказать последствия следующего изменения URL.

Комментарии начинаются с #. Они полезны, когда объясняют владельца и причину ограничения: например, «внутренний поиск создаёт бесконечные комбинации запросов». Но комментарий не должен раскрывать внутреннюю структуру защищённых данных. Если правило невозможно объяснить одной фразой, его стоит вынести в техническое решение рядом с шаблонами CMS и тестами релиза.

Чтобы прочитать метатег noindex или заголовок X-Robots-Tag, робот должен запросить страницу. Если сначала запретить этот URL в robots.txt, поисковая система может не увидеть указание об исключении из поиска. При этом сам адрес может быть известен из внутренних или внешних ссылок, старой карты сайта либо предыдущего обхода. В результате в поиске иногда остаётся URL без понятного описания содержимого.

Для разных задач нужны разные механизмы:

Canonical тоже нельзя прятать за запретом обхода. Эта ссылка находится в HTML или HTTP-заголовке ответа. Если робот не получает ответ, он не видит предпочтительный адрес. На пути URL эта граница разобрана в статье об индексации сайта.

RFC 9309 требует UTF-8 и text/plain; клиент должен уметь обработать как минимум 500 КиБ. Google обрабатывает первые 500 КиБ, а Яндекс документирует предел 500 КБ, поэтому файл лучше держать значительно меньше. Стандарт допускает кеширование и рекомендует не использовать доступную кешированную версию дольше 24 часов. По RFC ответ класса 4xx означает, что клиент может продолжить обход, а при 5xx или сетевой недоступности он должен считать обход полностью запрещённым; после длительной недоступности допускается другое поведение.

Реализации отличаются. Google обычно кеширует файл до 24 часов, трактует 4xx, кроме 429, как отсутствие ограничений, а при 5xx сначала останавливает обход на 12 часов, затем при наличии использует последнюю успешную версию до 30 дней. Яндекс требует 200 OK либо редирект на доступный robots.txt и сообщает, что при несоответствии требованиям считает сайт открытым. Поэтому код ответа robots.txt нельзя использовать как универсальный переключатель: проверяют документацию и фактическое поведение каждого важного робота.

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

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

Безопаснее разделять окружения технически: тестовый сайт защищать доступом, а рабочий robots.txt собирать из отдельной конфигурации. В чек-листе релиза нужен запрос к реальному https://домен/robots.txt, а не просмотр файла в репозитории. CDN, CMS или прокси могут отдать не ту версию, которую видел разработчик локально.

Строка Disallow: /client-documents/ ограничивает обход у поддерживающего её робота, но не запрещает человеку открыть документ. Если файл доступен по ссылке без проверки прав, проблема находится в серверной защите. Robots.txt здесь только маскирует симптом.

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

У магазина параметры сортировки, фильтров, пагинации и рекламных меток создают множество URL. Команда запрещает все адреса со знаком ?. Вместе с техническими копиями под правило могут попасть полезные отфильтрованные категории, API-ресурсы для отрисовки или адреса, на которых поисковику нужно увидеть canonical.

Сначала URL группируют по назначению. UTM-метка обычно не меняет содержание. Сортировка меняет порядок. Фильтр может создать самостоятельную страницу под устойчивую потребность. Пагинация открывает товары дальше первой страницы. Только после этой карты решают, где нужен canonical, редирект, отдельная индексация или ограничение обхода. Массовая строка не заменяет разбор того, какую версию поисковик сочтёт основной.

Иногда в robots.txt закрывают каталоги /assets/, /scripts/ или /styles/, потому что эти файлы сами по себе не должны появляться в поиске. Но робот может загружать CSS и JavaScript, чтобы отрисовать страницу и понять видимое содержимое. Если критичный ресурс закрыт, поисковая система получает неполное представление интерфейса.

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

Особенно осторожно работают сайты, где карточки и категории собираются JavaScript. HTML может содержать только оболочку, а товары, цены и ссылки появляются после запросов к ресурсам. Слепой запрет таких запросов делает страницу пустой для робота, хотя в браузере сотрудника всё выглядит нормально.

Один и тот же URL получает сигналы из нескольких мест:

Если Sitemap перечисляет категорию, меню ведёт на неё, а robots.txt запрещает путь, система сообщает одновременно «это важная страница» и «не запрашивай её». Такое противоречие не обязательно приводит к одному предсказуемому результату, зато усложняет диагностику.

Robots.txt нужно проверять в связке с индексированием страниц и общим контуром SEO для бизнеса. Доступность для обхода — только один этап. Разрешённая страница может не попасть в индекс из-за ответа сервера, canonical, дублирования, слабого содержания или других причин. И наоборот, запрет обхода не гарантирует, что уже известный адрес мгновенно исчезнет из результатов.

Файл может быть синтаксически правильным и при этом противоречить реальной архитектуре сайта.

Перед правкой составьте набор контрольных адресов. В него должны попасть:

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

После релиза не ждите только изменения позиций. Сначала проверьте:

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

Robots.txt полезен как точный регулятор обхода, а не как универсальная кнопка «спрятать». Перед выпуском файла проверьте четыре границы:

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