Коротко: AI-краулеры уже нельзя воспринимать как один большой «бот искусственного интеллекта». У разных систем разные задачи: одни ищут страницы для AI-поиска, другие забирают контент для обучения моделей, третьи открывают конкретную страницу по запросу пользователя. Поэтому правильная стратегия не «запретить всех» и не «пустить всех», а разделить доступ по целям.
Этот материал — русская редакторская адаптация статьи Momentic AI Search Crawlers & Bots, дополненная практическими комментариями для SEO-специалистов и владельцев сайтов. Это не дословный перевод, а читабельная версия с фокусом на то, что делать в реальном проекте.
Почему тема стала важной
Раньше вопрос краулеров был относительно понятным: Googlebot, YandexBot, Bingbot и несколько сервисных роботов. Если сайт доступен, страницы индексируются, дальше работают классические поисковые факторы. Сейчас поверх этого появился новый слой: AI-поиск, генеративные ответы, ассистенты и модели, которые могут использовать веб-контент по-разному.
Для SEO это меняет задачу. Важно не только попасть в обычную выдачу, но и не потерять возможность быть источником в AI-ответах. Одновременно у издателей, SaaS-проектов, медиа и e-commerce появляется нормальный страх: а не отдать ли весь контент на обучение моделей бесплатно? Ответ зависит от типа сайта, ценности контента и бизнес-целей.
Главное различие: поиск, обучение и пользовательский fetch
Условно AI-ботов можно разделить на три группы.
- Поисковые AI-краулеры. Они помогают продукту находить и показывать сайты в AI-поиске или ответах с веб-источниками. Если закрыть такого бота, можно потерять видимость в соответствующей AI-поверхности.
- Боты для обучения и улучшения моделей. Они собирают данные, которые потенциально могут использоваться для тренировки или улучшения foundation-моделей. Их можно закрывать, если защита контента важнее потенциальной пользы.
- Пользовательские fetcher’ы. Они приходят не в рамках массового обхода, а когда пользователь просит ассистента открыть конкретную страницу, проверить ссылку, пересказать документ или выполнить действие.
Ошибка многих сайтов — писать одно общее правило для всех AI-ботов. Это удобно, но грубо. Так можно случайно закрыть канал, через который сайт мог бы попадать в ответы ChatGPT Search или другие AI-интерфейсы.
Что означают ключевые user-agent’ы
| Бот / токен | Для чего нужен | Как относиться |
|---|---|---|
OAI-SearchBot |
Поисковый бот OpenAI для отображения сайтов в поисковых функциях ChatGPT. | Обычно стоит разрешить, если вам нужна видимость в ChatGPT Search. |
GPTBot |
Краулер OpenAI для данных, которые могут использоваться при обучении и улучшении моделей. | Можно закрыть, если не хотите отдавать контент для обучения моделей. |
ChatGPT-User |
Запросы, инициированные пользователем ChatGPT или Custom GPT. | Не путать с массовым обходом. Часто лучше не блокировать, иначе пользователи хуже взаимодействуют с вашим сайтом через ассистента. |
Google-Extended |
Токен robots.txt, через который Google дает управлять использованием контента для Gemini Apps и Vertex AI API for Gemini. | Это не отдельный HTTP user-agent и не фактор ранжирования Google Search. Решение зависит от политики по AI-использованию контента. |
Важно: названия и поведение ботов меняются. Перед жесткими правилами в продакшене стоит сверять документацию конкретного провайдера, а не копировать чужой robots.txt из статьи двухлетней давности.
Стратегия 1: хотим видимость в AI-поиске, но не хотим обучение
Для большинства коммерческих сайтов это самый разумный старт. Интернет-магазину, SaaS, клинике, локальному бизнесу или агентству обычно выгодно, чтобы AI-поиск мог показывать сайт как источник. Но это не значит, что нужно автоматически разрешать все сценарии использования контента.
Пример логики для OpenAI:
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: GPTBot
Disallow: /Смысл такой: поисковый бот и пользовательские обращения не блокируются, а тренировочный бот закрывается. Это не универсальная рекомендация на все времена, но хороший базовый компромисс для проектов, где органическая видимость важна, а контент имеет самостоятельную ценность.
Стратегия 2: максимальная открытость
Такой подход может подойти брендам, которым важнее распространение знаний, упоминания и цитируемость, чем контроль над текстами. Например, разработчик open-source продукта, публичная документация API, справочный портал или образовательный проект могут сознательно разрешать больше ботов.
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Allow: /
User-agent: ChatGPT-User
Allow: /Плюс подхода — меньше риска случайно выпасть из новых AI-каналов. Минус — меньше контроля над тем, как контент может использоваться в экосистемах моделей. Для медиа, платных баз знаний и сайтов с уникальными исследованиями такая открытость не всегда разумна.
Стратегия 3: защита контента прежде всего
Если сайт живет за счет уникальных материалов, платного доступа, закрытых исследований или юридически чувствительных данных, можно выбрать более жесткую модель. Но ее надо осознавать как бизнес-решение: вы снижаете риск использования контента, но потенциально ограничиваете присутствие в AI-поиске и ассистентах.
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /Даже при жесткой политике не стоит слепо закрывать вообще все. Например, можно оставить открытыми публичные лендинги, документацию, страницы продукта и контакты, а закрыть платные материалы, архивы, внутренние разделы и страницы, которые не должны становиться источником для внешних ответов.
Почему robots.txt — это только один слой
robots.txt помогает обозначить правила для добросовестных краулеров, но не решает все вопросы. Он не заменяет авторизацию, paywall, техническую защиту закрытых данных и нормальное управление индексируемостью. Если контент не должен быть публичным, он не должен просто лежать в открытом HTML и надеяться на robots.txt.
Для SEO также важно помнить: блокировка краулера не равна удалению страницы из уже существующих индексов или чужих кэшей. А запрет одного бота не означает запрет всех AI-систем. Нужна регулярная инвентаризация логов и правил доступа.
Что смотреть в логах
Минимальный аудит AI-ботов начинается не с идеального robots.txt, а с логов сервера. Нужно понять, кто уже приходит на сайт, какие URL запрашивает, какие коды ответа получает и не создает ли лишнюю нагрузку.
- User-agent. Фиксируйте точные строки и не полагайтесь только на короткое название.
- IP и верификация. Для важных ботов проверяйте официальные диапазоны или рекомендованный способ проверки провайдера.
- Глубина обхода. Смотрите, ходит ли бот только по главным страницам или забирает фильтры, пагинацию, параметры и мусорные URL.
- Коды ответа. Массовые 404, 500, 429 и редиректные цепочки ухудшают качество обхода и создают шум.
- Частота. Если бот грузит сервер, настройте rate limiting аккуратно, не ломая обычных поисковых роботов.
Как не навредить SEO
Главный риск — закрыть полезный канал из-за страха перед словом AI. Если ваш бизнес получает клиентов из поиска, то AI-поиск постепенно становится частью поисковой видимости. И наоборот: если вы без разбора открываете весь сайт, можно отдать на внешнюю переработку то, что является вашим продуктом.
Практичный порядок такой:
- Разделите страницы по ценности. Главная, услуги, карточки товаров, документация, блог, платные материалы и личные кабинеты требуют разных правил.
- Определите цель. Вам важнее попадать в AI-ответы, защищать данные или балансировать оба сценария?
- Разрешайте поисковые AI-боты отдельно от тренировочных. Не смешивайте `OAI-SearchBot` и `GPTBot` в одну категорию просто потому, что оба связаны с OpenAI.
- Проверяйте рендеринг страниц. AI-краулеры и поисковые системы хуже работают с пустыми страницами, перегруженным JS и контентом, который появляется только после сложных клиентских действий.
- Уберите мусорные зоны обхода. Фильтры, сортировки, календарные архивы, поиск по сайту и UTM-дубли могут съедать crawl budget и давать плохой сигнал о качестве сайта.
- Добавьте ясные сигналы доверия. Автор, редактор, дата обновления, источники, контакты, политика компании и прозрачная структура помогают не только людям, но и системам оценки качества.
Отдельно про Google-Extended
`Google-Extended` часто понимают неправильно. Это не обычный робот, который вы увидите как отдельную строку user-agent в логах. Это управляющий токен robots.txt. Google указывает, что он связан с использованием контента для Gemini Apps и Vertex AI API for Gemini, а также с grounding-сценариями. При этом Google отдельно подчеркивает, что `Google-Extended` не влияет на включение сайта в Google Search и не используется как сигнал ранжирования.
То есть запрет `Google-Extended` не должен быть способом «улучшить SEO» или «скрыться от Googlebot». Это настройка политики AI-использования контента. Для обычного поиска Google все равно нужны корректные правила для Googlebot, индексации, canonical, sitemap, noindex и технического состояния сайта.
User-agent: Google-Extended
Disallow: /Такое правило говорит не о запрете Google Search, а о запрете соответствующего AI-использования, описанного Google. Перед внедрением лучше согласовать это решение с владельцем контента, юристом или руководителем продукта, потому что это уже не только SEO-настройка.
Чеклист для сайта
- Проверьте текущий `robots.txt`: нет ли там старых или слишком широких запретов.
- Составьте список AI-ботов, которые реально приходили в логи за последние 30-90 дней.
- Разделите ботов на поисковых, тренировочных и пользовательских fetcher’ов.
- Определите, какие разделы сайта должны быть доступны для AI-поиска.
- Закройте тренировочный доступ там, где контент является платным, уникальным или юридически чувствительным.
- Проверьте, что важные страницы отдают 200, имеют нормальный HTML, title, description, canonical и понятный основной контент.
- Настройте мониторинг логов и вернитесь к правилам через месяц: AI-экосистема меняется быстро.
Вывод
AI-краулеры — это уже часть SEO-инфраструктуры, а не отдельная экзотика. Хорошая настройка не должна быть эмоциональной: «запретить всех» или «разрешить всех». Она должна отвечать на простой вопрос: какой контент мы хотим показывать в AI-поиске, какой контент можно использовать для пользовательских запросов, а какой не должен уходить в обучение моделей.
Если коротко: разрешайте то, что помогает находить ваш сайт и приводить пользователей; закрывайте то, что является вашим защищаемым активом; регулярно проверяйте документацию и серверные логи. Это спокойная, взрослая стратегия для новой поисковой реальности.
