Короткий ответ
robots.txt сообщает добросовестным краулерам правила обхода, но не заменяет авторизацию и серверную защиту. Разделяйте поисковую индексацию, AI-поиск, обучение моделей и запросы пользователей, а решение принимайте по цели и проверяемым сигналам.
В access-логах сайтов появляются новые User-Agent: GPTBot, OAI-SearchBot, ClaudeBot и другие автоматические клиенты. Владельцу бизнеса важно понять, кого разрешить ради видимости, кому ограничить доступ к контенту и как не заблокировать обычный поиск. Одно глобальное правило не решает все задачи: поисковый робот, краулер обучения модели, AI-поиск и вредный парсер работают с разными целями.
Эта статья помогает выстроить политику: инвентаризировать автоматические запросы, проверить robots.txt, разделить публичные и закрытые разделы, а затем наблюдать за результатом по логам, поисковой аналитике и бизнес-метрикам. Правила операторов меняются, поэтому перед релизом сверяйте их с официальной документацией.
Чем AI-краулеры отличаются от поисковых роботов
Googlebot и Яндекс.Бот обходят страницы для поисковых систем. Ошибочная блокировка способна ухудшить обнаружение и обновление документов. OpenAI описывает OAI-SearchBot как робот для показа сайтов в поисковых ответах ChatGPT, а GPTBot — как краулер контента, который потенциально используется для обучения генеративных моделей. ChatGPT-User применяется для некоторых действий, инициированных пользователем, и не предназначен для автоматического обхода всего веба.
Anthropic аналогично разделяет ClaudeBot, Claude-SearchBot и Claude-User. Поэтому решение «разрешить AI» слишком расплывчато. Компания может разрешить поисковое обнаружение публичных материалов, запретить сбор для обучения и оставить закрытые разделы недоступными неавторизованным клиентам.
| Тип | Цель | Основной контроль | Риск ошибки |
|---|---|---|---|
| Поисковый робот | Индексирование | robots.txt, sitemap, canonical | Потеря видимости |
| AI-поиск | Поисковые ответы | Правило User-Agent | Потеря канала |
| Обучающий краулер | Сбор материалов | Поддерживаемый opt-out | Нежелательное использование |
| Вредный парсер | Копирование или атака | WAF, rate limit, поведение | Нагрузка и утечка |
Что действительно контролирует robots.txt
Файл в корне хоста задаёт правила автоматического обхода для клиентов, которые согласны их соблюдать. Это не пароль и не средство сокрытия конфиденциальной страницы. URL может быть известен из внешней ссылки, а недобросовестный скрипт способен проигнорировать Disallow. Личный кабинет, документы клиентов и служебные API должны защищаться авторизацией и проверкой прав.
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: *
Allow: /
Sitemap: https://example.ru/sitemap.xml
Это пример раздельной политики, а не универсальная рекомендация. robots.txt действует для конкретного хоста, поэтому правила проверяют отдельно для основного домена и поддоменов. В материале о Googlebot и Яндекс.Боте разобраны проверка поисковых роботов и ложные срабатывания.
Как выбрать политику доступа
Начните с карты контента. Публичные статьи, карточки товаров и справка могут приносить поисковый спрос. Корзина, форма, поиск по каталогу и API создают вычислительную нагрузку. Личный кабинет и персональные данные не должны становиться публичными. Для каждой группы зафиксируйте допустимых клиентов, лимит запросов и ожидаемый бизнес-результат.
- Редакционный контент: разрешить выбранные поисковые каналы, контролировать частоту и кеширование.
- Каталог: сохранить индексируемые страницы, но ограничить перебор фильтров и параметров.
- Формы: применять поведенческую проверку, защиту от повторов и серверную валидацию.
- API: использовать ключи, подписи, квоты и минимальные права, а не robots.txt.
- Закрытые данные: требовать аутентификацию на каждом запросе.
Пошаговая настройка без потери SEO
- Соберите базовую линию. Сопоставьте User-Agent, URL, HTTP-код, частоту, ASN и нагрузку за одинаковые периоды. Методика описана в статье про Метрику, логи и CRM.
- Классифицируйте клиента. Отделите подтверждённый поиск, мониторинг и интеграции от парсинга, спама и перебора.
- Определите цели. Решите, нужна ли видимость в конкретном поиске и допустим ли сбор для обучения.
- Изменяйте минимально. Добавьте правило конкретного робота вместо глобального запрета и проверьте синтаксис.
- Проверьте инфраструктуру. Откройте robots.txt и sitemap.xml снаружи, проверьте canonical, коды ответа, DNS и SSL в инструменте здоровья домена.
- Наблюдайте. Сравните ошибки обхода, органический трафик, время ответа, нагрузку origin и заявки.
Когда нужна серверная защита
Парсер может назваться Googlebot, а распределённая атака менять IP после каждого запроса. Поэтому для дорогих маршрутов комбинируют частоту, последовательность действий, cookies, JavaScript-сигналы, сетевую репутацию и ценность операции. На чтении каталога уместно замедление, на отправке формы — challenge, на авторизации — строгие лимиты, а в API — криптографическая аутентификация.
Не блокируйте весь трафик дата-центров или мобильных сетей без проверки. В руководстве по rate limiting разобрана пропорциональная реакция, а статья о полезном и вредном бот-трафике помогает построить классификацию.
Какие метрики проверить после изменения
| Область | Метрика | Тревожный сигнал |
|---|---|---|
| SEO | Индекс, ошибки обхода | Падение доступных URL |
| Сервер | RPS, CPU, время ответа | Рост нагрузки без ценности |
| Защита | 403, 429, challenge | Ошибки реальных сессий |
| Бизнес | Лиды и конверсия | Падение заявок |
Частые вопросы
Нужно ли разрешать всех AI-краулеров ради SEO?
Нет. Классическая индексация и AI-поиск — разные каналы. Оценивайте видимость, нагрузку и правила использования контента отдельно.
Можно ли доверять User-Agent?
Нет. Его легко подделать. Для чувствительных решений проверяйте сетевой контекст, поведение и доступ к маршруту.
Скроет ли Disallow закрытую страницу?
Нет. Закрытые данные защищают авторизацией. robots.txt — публичный файл с рекомендациями для обхода.
Сверяйте детали с документацией OpenAI, справкой Google и правилами Anthropic. Оценить эффект можно в калькуляторе потерь.