robots.txt

Происхождение и история термина

Протокол исключений для роботов предложил Мартейн Костер (Martijn Koster) в 1994 году; именно этот исходный метод современный стандарт уточняет и расширяет ^[1]. Долгое время протокол оставался стандартом де-факто: в описании открытой библиотеки Google для разбора robots.txt сказано, что за 25 лет такого статуса разработчики по-разному разбирали файлы, и это порождало путаницу ^[15]. Различия сохраняются и сейчас: Google предупреждает, что разные краулеры по-разному интерпретируют синтаксис ^[2], а Яндекс — что роботы других поисковых систем и сервисов могут иначе толковать директивы ^[6].

В учебнике Маннинга, Рагхавана и Шютце «Introduction to Information Retrieval» (2008) проверка robots.txt описана как часть архитектуры поискового краулера: краулер получает robots.txt хоста, чтобы проверить, можно ли загружать URL, хранит недавние копии файлов в кэше и выполняет проверку непосредственно перед загрузкой страницы, потому что файл мог измениться за время ожидания URL в очереди ^[13].

В сентябре 2022 года IETF опубликовал RFC 9309 «Robots Exclusion Protocol» (авторы — M. Koster, G. Illyes, H. Zeller, L. Sassman; трое последних указаны как сотрудники Google LLC). Документ уточняет исходный метод и добавляет правила обработки ошибок и кэширования ^[1].

Российская линия развития связана прежде всего с Яндексом. У Яндекса есть собственная межсекционная директива Clean-param для параметров URL, которые не меняют содержимое страницы ^[10]. Директиву Crawl-delay Яндекс перестал учитывать с 22 февраля 2018 года; скорость обхода теперь настраивается в Яндекс Вебмастере ^[9]. Директивы Host в текущем перечне поддерживаемых директив справки Яндекса нет ^[6].

Новый этап — использование robots.txt для управления ИИ-краулерами. Google ввёл отдельный токен Google-Extended для решений об использовании контента в моделях Gemini ^[5]. OpenAI описывает несколько агентов с разным назначением, в том числе для обучения моделей (GPTBot), поиска ChatGPT (OAI-SearchBot), действий по запросу пользователя (ChatGPT-User) и проверки рекламных страниц (OAI-AdsBot) ^[12].

Суть и механизм

Где лежит файл и каким он должен быть

Из чего состоит файл

robots.txt состоит из групп и отдельных записей. Группа начинается с одной или нескольких строк User-agent (кому адресованы правила), за которыми идут правила Allow и Disallow с путями. Символ # начинает комментарий ^[1]. Запись Sitemap не привязана к конкретному User-agent ^[3]; в RFC 9309 такие записи относятся к «прочим», которые краулер вправе понимать, если это не мешает разбору основных правил ^[1]. Названия директив регистр не учитывают, а пути — учитывают: /Catalog и /catalog — разные адреса ^{[3; 6]}.

Как робот применяет правила

1. Запрос файла. Перед обходом робот загружает robots.txt и хранит его в кэше. По RFC 9309 кэшированную версию не следует использовать дольше 24 часов, если файл доступен ^[1]; Google обычно кэширует файл до 24 часов и может учитывать заголовок Cache-Control: max-age ^[3].
2. Выбор группы. По RFC 9309 имя робота сравнивается без учёта регистра, все подходящие ему группы объединяются, а если подходящей нет — действует группа *; если нет и её, ограничений нет ^[1]. У Google для робота действует одна группа — с самым конкретным совпадающим User-agent; несколько групп для одного и того же робота объединяются, а с группой * собственная группа не объединяется ^[3]. Яндекс: при наличии группы User-agent: Yandex группа * не учитывается; при наличии группы для конкретного робота (например, YandexBot) не используются ни Yandex, ни * ^[8].
3. Сопоставление пути. Путь из правила сравнивается с началом URL. * означает любую последовательность символов, $ — конец URL ^{[1; 3]}. Яндекс по умолчанию дописывает * в конец каждого правила, поэтому Disallow: /cgi-bin и Disallow: /cgi-bin* равнозначны ^[7].
4. Приоритет. Срабатывает самое конкретное правило — с наибольшим числом символов. При равной длине по RFC 9309 побеждает Allow ^[1]; Google в конфликтных случаях, включая правила с подстановочными знаками, применяет наименее строгое правило ^[3]; Яндекс сортирует правила по длине префикса и при равной длине отдаёт приоритет Allow ^[7]. Порядок строк в файле на результат не влияет ^[7].

Что происходит при ошибках

Справка Яндекса требует ответа 200 OK и указывает, что сайт считается открытым для индексирования, если файл не соответствует требованиям; как Яндекс обрабатывает конкретные коды 4xx и 5xx, в ней отдельно не описано ^[6].

Пример 1. Всё открыто, указана карта сайта

User-agent: *
Allow: /

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

Любой добросовестный робот может сканировать весь сайт, а адрес карты сайта доступен всем краулерам ^[3].

Пример 2. Типовой сайт на CMS (пример)

User-agent: *
Disallow: /admin/
Allow: /admin/public/
Disallow: /search
Disallow: /*?sort=

User-agent: Yandex
Disallow: /admin/
Allow: /admin/public/
Disallow: /search

Clean-param: utm_source&utm_medium&utm_campaign

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

Разбор:

• Для Googlebot действует группа * (отдельной группы для него нет) ^[3]. Закрыты служебный раздел /admin/ (кроме /admin/public/, потому что это правило длиннее), внутренний поиск и страницы с сортировкой.
• Disallow: /search закроет не только /search?q=…, но и, например, /searchable/ — правило работает как префикс ^{[3; 7]}.
• Для роботов Яндекса действует только группа Yandex, группа * игнорируется ^[8]. Поэтому правило Disallow: /*?sort= на них не распространяется — его нужно продублировать в группе Yandex. Такую ошибку легко допустить, если дописывать отдельную группу для Яндекса к готовому шаблону (вывод).
• Clean-param — межсекционная директива Яндекса, её можно указать в любом месте файла ^[10]; Google её не поддерживает ^[3]. Подробно — в статье «Директива Clean-param».

Пример 3. Конфликт Allow и Disallow (пример)

User-agent: *
Disallow: /catalog
Allow: /catalog/auto
Disallow: /*.pdf$

Аналогичный пример в справке Яндекса: при Allow: /catalog/auto и Disallow: /catalog страницы, начинающиеся с /catalog, закрыты, а начинающиеся с /catalog/auto — открыты ^[7].

Виды и классификации

Директивы по поддержке

Классификация составлена по документации RFC 9309, Google и Яндекса.

Адресаты правил

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

• Поисковые роботы. У Google основной токен — Googlebot. У Googlebot-Image, Googlebot-Video и Googlebot-News по два токена — собственный и Googlebot; чтобы правило применилось, достаточно совпадения одного из них ^[5]. Роботы Яндекса читают группы Yandex и *, но некоторые из них могут игнорировать указания, в том числе для User-agent: Yandex, — для них нужно указывать конкретный User-agent ^[8].
• ИИ-краулеры и токены управления. Google-Extended не имеет собственной строки User-agent в HTTP-запросах: сканирование ведут обычные роботы Google, а токен служит только для управления. Он определяет, можно ли использовать контент для обучения будущих моделей Gemini и для grounding (подстановки данных из индекса Google Поиска в ответ модели), и не влияет на присутствие сайта в Google Поиске и ранжирование ^[5]. У OpenAI GPTBot связан с обучением генеративных моделей, OAI-SearchBot — с показом сайтов в поиске ChatGPT; настройки для них независимы ^[12]. OAI-AdsBot посещает только страницы, поданные как реклама в ChatGPT, чтобы проверить их безопасность; по данным OpenAI, собранное им не используется для обучения моделей ^[12].
• Агенты, действующие по запросу пользователя. ChatGPT-User выполняет действия, инициированные человеком, не обходит веб автоматически, и, по словам OpenAI, правила robots.txt к нему могут не применяться ^[12].

robots.txt и другие механизмы управления

Подробнее — в статьях «Мета-тег robots» и «noindex».

Как применяется на практике

Снижение нагрузки и экономия обхода. Google называет основным назначением файла управление трафиком краулеров, чтобы не перегружать сайт запросами ^[2]. Для этого закрывают служебные разделы, страницы внутреннего поиска, сортировки и фильтры, которые порождают множество почти одинаковых URL (см. «Краулинговый бюджет»).

Параметры URL в Яндексе. Для UTM-меток, идентификаторов сессий и других незначащих параметров Яндекс предлагает Clean-param: директива помогает избежать дублей и передать накопленные показатели основному URL ^[10].

Указание карты сайта. Строка Sitemap с абсолютным адресом поддерживается Google и Яндексом ^{[3; 6]}; Google допускает несколько таких строк ^[3].

Медиафайлы. Google допускает использование robots.txt, чтобы изображения, видео и аудио не появлялись в его поиске, но это не помешает другим сайтам ссылаться на эти файлы ^[2].

Тестовые копии сайта. Закрытие стейджинга через Disallow: / надёжным скрытием не является: для конфиденциального содержимого Google рекомендует защиту паролем на сервере ^[2]. Обратный риск — перенести на рабочий сайт файл со стейджинга вместе с Disallow: / (вывод).

Переезд. Яндекс учитывает редирект robots.txt на файл другого сайта, что справка называет удобным при переезде ^[6].

Ограничения CMS. В конструкторах вроде Wix или Blogger файл может быть недоступен для прямого редактирования, а управление обходом выполняется через настройки платформы ^[2].

ИИ-краулеры. Владелец сайта может, например, запретить GPTBot и разрешить OAI-SearchBot, чтобы отказаться от использования контента для обучения, но оставаться в поиске ChatGPT ^[12]; по данным OpenAI, на учёт изменений в поиске нужно около 24 часов ^[12]. Запрет Google-Extended не влияет на Google Поиск ^[5]. Файл llms.txt — другой файл с другим назначением, он не заменяет robots.txt (см. «llms.txt»).

Как измерить или проверить

Яндекс Вебмастер — «Анализ robots.txt»

Инструмент проверяет файл на синтаксические ошибки и противоречия и показывает, какие страницы разрешены или запрещены для робота ^[11]. Для сайта, не добавленного в Вебмастер, адрес вводится вручную. В блоке «Доступ к страницам» можно проверить список URL — полных или относительно корня — и увидеть, открыта ли каждая страница ^[11]. Правки можно внести прямо в поле с кодом и проверить их до публикации. История версий (за 6 месяцев, до 100 версий) доступна только после подтверждения прав на сайт ^[11].

Google Search Console — отчёт «robots.txt»

Отчёт показывает, какие файлы robots.txt Google нашёл для 20 основных хостов сайта, когда они проверялись, статус загрузки, предупреждения и ошибки; история охватывает последние 30 дней ^[4]. Отчёт доступен только для ресурсов уровня домена (доменный ресурс или ресурс с префиксом URL без пути). После исправления ошибки можно запросить повторное сканирование файла. Закрыт ли конкретный URL, проверяют инструментом проверки URL ^[4]. Разработчики могут проверять файлы локально с помощью открытой библиотеки Google для разбора robots.txt ^[4]; по описанию в репозитории, это код, который Googlebot использует в работе, с небольшими изменениями ^[15].

Логи сервера

По строке User-agent в логах видно, какие роботы запрашивают /robots.txt и как часто (см. «Лог-файлы сервера»).

Мини-инструмент на этой странице

Инструмент помогает понять, как правила файла применятся к конкретному адресу.

1. Вставьте текст robots.txt в поле «Текст robots.txt».
2. Укажите URL или путь.
3. Выберите User-agent: *, Googlebot, YandexBot, GPTBot, OAI-SearchBot или Google-Extended.
4. Выберите логику: «RFC 9309 / Google» или «Яндекс».

Режимы различаются выбором группы. В режиме «Яндекс» группа Yandex подавляет *, а группа конкретного робота — и Yandex, и * ^[8]. Режим «RFC 9309 / Google» опирается на общее для них правило: группы одного робота объединяются, а группа * применяется, только если своей группы нет ^{[1; 3]}. Там, где RFC 9309 и Google расходятся (например, конфликт правил с подстановочными знаками), этот режим следует логике Google ^[3].

Результат — «разрешено» или «запрещено», а также выбранная группа и сработавшее правило. Линтер предупреждает о BOM, кириллице, правилах вне группы, директивах, которые Google не учитывает (Crawl-delay, Host, Noindex), размере больше 500 KiB и строке Disallow: / для *. Инструмент работает только со вставленным текстом и не загружает файлы сайтов. Его результат — модель интерпретации по открытым правилам; окончательную картину показывают отчёты Яндекс Вебмастера и Google Search Console.

Ошибки, ограничения и спорные вопросы

Disallow не удаляет страницу из поиска. Google прямо пишет, что robots.txt не предназначен для того, чтобы исключить страницу из Google: закрытый URL может появиться в выдаче без описания ^[2]. Яндекс также указывает, что закрытые в robots.txt страницы могут участвовать в поиске; для удаления нужен noindex в HTML или HTTP-заголовке, а саму страницу не следует закрывать в robots.txt, чтобы робот увидел указание ^[6]. Поэтому сочетание noindex и Disallow на одной странице не работает: робот не прочитает noindex ^{[6; 14]}.

Не средство безопасности. RFC 9309 подчёркивает, что протокол не заменяет меры защиты контента, а перечисление путей в файле делает их публично известными ^[1]. Соблюдение правил добровольно: не все поисковые системы их поддерживают ^[2].

Закрытые ресурсы. Если закрыть изображения, скрипты или стили, без которых страница отображается иначе, Google хуже проанализирует такие страницы ^[2].

Ошибки сервера. Ответ 5xx на запрос robots.txt останавливает сканирование Google на первые 12 часов, а по RFC 9309 означает полный запрет ^{[1; 3]}. Коды 401 и 403 Google не рекомендует использовать для ограничения скорости обхода ^[3]. Поведение Яндекса при ответах 4xx и 5xx в его Справке отдельно не описано ^[6].

Синтаксические мелочи. Пути регистрозависимы ^{[1; 3]}; лишний * или $ меняет смысл правила ^[7]; кириллица в файле у Яндекса запрещена ^[6]; файл на http:// или на поддомене не действует для https:// или основного домена ^[3].

Устаревшие директивы. Google поддерживает только четыре поля — user-agent, allow, disallow и sitemap; Crawl-delay и другие поля он не учитывает ^[3]. Яндекс не учитывает Crawl-delay с 2018 года ^[9], а Host отсутствует в его текущем перечне директив ^[6]. Если такие строки остались в файле, они ничего не меняют для этих поисковых систем.

Разные интерпретации. Один и тот же файл может дать разный результат для разных роботов: Google и Яндекс по-разному выбирают группу ^{[3; 8]} и по-разному описывают реакцию на ошибки сервера ^{[3; 6]}, а справка Яндекса прямо предупреждает, что роботы других систем могут толковать директивы иначе ^[6]. Поэтому правила для Яндекса и для остальных роботов стоит проверять отдельно.

Спорный вопрос: эффективность блокировки ИИ. Блокировка опирается на добровольное соблюдение. Компании разделяют токены для обучения и для поиска ^{[5; 12]}, а агент ChatGPT-User, действующий по запросу человека, по словам OpenAI, может не следовать robots.txt ^[12]. Поэтому robots.txt позволяет выразить волю владельца сайта, но не гарантирует, что контент не попадёт в нейросетевые сервисы.

Правовой статус. robots.txt — технический протокол: RFC 9309 указывает, что его правила не являются формой авторизации доступа ^[1]. Правовая оценка парсинга и использования контента выходит за рамки этой статьи.

Частые вопросы

Связанные термины

• Сканирование (краулинг) — skanirovanie
• Поисковый робот — poiskovyy-robot
• Индексация — indeksatsiya
• Мета-тег robots — meta-teg-robots
• noindex — noindex
• Директива Clean-param — direktiva-clean-param
• Карта сайта (sitemap.xml) — karta-sayta
• Краулинговый бюджет — kraulingovyy-byudzhet
• Яндекс Вебмастер — yandeks-vebmaster
• Google Search Console — google-search-console