AI-краулеры в robots.txt: кого пускать и зачем

Строка «User-agent: GPTBot» в robots.txt не решает, попадёт ли сайт в ответы ChatGPT: за поиск у OpenAI отвечает другой робот, OAI-SearchBot, и запрет одного не касается другого. AI-краулеры в robots.txt — это не один «бот нейросети», а набор роботов с тремя разными работами: одни собирают тексты для обучения моделей, другие строят поисковый индекс для ответов, третьи открывают страницу, когда пользователь попросил ассистента её прочитать. Их постоянно путают и закрывают не то, что хотели. Ниже — кто есть кто по документации самих компаний на сентябрь 2026 года, три ошибки, которые были в нашем собственном файле, и способ проверить по логам сервера, дошёл ли нужный робот до страниц, которые продают.

AI-краулер — не один бот, а три разные работы

AI-краулер — это программа компании-разработчика нейросети, которая запрашивает страницы сайта для одной из трёх задач: собрать тексты для обучения моделей, построить поисковый индекс, из которого ассистент берёт источники для ответа, или открыть конкретную страницу по просьбе пользователя. У каждой задачи обычно свой робот со своим именем в заголовке User-Agent, и robots.txt управляет ими по отдельности.

Это различие важнее всего остального в статье. Когда руководитель говорит «закройте сайт от нейросетей», он обычно имеет в виду обучение: не хочет, чтобы тексты компании бесплатно ушли в модель. Когда маркетолог говорит «откройте сайт для нейросетей», он имеет в виду поиск: хочет, чтобы ChatGPT или Алиса называли компанию в ответах. Это разные роботы, и одной строкой обе задачи не решаются. Третья группа, роботы по запросу пользователя, через robots.txt управляется плохо — к ней вернёмся ниже.

Как нейросети выбирают источники и как писать текст, который цитируют, разобрано в статье о GEO для B2B-компаний, а место этой темы в работе с сайтом целиком — в обзоре что такое генеративное SEO. Здесь — только технический слой: какой робот что делает и что написать в файле.

Кто есть кто: роботы по документации компаний на сентябрь 2026

Таблица собрана только по официальным страницам компаний: OpenAI, Anthropic, Perplexity, Google, Яндекса, Apple, Common Crawl и Meta. Если назначение робота не описано в первоисточнике, в таблице его нет.

Выделены роботы поиска — от них зависит, окажется ли сайт в ответах ассистентов с поиском. Meta Platforms Inc. признана экстремистской организацией и запрещена в России; её роботы приведены только потому, что они ходят по сайтам и владельцу полезно знать их имена.

Имён Claude-Web и anthropic-ai, которые кочуют по готовым шаблонам, в таблице нет: текущая справка Anthropic их не перечисляет.

У OpenAI три робота и одна оговорка про общий обход

Документация OpenAI прямо говорит, что настройки роботов независимы: можно разрешить OAI-SearchBot, чтобы появляться в поиске ChatGPT, и запретить GPTBot, чтобы контент не шёл в обучение. Сценарий «поиск без обучения» поддерживается официально.

Но там же есть фраза, которую почти никто не замечает: если сайт разрешил оба робота, OpenAI может использовать результаты одного обхода для обеих задач, чтобы не обходить сайт дважды. Следствие для логов: много визитов GPTBot и почти ни одного OAI-SearchBot ещё не значит, что поиску ChatGPT сайт не интересен. Имя в заголовке говорит, кто пришёл, но не всегда — для чего будут использованы данные.

ChatGPT-User, по словам OpenAI, веб автоматически не обходит и не определяет, появится ли контент в поиске, а поскольку его действия инициирует пользователь, правила robots.txt к нему могут не применяться. Попаданием в поиск компания предлагает управлять только через OAI-SearchBot. Четвёртый робот, OAI-AdsBot, касается только рекламодателей в ChatGPT.

Деталь для логов: запрашивая сам файл, OAI-SearchBot и GPTBot могут добавлять в User-Agent пометку «robots.txt» — так чтение правил отличается от обхода страниц.

Anthropic, Perplexity и Meta: те же три роли, разное отношение к запретам

Anthropic устроила роботов по той же схеме: ClaudeBot для обучения, Claude-SearchBot для поиска, Claude-User для запросов пользователей. Разница с OpenAI в третьей роли: в справочной статье сказано, что роботы Anthropic соблюдают директивы robots.txt, а Claude-User даёт владельцам сайтов контролировать, что доступно через запросы пользователей. Anthropic поддерживает и нестандартную директиву Crawl-delay, которой можно замедлить обход, не запрещая его, а блокировать роботов по IP не советует: так робот не прочитает сам robots.txt.

У Perplexity и Meta с третьей ролью строже. Perplexity пишет, что Perplexity-User, как правило, игнорирует robots.txt, потому что запрос инициировал человек; Meta — что meta-externalfetcher может обходить файл по той же причине.

Практический вывод: надёжно запретить «третью группу» по документации можно только у Anthropic. Если человек вставил ссылку на вашу страницу в чат с ассистентом, страница, скорее всего, будет прочитана. Для публичного маркетингового сайта это нормально — так же её открыл бы сам человек в браузере.

Google-Extended и Applebot-Extended — переключатели, а не роботы

Google пишет, что у Google-Extended нет отдельной строки User-Agent: обход выполняют обычные роботы Google, а токен в robots.txt служит только управляющим сигналом. Apple говорит короче: Applebot-Extended не обходит веб-страницы. В логах сервера этих имён не будет никогда.

По документации Google, Google-Extended решает, можно ли использовать контент для обучения будущих моделей Gemini и для grounding — опоры ответа на найденные источники — в приложениях Gemini и Vertex AI. На включение в Google Поиск и ранжирование он не влияет. Запрет Applebot-Extended исключает сайт из обучения моделей Apple, но не из поиска в её экосистеме.

Самое неприятное: AI Overviews и AI Mode токен Google-Extended не управляет. Для них Google предлагает те же средства, что и для обычной выдачи: nosnippet, data-nosnippet, max-snippet и noindex, — то есть убрать сайт из AI Overviews можно только ценой его вида в обычном поиске. Там же Google пишет, что для появления в этих функциях не нужны особые файлы или разметка, — что это значит для llms.txt, разобрано в статье о llms.txt.

YandexAdditional управляет ответами Алисы, а не индексом Яндекса

В справке Вебмастера YandexAdditional и YandexAdditionalBot описаны так: они учитываются при обработке robots.txt, чтобы ограничить отображение контента страницы в быстрых ответах с YandexGPT и в ответах Поиска с Алисой, применяются к страницам, проиндексированным основным роботом, и сами запросов для индексирования не совершают.

В той же таблице у обоих указано, что общие правила robots.txt они не учитывают. Значит, «User-agent: *» с запретом раздела на показ в ответах Алисы не распространяется — нужна отдельная группа с именем YandexAdditional. В блоге Яндекса для вебмастеров от 16 апреля 2024 года, в посте о запуске Нейро, приведён именно такой пример с «Disallow: /» и сказано, что применение директивы занимает от 2 до 14 дней.

Об обучении моделей через этот токен в документации Яндекса ничего нет. Поэтому честная формулировка: YandexAdditional — переключатель показа в генеративных ответах Яндекса, а не «запрет обучения YandexGPT». Первоисточника о том, как запретить второе, я не нашёл.

Для российского B2B-сайта это, пожалуй, главная строка файла: закрыв YandexAdditional «на всякий случай», компания исчезает из ответов Алисы, а в обычной выдаче ничего не меняется, и этого месяцами никто не замечает.

Пускать или закрывать — зависит от того, что продаёт сайт

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

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

Контент сам по себе и есть продукт. Платная база знаний, аналитика по подписке, курсы, справочник, который собирали годами. Здесь обучение стоит закрыть, а поиск оставить: ассистент сошлётся на страницу, человек придёт на сайт, но модель не выучит то, за что клиенты платят. Раздельная настройка есть у OpenAI, Anthropic, Apple и Meta.

Сайт вообще не должен попадать в ответы. Внутренние порталы, личные кабинеты, тестовые копии. Для них robots.txt — неправильный инструмент: RFC 9309, стандарт этого файла, прямо говорит, что он не заменяет мер защиты, а перечисленные в нём пути видны любому. Такие разделы закрывают авторизацией.

Контраргумент, который звучит всерьёз: если закрыть обучение, модели будут знать о компании меньше. Возможно. Но ни одна компания не публикует, как запрет обучающего робота влияет на ответы. Ставка на обучение не измеряется, ставка на поиск измеряется в логах и в ответах. Исключение — Google-Extended: его запрет выключает ещё и grounding в приложениях Gemini.

Когда AI-краулеры не стоят вашего времени

Если в robots.txt нет групп с именами AI-роботов, а общая группа «User-agent: *» ничего важного не запрещает, сайт уже открыт для всех, кто соблюдает стандарт. Дописывать явные разрешения не нужно — ниже видно, как они могут навредить.

Если сайт почти не получает обращений из поиска вообще, начинать с AI-краулеров я бы не стал: узкое место, скорее всего, в том, что на сайте мало страниц, отвечающих на вопросы клиентов. А экономику канала по визитам роботов считать рано, пока он не принёс ни одной заявки, — как её считать, разобрано в статье сколько стоит клиент из нейросети.

И если вы боитесь нагрузки от роботов, запрет в robots.txt — не первый шаг. Сначала посмотрите в логах, кто на самом деле её создаёт: запросы, которые только представляются известными роботами, существуют, и Common Crawl прямо предупреждает о поддельных CCBot.

Разбор нашего robots.txt: три ошибки в файле с правильной целью

Лучший пример, который у меня есть, — прежняя версия robots.txt нашего сайта 404ai.ru. Цель у неё была верная: сайт агентства открыт и для поисковиков, и для нейросетей. Но устроен файл был так, как устроено большинство файлов, собранных из советов в интернете.

В начале стояла общая группа «User-agent: *» с «Allow: /» и запретами служебных разделов: /thank-you/, /partials/, /react/, /scripts/, /assets/vendor/. Ниже шли отдельные группы для GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, Perplexity-User, ClaudeBot, Claude-Web, anthropic-ai, Google-Extended, CCBot и YandexAdditional — в каждой одна строка «Allow: /».

Ошибка первая: явные разрешения отменяли запреты. По RFC 9309 робот ищет группу со своим именем, а группу «*» использует, только если своей не нашёл. Google в документации формулирует жёстче: группы конкретного робота и общая группа не объединяются. Для GPTBot, ClaudeBot и остальных из списка действовала только их строка «Allow: /», а запреты служебных разделов на них не распространялись. Файл, задуманный как «всё то же самое плюс приглашение», пускал AI-роботов туда, куда не пускал остальных.

Ошибка вторая: имена, которых нет в документации. Claude-Web и anthropic-ai в текущей справке Anthropic не перечислены, а Claude-SearchBot и Claude-User в файле отсутствовали. Вреда было немного — новые роботы Anthropic попадали в общую группу, где сайт тоже открыт, — но файл создавал ложную уверенность, что «с Anthropic всё настроено».

Ошибка третья: разрешения для тех, кто не ходит. Google-Extended и YandexAdditional страниц не запрашивают, а запрещено для них ничего не было. Строки «Allow: /» ничего не меняли и только мешали читать файл.

В сентябре 2026 года мы файл переделали: отдельные группы для AI-роботов убрали, осталась одна общая группа с запретами служебных путей и строка Sitemap. В комментарии в начале файла записано, почему групп для AI-роботов нет, — чтобы их не вернули «для надёжности». Вывод для любого сайта: если цель — пустить всех, достаточно одной общей группы. Отдельная группа нужна, только когда роботу надо запретить или разрешить что-то сверх общего, и тогда в неё придётся повторить все общие запреты.

Пример robots.txt, который разводит обучение и поиск

Первый вариант — для сайта, открытого всем. Так выглядит наш текущий файл без комментариев: служебные запреты действуют на любого робота, у которого нет своей группы, а своей нет ни у кого.

Второй вариант — для сайта, где контент и есть продукт: поиск открыт, обучение закрыто. Стандарт разрешает перечислить несколько строк User-agent подряд, и правила группы действуют на всех перечисленных. Общая группа та же, что выше; к ней добавляется блок:

Роботы поиска — OAI-SearchBot, Claude-SearchBot, PerplexityBot — своих групп здесь не имеют и подчиняются общей: для них действуют служебные запреты, остальное открыто. YandexAdditional тоже не упомянут, значит, показ в ответах Алисы не ограничен; если его нужно ограничить, для него пишется отдельная группа — общие правила он, по справке Яндекса, не читает.

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

Две детали, которые ломают даже правильный файл. Robots.txt действует только на тот хост, где лежит: Anthropic прямо просит повторить запрет на каждом поддомене, Google пишет то же. И изменения учитываются не мгновенно: RFC 9309 допускает кэширование файла до 24 часов, OpenAI и Perplexity говорят о 24 часах, Яндекс — о 2–14 днях для YandexAdditional.

Логи сервера покажут, дошёл ли робот, но не каждого робота в них видно

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

Шаг первый: посчитать визиты по именам. Для nginx с обычным форматом журнала хватит одной команды:

Google-Extended, Applebot-Extended и YandexAdditional в списке нет намеренно: они не делают запросов, и их отсутствие в журнале — норма.

Шаг второй: посмотреть, что робот получил. Визит с ответом 403 или 503 хуже, чем отсутствие визита: робот пришёл, а страницу не увидел. В стандартном формате журнала nginx код ответа стоит в девятом поле:

Если там много 403 при открытом robots.txt, запрет стоит не в файле, а в защите от ботов у хостинга, CDN или межсетевого экрана. Частая история: robots.txt все проверили, а фильтр по User-Agent включили годом раньше и забыли.

Шаг третий: убедиться, что это не подделка. Строку User-Agent может отправить кто угодно. OpenAI, Anthropic, Perplexity и Common Crawl публикуют списки IP-адресов своих роботов в JSON, у Anthropic это claude.com/crawling/bots.json. Для Google, Яндекса и Apple работает обратный DNS-запрос: по IP узнать имя хоста, проверить окончание (у Яндекса — yandex.ru, yandex.net или yandex.com, у Apple — applebot.apple.com) и прямым запросом убедиться, что имя указывает на тот же IP.

Где метод ломается. Журнал показывает, кто пришёл, но не для чего, и ничего не говорит о том, процитировали ли вас. Логи отвечают на один вопрос — открыт ли путь, зато точно.

Пилот на месяц: какую цифру смотреть и когда остановиться

Доступ для роботов — не цель, а условие. Цель — чтобы ассистенты называли компанию, когда клиент спрашивает о задаче, и из этого приходили обращения. По методу «Цель → метрика» (наш подход) сначала договариваются, какая цифра должна измениться, потом правят файл. Пилот — месяц и три показателя.

• Доступ. Отобрать 10–20 страниц, ближайших к деньгам: услуги, цены, ответы на частые вопросы. Раз в неделю проверять по журналу, заходили ли на них OAI-SearchBot, Claude-SearchBot, PerplexityBot и какой код ответа получили.
• Присутствие. Составить список из 20 вопросов, которые клиенты задают до покупки, и раз в неделю задавать их ChatGPT с поиском, Perplexity и Алисе, отмечая, назван ли сайт среди источников.
• Обращения. Считать заявки из нейросетей; как отличить такие переходы от прямых заходов, разобрано в статье о трафике из нейросетей в аналитике.

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

На опубликованном примере: в кейсе юридической компании технический слой, включая открытый доступ для AI-краулеров, был одним из четырёх слоёв работы, а не единственным. Если проверка показала, что дело в страницах и семантике, это работа другого масштаба — её мы делаем в рамках услуги «Генеративное SEO».

Что проверить в своём файле до конца недели

Откройте robots.txt и ответьте на четыре вопроса. Повторены ли в группах AI-роботов все запреты общей группы — или таких групп нет вовсе. Нет ли забытой группы YandexAdditional с «Disallow». Совпадает ли решение по роботам обучения с тем, что сайт продаёт. Лежит ли нужный файл на поддоменах со страницами для клиентов.

Потом возьмите журнал доступа за неделю и выполните две команды из раздела про логи. Если OAI-SearchBot, Claude-SearchBot и PerplexityBot приходят на страницы услуг и получают 200, технический слой в порядке и следующая неделя должна уйти на тексты. Если не приходят или получают 403, вы нашли причину, по которой нейросети молчат о компании, — и она не в качестве текстов.