«Тихий DDoS» от ИИ-ботов: ставим квоты и кэш, чтобы счета за инфраструктуру не росли
Как вычислить маскировку под браузер и пресечь её правилами WAF/CDN.
Разберёмся, откуда берутся ИИ-боты, почему простого robots.txt уже недостаточно и как выстроить защиту без порчи SEO и опыта реальных посетителей. Стратегия будет многоуровневой: от предупредительных сигналов до принудительных ограничений и юридических оговорок. В конце — чек-лист и готовые фрагменты конфигураций.
В чём проблема: ИИ-боты как новая «цена» за веб-публикации
Большинство современных моделей питаются открытыми данными. Чем богаче корпус, тем «умнее» ответы. Цена этой «умности» — волны машинного обхода. Они не злобные сами по себе, просто не учитывают вашу экономику и инфраструктурные лимиты. И если поисковики за десятилетия научились беречь сайты, то новое поколение ботов ещё учится.
Показательная тенденция: на некоторых ресурсах доля небраузерных запросов переваливает за разумные пределы. Пики нагрузки от «фетчеров» (ботов, которые делают выборки в момент запроса пользователя) приходятся на публикацию свежих новостей или обновлений и легко забивают узкие места — базы данных, поиск и внешние интеграции. В результате растут счета за инфраструктуру и падает качество сервиса для живых людей.
Почему это «хуже DDoS» и при чём здесь экономика контента
DDoS-атака — это обычно короткий шквал. ИИ-боты — это скорее «постоянный дождь»: интенсивность то нарастает, то стихает, но в сумме расходует ресурсы и вытесняет органику. Хуже всего, когда сайт зарабатывает показами и кликами: ответы «без перехода» в ИИ-поиске обесценивают вашу работу, хотя именно ваш контент кормит модель.
Есть и культурные последствия: если основная подкачка данных идёт из определённых регионов и сегментов, модели наследуют их уклон. Для нишевых и локальных проектов это означает, что их голос в обучающих корпусах может просто не прозвучать. Так что вопрос «пускать или не пускать» — не только технический, но и стратегический.
Почему одного robots.txt уже мало
robots.txt — цивилизованный способ сказать «не ходи». Добропорядочные боты его уважают. Но на практике хватает серых зон. Во-первых, часть операторов меняет User-Agent, маскируясь под браузер. Во-вторых, данные часто попадают в модели не напрямую, а через посредников — кэш поисковиков, агрегаторы, общие датасеты. Запретили GPTBot, но не ограничили Common Crawl — и вот ваш контент в итоговом корпусе.
Поэтому грамотная защита всегда многоуровневая. Сначала — «сигналы доброй воли» (чтобы compliant-боты не ходили сами). Затем — технические барьеры для остальных. Плюс юридическая маркировка, чтобы у вас были аргументы и правила для переговоров или претензий.
Стратегия защиты: от мягкого к жёсткому
Ниже — уровни, которые можно комбинировать. Начинайте с мягких: они дешёвые и не ломают ничьего опыта. Если картины мира не меняется — добавляйте принудительные меры на уровне CDN, WAF и приложений. Важен мониторинг: без телеметрии борьба превратится в угадайку.
Применяйте принцип минимально достаточной строгости. Медиа и блоги чаще ограничивают именно ИИ-краулинг. Интернет-магазинам и SaaS стоит «забор» ставить выше: у них тяжёлые страницы, поисковые индексы и нежелательное копирование цен/ассортимента.
Уровень 1. Сигналы в robots.txt для известных ИИ-ботов
Это первый и самый дешёвый шаг. Он работает там, где оператор стремится быть прозрачным и не портить отношения с паблишерами. Настройте явный запрет для конкретных агентов и оставьте «звёздочку» для остального краулинга. Если какие-то ИИ-сервисы вам полезны — для них можно сделать отдельные разрешения и лимиты.
# Пример robots.txt (фрагмент)
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-User
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
# Запрет использования для обучения Gemini и «подсказок»:
User-agent: Google-Extended
Disallow: /
Помните, что «звёздочка» не заменяет явные правила: некоторые агенты смотрят только свой токен. Обновляйте список по мере появления новых ботов и заведите процедуру его ревизии раз в квартал. Для крупных порталов удобнее генерировать robots.txt автоматически из базы известных агентов.
Уровень 2. Метки в HTML и заголовках ответа
Помимо robots.txt, укажите запрет прямо в страницах и ответах сервера. Это полезно для медиа, картинок и файлов, где важна пообъектная маркировка. Используются два механизма: метатеги «роботов» и заголовок X-Robots-Tag. Нестандартные директивы noai и noimageai уже поддерживает ряд инструментов и сервисов, а классические noindex/noarchive понимают поисковики.
<!-- В <head> страницы -->
<meta name="robots" content="noai, noimageai">
<!-- В HTTP-ответе (например, Nginx) -->
add_header X-Robots-Tag "noai, noimageai" always;
Для Европы дополнительно рассмотрите протокол Text and Data Mining Reservation Protocol (TDMRep): он позволяет машинно-читаемо заявлять «права зарезервированы для майнинга». Передача делается через заголовок и/или файл /.well-known/tdmrep.json. Это не «блокировка», но понятная юридическая оговорка и сигнал добросовестным игрокам.
# Минимальный заголовок
add_header tdm-reservation "1" always;
# Минимальный /.well-known/tdmrep.json
{
"reservation": 1,
"policy": "https://example.com/tdm-policy"
}
Уровень 3. Правила на CDN/WAF: блок, челлендж, квоты
Дальше — периметр. Сеть доставки контента и веб-фаервол (CDN/WAF) видят больше сигналов, чем ваш сервер, и умеют «встретить» бота на границе. Простой приём — правила по User-Agent: блок/челлендж для токенов ИИ-ботов. Лучше — правила по поведенческим метрикам: частота, параллельность, шаблоны URL, доля HEAD-запросов. Ещё лучше — комбинированные решения «управления ботами», которые учитывают репутацию IP/ASN и отпечатки TLS/JA3.
# Пример выражения (WAF) — блок по токенам
(http.user_agent contains "GPTBot") or
(http.user_agent contains "OAI-SearchBot") or
(http.user_agent contains "ClaudeBot") or
(http.user_agent contains "PerplexityBot") or
(http.user_agent contains "CCBot")
Полезно включить автоматические опции блокировки ИИ-скрейперов, если они есть у вашего провайдера. Для «серых» случаев применяйте JS-челлендж или «управляемое испытание», чтобы не резать полезных роботов и людей, заходящих со странных сетей. В особо шумных сегментах помогает ограничение скорости и количества одновременных соединений на IP/подсеть/ASN.
Уровень 4. Фильтрация по IP/ASN и верификация диапазонов
Часть операторов публикует диапазоны адресов, с которых ходят их боты. Это удобно, когда нужен именно «жёсткий» контур: например, вы хотите пускать только поисковые системы и блокировать весь ИИ-краулинг на уровне сети. Имейте в виду, что не все игроки публикуют списки, а часть «проблемных» ботов меняет подсети и автономные системы. Поэтому фильтрация по IP — это дополнение, а не главный щит.
# Nginx: грубая фильтрация по известным подсетям (пример)
geo $bad_ai {
default 0;
203.0.113.0/24 1; # подозрительная подсеть
198.51.100.0/24 1;
}
map $bad_ai $block_ai { 1 1; 0 0; }
if ($block_ai) { return 403; }
Гораздо безопаснее выделять доверенные адреса (allowlist) для своих интеграций и партнёров, а всё остальное прогонять через поведенческие правила и челленджи. Актуальные диапазоны известных ботов подтягивайте скриптом и кешируйте на час-другой, чтобы не зависеть от сбоев.
Уровень 5. Поведенческие фильтры и квоты на уровне приложения
Если у вас есть внутренний поиск, API или страницы с тяжёлой выборкой — встраивайте квоты прямо в коде. Лимит на количество запросов в секунду на IP/пользователя, замедление ответов при всплесках, раннее завершение «безопасной» заглушкой — всё это сильно снижает эффективность скрейпинга. Для API полезны подписи запросов (HMAC), ключи с ролями и сроками, а для приватного контента — двойная защита токеном и временем жизни ссылки.
# Nginx: базовое ограничение скорости
limit_req_zone $binary_remote_addr zone=ai_rps:10m rate=5r/s;
server {
location / {
limit_req zone=ai_rps burst=20 nodelay;
}
}
На «дорогие» маршруты поставьте кэш и очередь (waiting room), чтобы бот не «раскручивал» базу. Отдельно закройте административные и служебные пути mTLS или VPN — это не про ИИ-ботов, но снижает общий фон шума и ошибок.
Уровень 6. Хонипоты, «канарейки» и операционный контроль
Добавьте невидимую для людей ссылку-ловушку на страницу с прямым запретом в robots/meta. Любая попытка её открыть — почти наверняка бот. На такие срабатывания стоит заводить алерт и автоматически усиливать правила на периметре. То же самое можно сделать с «канареечными» абзацами текста: уникальные формулировки и ссылки подскажут, где всплыл ваш контент.
Параллельно наладьте отчётность: еженедельно выгрузка топ-ботов, подсетей, правил WAF по срабатываниям, «дорогих» путей. С такой телеметрией решения перестанут быть реактивными: вы заранее увидите новые токены и сетевые источники и добавите их в правила без дедлайнов и пожаров.
Уровень 7. Лицензирование и «белые» каналы
Иногда блокировать всех — значит стрелять себе в ногу. Например, вам важна видимость в ИИ-ответах или вы готовы делиться частью контента на условиях атрибуции. В этом случае формируйте «белые» каналы: разрешайте конкретные боты, ограничивайте частоту и предлагаете машинно-читаемую политику доступа. В идеале — переводите запросы к контенту на лицензированную витрину (API/фиды) с учётом вашей монетизации и с прозрачной отчётностью.
Под это хорошо ложатся «позитивные» записи в robots.txt, TDMRep-политика и «пригласительные» правила на периметре. Если вы находите свой материал в чужих ИИ-ответах без соблюдения запретов и условий — у вас будут и технические, и юридические основания для претензий.
Готовые фрагменты конфигураций
Блокировка по User-Agent на уровне Nginx
map $http_user_agent $is_ai_ua {
default 0;
"~*GPTBot" 1;
"~*OAI-SearchBot" 1;
"~*ChatGPT-User" 1;
"~*ClaudeBot" 1;
"~*Claude-User" 1;
"~*Claude-SearchBot" 1;
"~*PerplexityBot" 1;
"~*CCBot" 1;
"~*Google-Extended" 1;
}
server {
if ($is_ai_ua) { return 403; }
}
Apache (.htaccess): запрет по токенам
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|CCBot|Google-Extended) [NC]
RewriteRule .* - [F,L]
</IfModule>
Cloudflare WAF (идея правила)
(http.user_agent contains "GPTBot") or
(http.user_agent contains "OAI-SearchBot") or
(http.user_agent contains "ClaudeBot") or
(http.user_agent contains "Claude-User") or
(http.user_agent contains "Claude-SearchBot") or
(http.user_agent contains "PerplexityBot") or
(http.user_agent contains "CCBot") or
(http.user_agent contains "Google-Extended")
Сценарии внедрения по типам проектов
Медиа и блоги
Начните с жёсткого запрета в robots.txt для ИИ-ботов и отметьте страницы тегами noai, noimageai. На периметре — пользовательский челлендж для «неизвестных» агентов и умеренный рейт-лимит. Для особо «дорогих» лонгридов и эксклюзивов поставьте кэш и хонипот-ссылки, чтобы быстро ловить скрытых скрейперов.
Для SEO ничего не ломайте: поисковики по-прежнему должны видеть сайт. При желании можно сделать «витрину» для лицензированного доступа ИИ-сервисов и аккуратно разрешать их в robots.txt под отчётность.
Интернет-магазины и маркетплейсы
Главная цель — защитить поиск, корзину, карточки с динамической ценой и остатками. Делайте лимиты на приложение, ставьте кэш на списки, ограничивайте параллельность запросов, включайте «китайскую стражу» на подозрительные подсети и гео. Часть путей (поиск, сравнение, калькуляторы) отгородите челленджем.
Вторая цель — защита от копирования ассортимента. Для этого пригодятся токенизированные фиды и подписанные ссылки для партнёров, а публичные страницы ограничивайте по скорости и частоте сканирования. Хонипоты и уникальные «канарейки» в описаниях помогут доказывать несанкционированное использование.
SaaS и документация
Документацию можно отдавать, но дозированно: разрешите индексным поисковикам и прикрутите ограничение для ИИ-ботов. Для API — только аутентифицированный доступ, ключи, квоты, подписи. Публичные демо-маршруты спрячьте за кэшем, а странные паттерны режьте на периметре.
Отдельно продумайте «белые» интеграции: многие ИИ-платформы охотно соблюдают условия, если им предложить официальный канал с нормальными лимитами и атрибуцией.
Мониторинг и контроль
Нужны не только правила, но и измерения. Сводите ежедневно топ-агентов, топ-подсетей, срабатывания правил, списки «дорогих» путей. Смотрите на долю небраузерных запросов и на пиковую интенсивность. Любая заметная новинка — кандидат на правило в robots.txt и на периметре. Раз в квартал делайте ревизию всех «сигналов» и обновляйте политику TDMRep.
Проверяйте, кто реально следует вашим правилам: для compliant-ботов достаточно мягких мер, для остальных — повышайте строгость. Не бойтесь экспериментировать с челленджами, но не забывайте про доступность: важные сервисы и страницы должны оставаться удобными для людей.
Чек-лист внедрения
- Составьте список ИИ-ботов, которых вы не хотите видеть на сайте. Обновляйте его регулярно.
- Настройте
robots.txtс явными правилами для ИИ-агентов. Разрешите только то, что точно нужно. - Добавьте метки
noai/noimageaiи заголовокX-Robots-Tagна страницы и файлы. - Включите на периметре правила WAF/CDN: блок по токенам, челлендж «неизвестных», рейт-лимит.
- Защитите «дорогие» маршруты: кэш, квоты в приложении, HMAC для API, токены и TTL на ссылки.
- Разверните хонипоты и «канарейки», подключите алерты.
- Для Европы — внедрите TDMRep (
tdm-reservationи/.well-known/tdmrep.json), опишите лицензионные условия. - Настройте отчётность: ежедневные и недельные сводки, квартальная ревизия правил.
- При необходимости — предложите «белый» канал доступа для партнёров и ИИ-сервисов.
Итог
ИИ-боты — это не «чужая беда», а новая реальность веба. Их нельзя просто отключить одной галочкой, но можно поставить рамки: от предупреждающих сигналов до строгого периметра и собственных квот. Ключ в том, чтобы управлять, а не воевать со всем сразу. Тогда вы сохраните и производительность, и ценность контента, и возможность сотрудничать с теми играми, кто уважает правила.