Новые правила для AI-ботов: как Microsoft, Google и Cloudflare переписывают robots.txt

Почему robots.txt больше недостаточно

Представьте: ваш сайт — это дом. Тридцать лет назад вы повесили табличку на двери: «Можно войти» или «Вход запрещён». Этого хватало. Но теперь гости не просто заходят — они фотографируют всё внутри, копируют содержимое и используют его для своих целей.

Именно так работают современные AI-боты. Старая табличка (файл robots.txt) больше не справляется. Поэтому технологические гиганты предлагают новые правила игры.

С 1994 года файл robots.txt помогал владельцам сайтов управлять поисковыми роботами. Принцип был простой: два правила — Allow (разрешить) и Disallow (запретить). Скажите роботу, куда можно заходить, а куда нельзя — и всё работает.

Но в 2024-2025 годах ситуация изменилась кардинально. Появились AI-боты с говорящими именами: GPTBot от OpenAI, ClaudeBot от Anthropic, Google-Extended, Bytespider и десятки других. Эти боты не просто читают ваши страницы для поисковой выдачи — они скачивают контент для обучения нейросетей.

В чём проблема? Классический robots.txt умеет только сказать «можно скачать» или «нельзя скачать». Но он не умеет ответить на вопрос: «А что вы будете делать с моим контентом после скачивания?»

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

Решение Microsoft: простые правила для всех

21 октября 2024 года два менеджера Microsoft — Fabrice Canel (Bing) и Krishna Madhavan (AI) — опубликовали предложение добавить в robots.txt два новых правила:

• DisallowAITraining — запретить использование контента для обучения AI
• AllowAITraining — разрешить использование для обучения AI

Логика понятная: старые правила Allow и Disallow контролируют доступ к контенту, а новые правила контролируют использование контента. Это две разные вещи!

Как это выглядит на практике

Допустим, вы хотите, чтобы ваш сайт индексировался в поиске, но не хотите, чтобы тексты использовались для обучения ChatGPT. Вот как это записать:

User-agent: * Allow: / DisallowAITraining: /

Перевод: «Все боты могут скачивать любые страницы (для поиска), но никто не может использовать контент для тренировки AI-моделей».

Можно быть ещё более точным:

User-agent: *
 Allow: /
 DisallowAITraining: /
 AllowAITraining: /open-data/

Здесь весь сайт защищён от AI-обучения, кроме раздела /open-data/, который вы готовы предоставить.

Три способа передачи правил

Microsoft предложила доставлять директивы тремя способами:

1. Через robots.txt — для правил всего сайта

2. Через HTML-теги — для отдельных страниц:

<meta name="robots" content="DisallowAITraining">

3. Через HTTP-заголовки — для динамического контента и API

Важно понимать: Эти директивы — это просьба, а не юридически обязывающий механизм. Как и классический robots.txt, это добровольный протокол. Однако все крупные компании традиционно соблюдают robots.txt, и ожидается, что они будут уважать и новые правила.

Решение Google: гибкая система категорий

Google пошёл другим путём. Вместо отдельных директив команда Google предложила универсальную систему Content-Usage, которая работает со словарём предпочтений.

Главная идея: разделить два уровня контроля:

1. Первый уровень (Allow/Disallow) — что можно скачивать
2. Второй уровень (Content-Usage) — как можно использовать скачанное

Пример использования

Базовая настройка выглядит так:

User-Agent: * Allow: / Content-Usage: train-ai=n

Здесь train-ai=n означает «не использовать для тренировки AI» (n = no, y = yes).

А вот более сложная конфигурация с разными правилами для разных разделов сайта:

User-Agent: *
 Allow: /
 Disallow: /never/
 Content-Usage: train-ai=n
 Content-Usage: /ai-ok/ train-ai=y

Что происходит: весь сайт открыт для индексации (кроме папки /never/), тренировка AI запрещена для всего контента, но разрешена для раздела /ai-ok/.

Результаты в виде таблицы

Словарь категорий: больше чем просто AI-обучение

Google и Mozilla создали специальный словарь (AIPREF Vocabulary), который определяет разные типы использования контента:

• train-ai — использование для обучения AI-моделей
• search — использование в поисковых системах (с показом источника)

Для каждой категории возможны три состояния: y (разрешено), n (запрещено) или отсутствие значения (нет предпочтения).

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

Кто координирует процесс: рабочая группа IETF

В апреле 2025 года IETF создал рабочую группу AIPREF (AI Preferences). Для тех, кто не знает: IETF — это международная организация, которая с 1986 года разрабатывает интернет-стандарты. Именно она создала HTTP, DNS, TLS и в 2022 году формализовала robots.txt в RFC 9309.

Задачи группы AIPREF:

• Создать общий словарь для выражения предпочтений владельцев контента
• Определить механизмы передачи этих предпочтений (через HTTP-заголовки и robots.txt)
• Разработать правила разрешения конфликтов

Как объяснил сопредседатель группы Mark Nottingham (один из ключевых авторов HTTP-стандартов): нестандартные сигналы в robots.txt не работают, и владельцы сайтов «теряют доверие к тому, что их предпочтения будут соблюдены», и начинают блокировать IP-адреса.

Целевой срок: август 2026 года — публикация официального стандарта RFC.

Подход Cloudflare: юридический и технический щит

В сентябре 2025 года в дискуссию вступил ещё один крупный игрок — Cloudflare представил свою Content Signals Policy. Через инфраструктуру Cloudflare проходит значительная часть интернет-трафика, поэтому их решение имеет вес.

Cloudflare предложил три категории использования:

• search — построение поискового индекса
• ai-input — подача контента в AI в реальном времени (например, для генеративного поиска)
• ai-train — обучение или дообучение AI-моделей

Синтаксис Cloudflare

User-Agent: *
 Content-Signal: search=yes, ai-train=no
 Allow: /

Обратите внимание: Cloudflare использует Content-Signal (не Content-Usage), значения yes/no (не y/n), и добавляет категорию ai-input, которой нет в предложении Google.

Уникальная особенность: Cloudflare включает в robots.txt подробный юридический комментарий со ссылкой на европейскую Директиву 2019/790 о цифровом едином рынке. Это превращает robots.txt не просто в техническое указание, но и в юридическое заявление о резервировании прав.

Cloudflare уже активировал свою политику для более 3,8 миллиона доменов и создал удобный генератор на сайте ContentSignals.org.

Сравнение трёх подходов

Microsoft: DisallowAITraining

Плюсы: Простой синтаксис, похож на привычный Disallow/Allow

Минусы: Ограничен одной категорией — AI-тренировка

Статус: Индивидуальный черновик, идеи включены в работу IETF

Google: Content-Usage

Плюсы: Гибкая система с расширяемым словарём категорий

Минусы: Более сложный синтаксис

Статус: Документ рабочей группы IETF, наибольшие шансы стать стандартом

Cloudflare: Content-Signal

Плюсы: Уже работает на миллионах сайтов, включает юридические формулировки

Минусы: Проприетарная инициатива, не согласована с IETF

Статус: Действующее решение, доступно всем

Что делать прямо сейчас: практическая инструкция

Поскольку ни одна из директив пока не стала официальным стандартом, лучшая стратегия — использовать все три подхода одновременно. Вот готовая конфигурация robots.txt, которая максимально защищает ваш контент:

# === Блокировка известных AI-краулеров === User-Agent: GPTBot
 User-Agent: ClaudeBot
 User-Agent: Claude-SearchBot
 User-Agent: CCBot
 User-Agent: Google-Extended
 User-Agent: Applebot-Extended
 User-Agent: Bytespider
 User-Agent: Meta-ExternalAgent
 User-Agent: PerplexityBot
 User-Agent: cohere-ai
 Disallow: /
 DisallowAITraining: /
 # === Экспериментальные директивы для всех ботов ===
 User-Agent: *
 Allow: /
 DisallowAITraining: /
 Content-Usage: train-ai=n
 Content-Signal: search=yes, ai-train=no

Как это работает:

1. Первый блок — прямой запрет для известных AI-ботов (проверенный метод)
2. Второй блок — для всех остальных ботов: разрешаем доступ, но запрещаем AI-обучение через все три механизма
3. Если бот понимает DisallowAITraining — сработает оно. Если Content-Usage — сработает оно. Если Content-Signal — тоже сработает
4. Неизвестные директивы просто игнорируются, так что совместимость с классическими поисковыми роботами сохраняется

Дополнительная защита: мета-теги

На уровне отдельных страниц добавьте в <head>:

<meta name="robots" content="DisallowAITraining">
 <meta name="robots" content="noai, noimageai">

Второй мета-тег (noai, noimageai) — это неофициальное предложение сообщества, используемое некоторыми CMS и WordPress-плагинами. На этапе формирования стандартов лучше добавить все доступные сигналы.

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

Вопрос управления AI-краулерами — не просто технический. За ним стоит экономика создания контента.

Реальные проблемы:

• Wikimedia Foundation сообщает, что трафик на получение изображений вырос на 50% за год — в основном за счёт AI-краулеров
• Издатели обнаруживают, что их тексты используются для обучения моделей, которые затем конкурируют с ними же
• OpenAI лоббирует реформу авторского права, чтобы скачивать больше контента без оплаты
• Правообладатели подают судебные иски

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

Но наличие стандарта меняет правила игры. Когда у издателя есть формализованный способ сказать «нет», а AI-компания его игнорирует — это уже не техническая, а юридическая и репутационная проблема.

Не случайно Cloudflare явно ссылается на европейскую Директиву 2019/790: в ЕС opt-out от text and data mining имеет юридическую силу, и машинночитаемое выражение этого opt-out через robots.txt может стать доказательством в суде.

Хронология событий

• 1994 год — Создан оригинальный протокол robots.txt
• 2022 год — IETF опубликовал RFC 9309, формализовавший Robots Exclusion Protocol
• Октябрь 2024 — Microsoft публикует предложение DisallowAITraining
• Апрель 2025 — IETF учреждает рабочую группу AIPREF
• Июнь 2025 — Google и Mozilla публикуют предложение Content-Usage
• Сентябрь 2025 — Cloudflare запускает Content Signals Policy
• Декабрь 2025 — Выходит пятая редакция словаря AIPREF Vocabulary
• Март 2026 — Запланировано очередное заседание рабочей группы AIPREF
• Август 2026 — Целевой срок публикации официального RFC-стандарта

Что ещё есть на горизонте

Помимо трёх основных подходов, существуют дополнительные инициативы:

llms.txt

Предложение создавать файл /llms.txt в корне сайта со структурированной информацией в Markdown для помощи LLM-системам. Это не про блокировку, а наоборот — про оптимизацию взаимодействия с AI. Однако Google прямо заявил, что не поддерживает llms.txt.

ai.txt

Доменно-специфический язык для описания разрешённых действий AI-систем. Формат амбициозный, но пока не получил значимой поддержки.

Cloudflare AI Labyrinth

Технологический подход, при котором Cloudflare направляет AI-ботов в «лабиринт» из бессмысленного AI-сгенерированного контента, тратя их ресурсы впустую.

Заключение: что делать владельцам сайтов

Мы находимся в историческом моменте формирования нового интернет-стандарта. Три подхода — от Microsoft, Google и Cloudflare — конкурируют и дополняют друг друга. К концу 2026 года мы увидим первый официальный RFC-стандарт.

Стратегия на сегодня:

• Не ждать — действовать сейчас
• Добавить экспериментальные директивы, комбинируя все три механизма
• Сохранить классическую блокировку по User-Agent
• Даже если директива пока не поддерживается — она формирует юридический, технический и репутационный сигнал

Когда стандарт будет принят, потребуются лишь минимальные корректировки в уже подготовленном robots.txt.