Каких AI-краулеров пускать на сайт и как настроить robots.txt для AI-видимости

Закрыть сайт от всех AI-ботов кажется безопасным решением: меньше копирования, меньше нагрузки, больше контроля над контентом. На практике так можно не сохранить трафик, а потерять новые точки видимости — в ChatGPT Search, Perplexity, Claude, Copilot и AI-ответах поисковиков. Поэтому в robots.txt сегодня важно не просто запрещать, а понимать, каких ботов пускать ради поиска и каких закрывать от обучения моделей.

Закрыть сайт от всех AI-ботов кажется безопасным решением: меньше копирования, меньше нагрузки, больше контроля над контентом. На практике так можно не сохранить трафик, а потерять новые точки видимости — в ChatGPT Search, Perplexity, Claude, Copilot и AI-ответах поисковиков. Поэтому в robots.txt сегодня важно не просто запрещать, а понимать, каких ботов пускать ради поиска и каких закрывать от обучения моделей.

Пытаться управлять всеми AI-ботами через общее правило вроде «запретить всех подозрительных краулеров» бессмысленно и опасно. Так можно случайно закрыть сайт от AI-поиска, но оставить открытым использование контента для обучения моделей — или наоборот.

Поэтому сначала нужно ответить на три вопроса:

• хотите ли вы, чтобы сайт появлялся в AI-поиске и ответах со ссылками;

• готовы ли вы, чтобы контент использовался для обучения будущих моделей;

• какие страницы должны быть доступны пользователям и AI-ассистентам по прямому запросу.

Только после этого имеет смысл настраивать robots.txt, meta robots, WAF и правила на уровне сервера.

Robots.txt управляет обходом сайта, но не защищает контент от AI-систем

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

Если страницу нужно исключить из индекса, используют noindex, meta robots или HTTP-заголовок X-Robots-Tag. Если контент нельзя показывать посторонним вообще, нужны авторизация, платный доступ, ограничения на уровне сервера или CDN/WAF. Robots.txt в таких случаях может быть дополнительным сигналом, но не основным способом защиты.

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

Поэтому robots.txt не решает все задачи управления AI-доступом. Он не заменяет:

• noindex, meta robots и X-Robots-Tag;

• авторизацию, платный доступ и серверные ограничения;

• WAF/CDN-правила;

• управление сниппетами в Google и Bing;

• проверку логов, IP и подлинности user-agent;

• юридическое лицензирование контента.

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

AI-ботов нужно делить по функциям, а не блокировать общей директивой

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

Запретить всех ботов подряд и при этом не просадить видимость сайта не получится. Следует отдельно управлять поисковыми краулерами, ботами для AI-поиска, ботами для обучения, пользовательскими агентами и токенами отказа от использования контента.

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

В Яндексе обычная индексация и попадание в «Нейро» управляются разными правилами

Основной краулер Яндекса — YandexBot. Он отвечает за обычное индексирование сайта в поиске. Закрывать его нельзя, если вам важна видимость в Яндексе.

Для сервиса «Нейро» у Яндекса есть отдельный робот — YandexAdditional. Если владелец сайта не хочет, чтобы страницы использовались как источники ответов в «Нейро», для этого агента можно прописать запрет в robots.txt.

Такая директива не равна блокировке обычной органической индексации. Она не закрывает сайт от YandexBot и не должна сама по себе выбивать страницы из классической выдачи. Но она может ограничить участие контента в генеративных ответах Яндекса.

Здесь важно учитывать логику вашего бизнеса. Для медиа, справочников и контентных проектов может быть соблазн закрыться от быстрых AI-ответов, чтобы пользователь чаще переходил на сайт. Но для коммерческого сайта, экспертного блога или B2B-компании такая блокировка может быть спорной: вы отказываетесь от дополнительной точки присутствия в AI-выдаче. Если цель — максимальная AI-видимость, YandexAdditional лучше не закрывать. Если цель — протестировать влияние «Нейро» на переходы или защитить отдельный тип контента, ограничение можно использовать осознанно и обязательно фиксировать дату изменения robots.txt.

С другими российскими AI-системами ситуация сложнее. «Алиса» и голосовой поиск во многом опираются на инфраструктуру Яндекса, поэтому для управления доступом обычно важны правила для YandexBot и YandexAdditional.

У GigaChat Сбера нет публичного краулера

GigaChat Сбера может находить информацию в интернете и формировать ответы с использованием внешних источников, но у него нет стабильно документированного краулера, которым вебмастер мог бы управлять через robots.txt так же прозрачно, как OAI-SearchBot или Googlebot.

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

• noindex на страницах, которые не должны попадать в поиск;

• авторизацию или платный доступ для закрытого контента;

• ограничения на уровне сервера;

• WAF/CDN-правила;

• анализ логов и фактических обращений к сайту.

В OpenAI можно разрешить ChatGPT Search и запретить обучение на контенте сайта

У OpenAI есть несколько агентов с разными функциями. Их нельзя закрывать или, наоборот, разрешать как одну общую группу.

OAI-SearchBot — это бот для поисковых функций ChatGPT. Он используется, чтобы сайты могли появляться в результатах ChatGPT Search. Если заблокировать OAI-SearchBot, сайт может перестать появляться в ответах ChatGPT Search, хотя в отдельных случаях может оставаться навигационной ссылкой. Поэтому если цель — AI-видимость, OAI-SearchBot обычно нужно разрешать.

GPTBot — это другой бот. Он связан не с показом сайта в ChatGPT Search, а с обходом контента, который может использоваться для обучения будущих моделей OpenAI. Если компания хочет появляться в ChatGPT Search, но не хочет отдавать материалы для обучения будущих базовых моделей, не нужно закрывать OpenAI целиком: достаточно оставить доступ OAI-SearchBot и закрыть GPTBot.

ChatGPT-User — пользовательский агент. Он может приходить на сайт, когда пользователь ChatGPT или Custom GPT просит открыть конкретную страницу, проверить ссылку или получить информацию с сайта. Это не автоматический поисковый краулер и не механизм попадания в ChatGPT Search. Управлять видимостью в поиске ChatGPT через ChatGPT-User не нужно — для этого есть OAI-SearchBot.

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

Итак, если цель — AI-видимость в поиске ChatGPT, но без использования контента для обучения, логика такая: OAI-SearchBot оставляем открытым, GPTBot закрываем, а ChatGPT-User рассматриваем отдельно как пользовательский сценарий. Полный пример robots.txt для этого сценария приведем ниже.

Для видимости в Perplexity важно пускать PerplexityBot и отдельно проверять WAF и логи

У Perplexity есть два основных публично описанных агента: PerplexityBot и Perplexity-User.

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

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

В случае с Perplexity нельзя полагаться только на robots.txt. Cloudflare в 2025 году публично заявлял, что наблюдал случаи скрытого краулинга: смену строки User-agent, IP-адресов и автономных систем (ASN), а также попытки обхода ограничений. Это не значит, что каждый сайт столкнется с такой проблемой, но это хороший аргумент не считать robots.txt единственным инструментом контроля.

Если у сайта подключен WAF или CDN, нужно проверять:

• не блокируются ли нужные боты Perplexity на уровне WAF;

• совпадает ли строка User-agent с официальными диапазонами IP-адресов;

• появляются ли обращения в серверных логах и логах CDN;

• не идет ли подозрительный трафик под видом обычного браузера.

Для AI-видимости важно не только прописать разрешение в robots.txt, но и убедиться, что инфраструктура сайта действительно пропускает нужные запросы. Полный пример правил для Perplexity приведем ниже.

У Claude поисковый бот, обучающий бот и пользовательский агент решают разные задачи

Anthropic разделяет своих ботов по функциям. Для вебмастера важны три сущности: ClaudeBot, Claude-SearchBot и Claude-User.

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

Claude-SearchBot нужен для улучшения поисковых ответов Claude. Он анализирует онлайн-контент, чтобы повышать релевантность и точность поисковых результатов. Если закрыть Claude-SearchBot, сайт может хуже появляться в пользовательских поисковых ответах Claude. Поэтому если цель — AI-видимость, его лучше разрешить.

Claude-User приходит, когда пользователь Claude просит получить контент с конкретной страницы. Anthropic указывает, что отключение Claude-User может помешать системе получить ваш контент по пользовательскому запросу и снизить видимость в пользовательском веб-поиске.

Anthropic поддерживает нестандартную директиву Crawl-delay. Это может быть полезно, если ClaudeBot или другие боты Anthropic создают слишком высокую нагрузку.

Пример:

User-agent: ClaudeBot
Crawl-delay: 1

Crawl-delay не является универсальным стандартом, и разные поисковики относятся к нему по-разному. Поэтому его не стоит считать общим способом управления всеми AI-краулерами. Для контроля нагрузки лучше дополнительно смотреть серверные логи, настройки CDN/WAF и частоту обхода там, где платформа дает такой инструмент.

Если цель — сохранить видимость в Claude Search, но ограничить обучение, логика такая: Claude-SearchBot и Claude-User оставляем открытыми, а ClaudeBot закрываем. Полный пример robots.txt приведем ниже.

В Google нельзя закрывать Googlebot, если сайту важны Search, AI Overviews и AI Mode

С Google легче всего ошибиться, потому что у него нет отдельного AI Overviews bot, которого можно просто разрешить или запретить.

Googlebot — основной краулер Google Search. Для AI Overviews и AI Mode действуют обычные требования Google Search: страница должна быть проиндексирована, доступна Googlebot и иметь право показываться в поиске со сниппетом. Поэтому блокировать Googlebot нельзя, если вы хотите оставаться в Google Search, AI Overviews и AI Mode.

Google-Extended — это специальный robots.txt-токен, который управляет тем, может ли Google использовать уже полученный контент в отдельных сценариях, связанных с Gemini: например, для обучения будущих моделей и использования контента как источника в Gemini Apps / Vertex AI. Именно поэтому искать в серверных логах отдельного робота Google-Extended бессмысленно. Обход выполняют обычные агенты Google, а Google-Extended задает политику использования контента.

Google-Extended не имеет обратной силы: он помогает задать политику использования контента после настройки, но не является инструментом удаления уже обработанных данных из AI-систем Google.

Если компания хочет сохранить Google Search и AI Overviews, но ограничить использование контента через Google-Extended, нужно оставить Googlebot открытым и закрыть Google-Extended. Полный пример правил приведем ниже.

Disallow: / для Google-Extended не убирает страницу из Google Search и не является способом отключить AI Overviews. Для управления тем, как контент может отображаться в AI-функциях Google Search, нужны другие инструменты.

Если нужно ограничить использование фрагментов страницы в Google Search, AI Overviews или AI Mode, смотреть нужно не только на robots.txt, а на настройки предварительного просмотра:

• nosnippet;

• max-snippet;

• data-nosnippet;

• robots meta;

• X-Robots-Tag.

Эти настройки работают только если Googlebot может получить доступ к странице и прочитать соответствующие директивы. Поэтому нельзя одновременно закрыть страницу от Googlebot в robots.txt и ожидать, что он увидит noindex или nosnippet в коде.

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

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

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

Для Bing и Copilot важен Bingbot

Искать отдельного CopilotBot обычно не нужно: Microsoft связывает AI-поиск и Copilot-сценарии с инфраструктурой Bing. Поэтому для сайта, которому важны Bing и Copilot, главное правило — не ломать доступ Bingbot.

В большинстве случаев Bingbot не нужно отдельно прописывать, если он не закрыт общим правилом. Но если на сайте уже есть сложные ограничения для User-agent: *, лучше явно проверить, что Bingbot не попал под случайный запрет.

Управление видимостью в Bing/Copilot — это не только robots.txt. В обновленных Bing Webmaster Guidelines отдельно описано влияние метадиректив:

• NOARCHIVE предотвращает использование контента в ответах Copilot и результатах, где контент используется как источник;

• NOCACHE ограничивает Copilot использованием URL, заголовка и сниппета;

• NOSNIPPET и DATA-NOSNIPPET могут ограничивать текстовые цитаты и качество отображения источника.

То есть для Microsoft управление AI-видимостью находится на стыке robots.txt, индексации и метадиректив. Если сайт хочет цитироваться в Copilot, не стоит бездумно закрывать Bingbot или злоупотреблять директивами, которые обрезают доступ к содержанию страницы.

Для AI-видимости обычно пускают поисковых ботов, а обучающих закрывают точечно

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

Файл robots.txt должен сохранять AI-видимость, а не закрывать сайт от AI

Ниже примерный шаблон. Его нельзя копировать без адаптации: служебные разделы, поддомены, CMS, параметры, Sitemap и бизнес-логика у всех разные.

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

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search/
Allow: /

Для Яндекса оставляем индексацию и не закрываем YandexAdditional при цели AI-видимости:

User-agent: YandexBot
Allow: /

User-agent: YandexAdditional
Allow: /

Для OpenAI разрешаем ChatGPT Search и закрываем GPTBot от обучения:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

ChatGPT-User можно отдельно прописать в политике доступа, если сайту важно открываться по прямым пользовательским запросам в ChatGPT. Но это не бот для ChatGPT Search и не надежный инструмент защиты контента: если страницу действительно нужно закрыть, используйте авторизацию, серверные правила или WAF.

Для Perplexity разрешаем поискового бота и пользовательский агент:

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

Для Claude разрешаем поиск и пользовательский доступ, а ClaudeBot закрываем от обучения:

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

Для Google оставляем Googlebot и закрываем Google-Extended от использования контента:

User-agent: Googlebot
Allow: /

User-agent: Google-Extended
Disallow: /

Для Bing и Microsoft оставляем доступ Bingbot:

User-agent: Bingbot
Allow: /

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

Важно:

• Allow: / часто не обязателен, потому что доступ разрешен по умолчанию, но в шаблоне он оставлен для ясности политики;

• если у сайта несколько поддоменов, для каждого нужен свой robots.txt;

• robots.txt должен лежать в корне конкретного хоста;

• служебные разделы нужно адаптировать под сайт;

• после правки нужно проверить файл в Google Search Console, Bing Webmaster Tools и Яндекс Вебмастере;

• дату изменения robots.txt лучше зафиксировать, чтобы потом связать изменения с динамикой индексации и AI-видимости.

Разным сайтам нужны разные сценарии видимости

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

Сценарий 1: максимальная AI-видимость

Подходит для медиа, блогов, B2B-сайтов, экспертных компаний, SaaS-проектов, образовательных платформ и брендов, которым важны цитирования в AI-ответах.

Что делать:

• не блокировать Googlebot, Bingbot, YandexBot;

• разрешить OAI-SearchBot, PerplexityBot, Claude-SearchBot;

• не закрывать YandexAdditional, если важна видимость в «Нейро»;

• отдельно решить, готовы ли вы разрешать обучающих ботов;

• следить за нагрузкой, логами и WAF.

Этот сценарий не гарантирует рост трафика, но сохраняет техническую возможность появляться в AI-ответах.

Сценарий 2: видимость без обучения

Подходит компаниям, которые хотят быть представлены в AI-поиске, но не хотят отдавать контент для обучения будущих моделей.

Что делать:

• разрешить OAI-SearchBot, PerplexityBot, Claude-SearchBot, Googlebot, Bingbot, YandexBot;

• запретить GPTBot, ClaudeBot, Google-Extended;

• аккуратно работать с ChatGPT-User, Perplexity-User, Claude-User и Google-Agent;

• понимать, что пользовательские агенты не всегда контролируются robots.txt;

• проверять WAF/CDN, чтобы нужные поисковые боты не блокировались случайно.

Это наиболее сбалансированный сценарий для большинства коммерческих сайтов.

Сценарий 3: закрытый или лицензируемый контент

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

Что делать:

• учесть, что robots.txt недостаточно;

• настроить авторизацию, платный доступ, WAF, CDN-правила;

• для Google и Bing дополнительно настроить robots meta, X-Robots-Tag и сниппеты;

• отдельно решить, какие промо-страницы оставить открытыми для AI-видимости;

• нельзя защищать платный или приватный контент только через robots.txt.

В этом сценарии сайт может сознательно жертвовать частью AI-видимости ради контроля доступа к контенту.

Перед публикацией robots.txt нужно проверить хост, sitemap, WAF и логи

Перед выкладкой нового robots.txt стоит пройти короткий технический чек-лист.

• Файл лежит по адресу /robots.txt в корне нужного хоста.

• Для каждого поддомена есть свой robots.txt.

• Файл отдает 200 OK.

• Нет случайного Disallow: / для User-agent: *.

• Не закрыты CSS и JS, если они нужны для рендеринга важных страниц.

• Не закрыты Googlebot, Bingbot и YandexBot.

• Поисковые боты не закрыты вместе с обучающими ботами.

• Sitemap указан корректно.

• Правила проверены в Google Search Console, Bing Webmaster Tools и Яндекс Вебмастере.

• После выкладки проверены серверные логи и логи CDN.

• WAF/CDN не блокирует нужных ботов.

• IP-диапазоны сверяются с официальной документацией, если платформа их публикует.

• Дата изменения robots.txt зафиксирована в журнале технических изменений.

• Изменения сопоставляются с динамикой индексации, AI-видимости и логами обращений.

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

Строка User-agent в логах не доказывает, что на сайт пришел настоящий AI-бот

User-agent легко подделать, поэтому доверять только названию бота в логах нельзя.

Для проверки подлинности используют несколько признаков:

• IP-адрес из официального диапазона;

• обратная DNS-проверка;

• поведение робота;

• частотность обращений;

• путь обхода;

• соответствие запросов опубликованной документации.

Для OpenAI и Perplexity есть опубликованные диапазоны IP-адресов. Google и Яндекс также дают способы проверки своих роботов, включая обратную DNS-проверку. У Anthropic есть список IP-источников, но компания отдельно предупреждает, что грубая блокировка IP может помешать ботам прочитать robots.txt.

Если у сайта настроен WAF, лучше строить правила не только по строке User-agent. Более надежная схема — сочетать User-agent, IP-адрес, обратную DNS-проверку и поведенческие признаки.

Читайте также:

Почему резко упал поисковый трафик: все причины

Разметка сайта для AI-видимости: что надо знать маркетологу

Как подготовить контент для поиска в 2026 году: чек-лист