AI-краулеры и robots.txt: кого пускать на сайт и что это меняет

Не принимайте одно решение для всех AI-ботов

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

Фраза «разрешить нейросетям индексировать сайт» смешивает разные процессы. У AI-платформ есть как минимум три типа доступа.

OpenAI прямо разделяет OAI-SearchBot и GPTBot: можно разрешить первый для участия в поисковых ответах ChatGPT и запретить второй для обучения моделей. ChatGPT-User используется при действиях пользователя, не определяет включение в Search, а правила robots.txt для таких запросов могут не применяться.

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

Anthropic описывает три отдельных агента: Claude-SearchBot для поиска, ClaudeBot для материалов, которые могут участвовать в обучении, и Claude-User для пользовательских запросов. Anthropic заявляет, что эти агенты соблюдают правила robots.txt.

У Google логика устроена иначе. Google-Extended не является отдельной строкой User-Agent в запросах. Это управляющий токен robots.txt, который определяет использование уже собранного Google контента для будущих моделей Gemini и некоторых сценариев grounding. Его запрет не влияет на включение сайта в Google Search и не является сигналом ранжирования.

Практический вывод простой: имя агента еще не объясняет последствия правила. Сначала выясните назначение, затем принимайте решение.

Сначала разделите сайт на зоны

Политика на уровне всего домена часто получается слишком грубой. Корпоративный сайт обычно состоит из зон с разной ценностью и риском.

Это разделение важнее списка модных User-Agent. Если сайт публикует экспертные статьи для привлечения спроса, блокировка поисковых AI-агентов противоречит функции этих материалов. Если тот же домен содержит клиентский портал, его нельзя считать защищенным только потому, что путь записан в Disallow.

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

Выберите модель доступа по цели бизнеса

Я использую последовательность цель -> ограничение -> модель -> владелец -> проверка. Она не требует открывать всех агентов и не заставляет блокировать их из общей тревоги.

Модель 1. Максимальная поисковая видимость

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

Главное ограничение здесь не авторское право «вообще», а состав открытого контура: команда должна заранее понимать, какие материалы являются публичными, актуальными и готовыми к широкому распространению.

Модель 2. Поиск открыт, обучение ограничено

Подходит компании, которая хочет появляться в поисковых ответах, но не хочет давать отдельным поставщикам сигнал на использование контента при обучении будущих моделей. Для OpenAI это означает разные правила для OAI-SearchBot и GPTBot; для Anthropic - для Claude-SearchBot и ClaudeBot; для Google - отдельное решение по Google-Extended.

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

Модель 3. Выборочный открытый контур

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

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

Модель 4. Закрытый продуктовый контур

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

Как может выглядеть политика в robots.txt

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

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

Открыть AI-поиск, но ограничить обучение

User-agent: OAI-SearchBotAllow: /User-agent: PerplexityBotAllow: /User-agent: Claude-SearchBotAllow: /User-agent: GPTBotDisallow: /User-agent: ClaudeBotDisallow: /User-agent: Google-ExtendedDisallow: /

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

Открыть публичное и закрыть служебное

User-agent: OAI-SearchBotDisallow: /admin/Disallow: /account/Disallow: /internal-search/User-agent: PerplexityBotDisallow: /admin/Disallow: /account/Disallow: /internal-search/User-agent: Claude-SearchBotDisallow: /admin/Disallow: /account/Disallow: /internal-search/

Все остальные пути для этих групп остаются доступными, если их не закрывают другие применимые правила. Но сами /admin/ и /account/ все равно должны требовать входа: перечисление пути в публичном файле не является защитой.

Временно закрыть тяжелый раздел

User-agent: OAI-SearchBotDisallow: /reports/User-agent: PerplexityBotDisallow: /reports/User-agent: Claude-SearchBotDisallow: /reports/

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

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

Robots.txt не защищает данные

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

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

Практически это дает три разных задачи:

1. Управление обходом. Robots.txt сообщает поддерживающему его агенту, какие пути не нужно запрашивать.
2. Управление индексированием. Для обычного поиска применяются доступная страница, noindex, canonical и другие механизмы в зависимости от задачи.
3. Защита информации. Авторизация, разграничение прав, непубличное хранилище и серверный контроль.

Проверьте не только файл, но и реальный доступ

Если в robots.txt доступ разрешен, а защита сервера режет того же агента, у компании две политики: одна заявленная и одна реальная. Работает только вторая.

Разрешающее правило не гарантирует, что агент получает страницу. Запрос может остановить CDN, WAF, защита от ботов, ограничение частоты, геоблокировка, обязательный JavaScript или ошибка приложения.

Проверка строится в пять уровней.

1. Файл отвечает корректно

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

2. Публичная страница доступна анонимно

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

3. Защита не отменяет политику

Сопоставьте настройки robots.txt с CDN и WAF. OpenAI и Perplexity публикуют актуальные IP-диапазоны своих агентов; Perplexity рекомендует при настройке WAF проверять и User-Agent, и IP. Одна строка User-Agent может быть подделана, поэтому для разрешающих исключений нельзя полагаться только на имя в заголовке.

4. Логи подтверждают фактическое поведение

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

5. Результат проверяется в продукте

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

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

Назначьте владельца политики

У каждого правила должны быть причина, владелец и дата пересмотра. Иначе через полгода никто не вспомнит, зачем важный раздел закрыли от поиска или, наоборот, оставили открытым.

Проблема robots.txt редко остается только в зоне разработчика. Маркетинг отвечает за страницы, которые должны распространяться. Юристы и владелец контента определяют ограничения использования. Техническая команда реализует правила и контролирует доступ. Руководитель принимает решение, когда цели конфликтуют.

Для каждого правила достаточно короткой карточки:

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

Чек-лист перед изменением доступа

1. Запишите, какой бизнес-результат должен поддержать доступ: поиск, переходы, пользовательское чтение или другое использование контента.
2. Разделите агентов на поиск, обучение и действия по запросу пользователя.
3. Разделите сайт на публичные, слабые, технические, приватные и тяжелые зоны.
4. Проверьте актуальное назначение каждого User-Agent по первичной документации.
5. Согласуйте отдельное решение для поиска и обучения, если платформа дает такой контроль.
6. Убедитесь, что приватные данные защищены авторизацией, а не только Disallow.
7. Проверьте robots.txt на каждом поддомене.
8. Сверьте правила с CDN, WAF, географическими и скоростными ограничениями.
9. Проверьте несколько реальных URL и серверные логи.
10. Назначьте владельца, причину и дату пересмотра каждого нестандартного правила.

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