Search Engine Journal разобрал новый выпуск видеосерии Google Search Central «The Non-Canonical Cabinet», где Гэри Иллис и Черри Проммавин отвечают на нестандартные технические вопросы сообщества. Вопрос второго выпуска звучал так: можно ли разрешить ИИ-краулерам заходить на сайт, но не позволить использовать этот контент для обучения генеративных моделей. Ответ Иллиса: средствами robots.txt в рамках стандарта — нет. Разбираю, что именно сказано, что с этим делать практически и куда движется стандарт.
Что сказал Google: robots.txt — протокол доступа, а не использования
По RFC 9309 robots.txt определяет, какие URL краулеру можно запрашивать, — и только это. Иллис назвал файл «access preference protocol» и прямо сказал: он «не диктует, что система делает с данными после того, как уже их просканировала». Если нужно полностью закрыть конкретного ИИ-бота от сайта, единственный путь — явно указать его user-agent токен в файле.
В выпуске показали вымышленную директиву No-AI-Chicken-Training: парсер её просто проигнорирует. Спецификация robots.txt от Google поддерживает ровно четыре элемента: User-Agent, Allow, Disallow и Sitemap. RFC 9309 в разделе 2.2.4 добавляет важное: как поступать с неопознанными строками, краулер решает сам. То есть «работает или нет» зависит не от содержимого файла, а от того, кто его читает.
Что реально работает: блокировка по токенам отдельных ботов
Стандартный механизм один — Disallow по точному user-agent токену. Для экосистемы Google такой токен — Google-Extended. У него нет собственного краулера: Google сканирует сайт обычными агентами, а токен работает в «контрольном» режиме. По документации Google он отключает использование просканированного контента для обучения будущих моделей Gemini и для grounding в Gemini Apps и Grounding with Google Search на Vertex AI. При этом на попадание сайта в Google Search и на ранжирование Google-Extended не влияет — решение о нём можно принимать отдельно от решения об индексации.
У других операторов свои токены: GPTBot у OpenAI, ClaudeBot у Anthropic, CCBot у Common Crawl. Это не стандарт, а добровольные декларации каждого оператора — список и поведение проверяйте по документации конкретной системы, они периодически меняются.
Черновик IETF: Content-Usage — попытка стандартизировать «можно сканировать, нельзя обучать»
Иллис — соавтор черновика IETF вместе с Мартином Томсоном из Mozilla. Документ предлагает дополнить RFC 9309 правилом Content-Usage и одноимённым HTTP-заголовком. Логика: Allow и Disallow отвечают на вопрос «что можно сканировать», Content-Usage — на вопрос «как можно использовать просканированное». В примере из черновика при открытых для краулинга путях стоит Content-Usage: train-ai=n.
Статус у идеи честный: это рабочий документ рабочей группы, до IESG он ещё не дошёл — планировать отправку на август 2026-го не получилось. Отдельный словарь меток прямо пишет, что консенсуса в группе пока нет, а сам черновик Content-Usage истекает 20 февраля 2027 года, если не выйдет новая редакция. Итог: на сегодня обязательного для всех способа сказать «сканировать можно, обучать нельзя» не существует — есть только добровольные токены отдельных систем.
Бонус выпуска: процентное кодирование путей в robots.txt
Второй практический совет касается сайтов с неанглийскими адресами. Проммавин рекомендовала указывать такие пути в robots.txt в percent-encoded виде: парсер Google одинаково понимает и сырой UTF-8 (включая эмодзи), но «другие или более старые краулеры могут запутаться». Если у вас категории и метки на кириллице — это ровно про ваш robots.txt: Google правило прочитает в любом виде, а вот менее аккуратный бот может не прочитать вовсе.
Что из этого следует
- Владельцам сайтов: robots.txt — про доступ, а не про права. Желание «разрешить бота, но запретить обучение» стандарт не выражает; выражает его только добровольная политика конкретного оператора ИИ.
- SEO-специалистам: Google-Extended отключает обучение и grounding для Gemini, не затрагивая индексацию и ранжирование. Решение о нём принимайте отдельно от решений о поисковой видимости — и фиксируйте его в чек-листе запуска новых сайтов.
- Разработчикам: блокируйте ИИ-ботов точными user-agent токенами, не изобретайте собственные директивы — неопознанные строки парсер волен игнорировать. Пути с кириллицей пишите в percent-encoding: для Google это равнозначно, для остальных — безопаснее.
Политика использования контента пока живёт в документации каждой ИИ-компании отдельно, и проверять её придётся вручную: список токенов, их семантика и добросовестность операторов — разные у каждой системы. Если нужно настроить robots.txt под ИИ-краулеров и провести аудит индексации — напишите нам, закроем вопрос в рамках технического аудита. А о том, как измерять видимость бренда в ответах ИИ без самообмана, у нас есть отдельный разбор.
Источники: разбор Search Engine Journal, видео Google Search Central, стандарт RFC 9309, черновики IETF aipref.
