Как написать robots.txt, который действительно блокирует ИИ-скрейперы

Неудобная правда о robots.txt

Файл robots.txt — это не замок. Это табличка на двери.

Это различие важно, когда команды спрашивают, могут ли они «заблокировать ИИ-скрейперы» одним небольшим текстовым файлом. Для авторитетных краулеров, которые соблюдают Robots Exclusion Protocol, — да: правильно написанный robots.txt может указать им не сканировать ваши страницы. Для неизвестных скрейперов, имитаторов, браузерной автоматизации и ботов, которым просто все равно, сам по себе он ничего не сделает.

Поэтому практическая цель — не «сделать скрейпинг невозможным». Она в другом:

• Сообщить добросовестным ИИ-краулерам, что не нужно использовать ваш сайт.
• Не заблокировать случайно поисковые системы или полезные сервисы.
• Добавить более сильные серверные меры контроля против злоупотреблений.
• Поддерживать политику в актуальном состоянии по мере изменения имен краулеров.

Это скучная версия. И именно она работает.

Что robots.txt может и не может делать

Файл robots.txt находится в корне сайта:

https://example.com/robots.txt

Краулеры запрашивают его перед сканированием. Файл содержит группы правил. Каждая группа начинается с одной или нескольких строк User-agent, за которыми следуют директивы Allow или Disallow.

Простая блокировка всего сайта выглядит так:

User-agent: GPTBot
Disallow: /

Это означает: если вы GPTBot, не сканируйте ничего на этом сайте.

Но у robots.txt есть жесткие ограничения:

1. Он добровольный. Недобросовестные участники могут его игнорировать.
2. Он не мешает обычному браузеру или скрипту запросить URL.
3. Он не удаляет контент, уже собранный где-либо еще.
4. Сам по себе он не определяет авторские права, лицензирование или права на обучение моделей.
5. Его можно настроить ошибочно так, что будут заблокированы не те боты.

Если вам нужен настоящий контроль доступа, используйте аутентификацию, авторизацию, ограничение частоты запросов, контроль по IP, управление ботами или юридические меры. Robots.txt все еще полезен, но он должен быть частью более широкой стратегии защиты контента.

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

Начните с решения о политике

Прежде чем редактировать файл, решите, что именно вы пытаетесь заблокировать.

Есть как минимум четыре разных смысла, которые люди вкладывают в выражение «ИИ-скрейпер»:

• Краулеры, используемые для сбора данных для обучения.
• Краулеры ИИ-поиска или систем ответов.
• Запросы, инициируемые пользователем, например когда кто-то просит ИИ-продукт кратко изложить URL.
• Обычные скрейперы, выдающие себя за обычные браузеры.

Возможно, вы захотите заблокировать их всех. Или, наоборот, сохранить обнаружение через поиск, но отказаться от использования контента для обучения моделей. Это не одна и та же политика.

Например, OpenAI документирует отдельные user agent для разных целей, включая GPTBot, ChatGPT-User и OAI-SearchBot. Google использует Google-Extended как управляющий токен для некоторых сценариев Gemini и Vertex AI, тогда как обычное сканирование для Google Search выполняется другими user agent Googlebot.

Это разделение важно. Если неосторожно блокировать широкие user agent, можно навредить обычной видимости в поиске, пытаясь заблокировать обучение ИИ.

Разумный шаблон robots.txt для блокировки ИИ

Вот консервативная отправная точка для блокировки нескольких распространенных документированных краулеров, связанных с ИИ, при сохранении доступа для обычных поисковых краулеров:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Это не волшебный универсальный список. Это поддерживаемый шаблон.

Несколько замечаний:

• Disallow: / означает «не сканировать ни один путь».
• User-agent: * применяется к краулерам, которые не совпали с более конкретной группой.
• Allow: / не строго обязателен для группы по умолчанию, но он ясно показывает ваше намерение.
• Делайте комментарии короткими. Некоторые парсеры снисходительны, но robots.txt должен оставаться скучным.
• Не включайте приватные URL в robots.txt. Файл публичный, и перечисление чувствительных путей может привлечь к ним внимание.

Последний пункт стоит повторить. Robots.txt — не механизм секретности. Если /client-contracts/ не должен быть публичным, защитите его аутентификацией. Не ограничивайтесь disallow.

Будьте осторожны с Google-Extended

Google-Extended часто понимают неправильно. Это не то же самое, что блокировка Google Search.

Согласно документации Google, Google-Extended — это отдельный продуктовый токен, который издатели могут использовать, чтобы управлять тем, может ли контент сайта помогать улучшать некоторые возможности Gemini и Vertex AI. Его блокировка сама по себе не должна блокировать сканирование Googlebot для Search.

При этом не заменяйте все директивы Google широкой блокировкой вроде этой, если вы действительно не это имеете в виду:

User-agent: Googlebot
Disallow: /

Это сообщит основному краулеру Google Search не сканировать ваш сайт. Для большинства публичных сайтов это не то, что нужно.

То же различие применимо и в других случаях. Некоторые поставщики разделяют краулеры для обучения, пользовательский просмотр и краулеры ИИ-поиска. Другие — нет. Вам нужно читать документацию по ботам, которые для вас важны, и относиться к своему robots.txt как к живому файлу, а не как к одноразовой галочке.

Тестируйте файл как production-код

Robots.txt выглядит простым, и именно поэтому его легко сломать.

Распространенные ошибки включают:

• Загрузку файла не туда, например в /assets/robots.txt вместо /robots.txt.
• Использование «умных» кавычек, скопированных из текстового редактора.
• Случайную блокировку всех краулеров через User-agent: * и Disallow: /.
• Предположение, что файл одного домена применяется к другому поддомену.
• Забывание о том, что http://, https://, www и хосты без www могут обрабатываться по-разному в зависимости от вашей настройки.

Для сайтов с несколькими доменами проверяйте каждый канонический хост. Файл robots по адресу https://www.example.com/robots.txt не управляет автоматически https://app.example.com/robots.txt.

При отладке проверяйте фактический HTTP-ответ, а не только то, что показывает предпросмотр вашей CMS. Вам нужен ответ 200 OK, тип содержимого text/plain, если возможно, и именно тот файл, который вы ожидаете. Если задействованы редиректы, кэширование или правила CDN, помогает просмотр сырых заголовков. Рабочий процесс из материала об отладке редиректов и HTTP-заголовков в production напрямую применим и здесь.

Добавьте серверные меры контроля для ботов, которые игнорируют правила

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

Практические меры включают:

Ограничение частоты запросов

Задайте пороги для необычных паттернов запросов: слишком много страниц в минуту, глубокий обход пагинации, повторяющиеся 404 или высокий объем запросов от небольшого набора IP. Лимиты должны быть достаточно щедрыми, чтобы не наказывать реальных пользователей, и достаточно строгими, чтобы сделать массовое извлечение дорогим.

Фильтрация по user-agent

Вы можете блокировать документированные user agent ИИ-краулеров на уровне веб-сервера, reverse proxy, CDN или приложения. Это сильнее, чем robots.txt, потому что возвращает фактический отказ в доступе.

Например, Nginx может заблокировать шаблон user agent, хотя production-правила нужно тщательно тестировать:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

Это не безотказно. Строки user-agent легко подделать. Но это останавливает честный или ленивый трафик и снижает нагрузку.

Контроль по IP и ASN

Некоторые операторы публикуют диапазоны IP, но многие экосистемы скрейперов этого не делают. Блокировка по IP может работать против очевидных злоупотреблений, особенно из диапазонов cloud hosting, где нет нормального пользовательского трафика, но она также может давать ложные срабатывания. Сначала логи, потом правила.

Аутентификация и paywall

Если контент не должен копироваться в больших объемах, не размещайте полный контент на публичном URL. Robots.txt не подходит для конфиденциальных материалов, лицензированных баз данных, закрытых сообществ или платных архивов.

Минимизация контента

Иногда лучшая защита — архитектурная. Не раскрывайте ненужные API, крупные JSON-пакеты, скрытые метаданные, черновые endpoints или полные архивы, если публичной странице нужен только небольшой фрагмент. Сайтам с большим количеством изображений также стоит думать о том, какие метаданные они публикуют; логика приватности из материала об удалении EXIF-метаданных перед публикацией фотографий онлайн применима и к контентным операциям.

Используйте robots meta tags для правил на уровне страницы

Robots.txt управляет сканированием. Robots meta tags и заголовки X-Robots-Tag управляют индексированием и поведением сниппетов для добросовестных поисковых систем и краулеров.

Например:

<meta name="robots" content="noindex, noarchive">

Или в виде HTTP-заголовка:

X-Robots-Tag: noindex, noarchive

Это не ИИ-специфичные щиты. Они полезны, когда вы хотите, чтобы страница была доступна, но не индексировалась. Однако если вы запрещаете краулеру получать страницу в robots.txt, он может никогда не увидеть meta tag на уровне страницы. Не полагайтесь на тег noindex на URL, который краулеру запрещено сканировать.

Общее правило:

• Используйте robots.txt, чтобы уменьшить или предотвратить сканирование.
• Используйте meta robots или X-Robots-Tag, чтобы управлять поведением индексирования.
• Используйте серверные меры контроля, чтобы принудительно ограничивать доступ.

Мониторьте логи после публикации

Публикация файла — только первый шаг. После этого проверяйте логи.

Ищите:

• Запросы к /robots.txt от user agent, которые вы указали.
• Продолжающееся сканирование после выдачи правил disallow.
• Подозрительные user agent с высоким объемом запросов.
• User agent, похожие на браузеры, которые запрашивают тысячи страниц подряд.
• Повторяющийся доступ к фидам, sitemap, страницам поиска и пагинации.

Если бот запрашивает robots.txt, видит полный запрет и затем останавливается, robots.txt сделал свою работу. Если он продолжает, переводите этого бота в режим принудительного контроля: лимиты частоты, блокировки или аутентификация.

Также проверьте, что раскрывают ваши sitemap. Sitemap полезны для поисковых систем, но они также являются удобными картами для скрейперов. Это не означает, что их нужно удалять с обычных сайтов. Это означает, что не следует включать URL, которые вы не хотите открывать для обнаружения публичными системами.

Держите файл небольшим и проверяемым

Robots.txt имеет свойство устаревать. Маркетинговая команда добавляет кампанийный microsite. Разработчик добавляет staging-путь. Поставщик меняет имя краулера. Через два года никто не знает, зачем существует половина правил.

Относитесь к нему как к конфигурации:

• По возможности храните его в version control.
• Добавляйте короткий комментарий для каждой группы ИИ-краулеров.
• Пересматривайте его ежеквартально.
• Проверяйте документацию поставщика перед добавлением широких правил.
• Тестируйте после изменений CDN, CMS или хостинга.

Если ваш сайт публикует контент, созданный с помощью ИИ, также отделяйте политику краулеров от редакционной прозрачности. Блокировка ИИ-скрейперов касается доступа и повторного использования. Раскрытие информации касается доверия читателей. Эти темы этически пересекаются, но это не один и тот же контроль. Практический подход к раскрытию описан в материале о том, как выглядит честное раскрытие использования ИИ на небольшом сайте.

<!-- tool-cta:start -->

💡 Попробуйте это: После добавления правил для AI-краулеров проверьте синтаксис с помощью Robots.txt Tester, чтобы случайно не заблокировать и легитимных ботов.

<!-- tool-cta:end -->

Главное

Хороший файл robots.txt заблокирует добросовестные ИИ-краулеры. Он не остановит настойчивый скрейпинг, поддельные строки user-agent, скомпрометированные браузеры или людей, которые вручную вставляют ваш контент в ИИ-системы.

Это не делает его бесполезным. Это делает его одним из уровней защиты.

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

Веб всегда работал на сочетании протоколов, норм и принудительного контроля. Robots.txt — это уровень норм. Используйте его, но не принимайте за стену.