23 апреля 2026 г.12 мин чтения

Cloudflare AI Audit и Bot Management: как управлять AI-ботами на сайте

Разбор Cloudflare AI Audit и Bot Management: как понять, какие AI-боты ходят на сайт, что разрешать, что блокировать и как монетизировать crawl.

Владислав Пучков

Основатель GEO Scout, эксперт по GEO-оптимизации

В 2026 году веб-трафик от AI-ботов стал сопоставим с трафиком от поисковых роботов. По данным Cloudflare, более 1 трлн AI-запросов к веб-сайтам прошло через их инфраструктуру только за второй квартал 2025 года. При этом большинство DevOps- и SRE-команд до сих пор управляют этим трафиком инструментами, написанными под классические поисковые краулеры: одним файлом robots.txt и базовым rate limiting.

Cloudflare предложил другой подход. AI Audit и обновлённый Bot Management дают гранулярный контроль: видно, кто именно ходит на сайт, с какой частотой, какие страницы берёт. И — что важнее — можно задать политику на уровне конкретного бота, а не всего класса агентов.

Что такое Cloudflare AI Audit

Cloudflare AI Audit — это раздел в дашборде Cloudflare, запущенный в 2024 году. Он агрегирует данные о запросах от AI-агентов и представляет их в виде таблицы: бот, количество запросов за период, топ URL, которые он обходит.

Ключевое отличие от стандартной аналитики трафика — классификация по типу агента. Cloudflare разделяет:

• AI Search боты — индексируют контент для поиска в реальном времени (OAI-SearchBot, PerplexityBot, ClaudeBot)
• AI Training боты — собирают данные для обучения базовых моделей (GPTBot, CCBot, Common Crawl)
• AI Assistant боты — действуют по запросу пользователя из продукта (ChatGPT-User, Claude-User)
• Unverified AI боты — агенты с AI-строкой в User-Agent, не прошедшие верификацию

Для каждой записи в таблице доступно управление политикой: Allow, Block, Rate Limit. Политика применяется на уровне бота, а не на уровне IP или ASN, что устраняет ложные срабатывания при смене адресов у легитимных краулеров.

До появления AI Audit единственным способом понять состав AI-трафика был лог-анализ — трудоёмкий, требующий настройки парсинга и обновления при появлении новых ботов. AI Audit делает это из коробки.

Как работает детекция и верификация подлинности бота

Не каждый запрос с User-Agent GPTBot/1.0 действительно отправлен OpenAI. Cloudflare выявляет таких имитаторов через двухступенчатую проверку.

Шаг 1 — Reverse DNS. По IP-адресу входящего запроса делается PTR-запись. Для легитимного GPTBot она должна разрешаться в домен вида crawl.openai.com.

Шаг 2 — Forward DNS. Для полученного hostname делается A-запись обратно. Если она совпадает с исходным IP — бот верифицирован. Если нет — классифицируется как Unverified.

Самостоятельная проверка через командную строку:

# Проверка PTR-записи для IP бота из логов
nslookup 23.102.140.112
# Ожидаемый ответ: crawl.openai.com
 
# Форвардная проверка
nslookup crawl.openai.com
# Должен вернуть тот же IP

Cloudflare автоматизирует эти проверки для всего трафика и маркирует результат в панели AI Audit. Неверифицированные боты с AI-строкой в User-Agent получают отдельную категорию — они могут быть заблокированы без риска задеть легитимные краулеры.

Функции Bot Management для AI-трафика

Bot Management в Cloudflare изначально проектировался под защиту от скрапинга и DDoS. С ростом AI-трафика функциональность расширилась под новые сценарии.

Политики на уровне бота

Через Bot Management Rules можно создать WAF-правило, которое реагирует на конкретный User-Agent или на классификатор Cloudflare cf.bot_management.verified_bot:

# Пример WAF Expression в Cloudflare (синтаксис Ruleset Engine)
# Блокировать неверифицированных AI-агентов
(cf.bot_management.score lt 30 and not cf.bot_management.verified_bot)
 
# Rate limit для CCBot — разрешить, но ограничить
(http.user_agent contains "CCBot") -> rate limit 10 req/min
 
# Разрешить без ограничений верифицированные поисковые боты
(cf.bot_management.verified_bot and
 http.user_agent contains "OAI-SearchBot")

Rate Limiting для AI-краулеров

Rate Limiting в Cloudflare позволяет задать порог запросов отдельно для AI-агентов. Это полезно, когда бот ведёт себя агрессивно (интенсивный обход за короткое время), но его нежелательно полностью блокировать.

Рекомендуемые пороги для начала (корректируются по данным из AI Audit):

AI Labyrinth: honeypot для неавторизованных ботов

AI Labyrinth — функция Cloudflare, анонсированная в 2025 году. Вместо прямой блокировки нарушителей (ботов, игнорирующих robots.txt или политику Bot Management) Cloudflare перенаправляет их в серию сгенерированных AI-страниц.

Механика: бот получает 200 OK с контентом — но контент не имеет ценности и не принадлежит сайту. Генерируется на лету Cloudflare Workers с помощью LLM. Страницы содержат ссылки на другие страницы лабиринта. Бот продолжает обход, тратит ресурсы, но не получает ни одной реальной страницы сайта.

Для владельца сайта это даёт два эффекта:

1. Защита контента — неавторизованный бот не получает реальные данные.
2. Детекция — боты, зашедшие в лабиринт, логируются. Можно построить список недобросовестных краулеров и принять решение об эскалации (жёсткий блок, юридическое уведомление, контакт с провайдером).

AI Labyrinth активируется в настройках Bot Management и применяется только к трафику, который попал под политику "Challenge" или к неверифицированным агентам. Верифицированные боты с разрешённой политикой лабиринт не видят.

Pay per crawl: монетизация AI-трафика

Cloudflare анонсировал pay per crawl как ожидаемый функционал для полноценного запуска в 2026 году. Концепция: владелец сайта устанавливает цену за одну страницу, запрошенную AI-ботом. AI-компания платит автоматически через биллинг Cloudflare.

Схема работы:

AI-бот запрашивает страницу
         ↓
Cloudflare проверяет политику сайта
         ↓
Если политика = pay-gated → возвращает 402 Payment Required
         ↓
Бот (или его оператор) подтверждает платёж
         ↓
Cloudflare пропускает запрос и списывает кредит

Для владельцев сайтов с высокоценным контентом (аналитика, исследования, специализированные базы данных) pay per crawl создаёт прямой revenue stream от AI-компаний. Для медиа и блогов это менее актуально из-за низкой стоимости страницы.

Практически важно: модель работает только с AI-компаниями, которые договорились с Cloudflare об интеграции биллинга. На момент написания это экспериментальная программа с ограниченным числом участников со стороны AI-провайдеров.

Настройка Cloudflare AI Audit: пошаговый порядок

Шаг 1. Включить Bot Management

Bot Management входит в тарифы Pro и выше. Для Enterprise доступны расширенные функции (кастомные ML-модели, детекция с учётом сессий).

Cloudflare Dashboard → [ваш домен] → Security → Bots → Enable Bot Fight Mode

Для Pro и выше: Security → Bots → Bot Management.

Шаг 2. Открыть AI Audit

Security → Bots → AI Audit

Здесь отображается таблица AI-агентов за выбранный период: имя бота, тип (Search / Training / Assistant / Unverified), количество запросов, топ-страницы.

Шаг 3. Задать политику для каждого бота

Для каждой строки в таблице доступны действия:

• Allow — пропускать без ограничений
• Block — возвращать 403
• Rate Limit — ограничить по частоте
• Challenge — CAPTCHA или JS-challenge (не рекомендуется для ботов — они не решают CAPTCHA)
• AI Labyrinth — перенаправить в honeypot

Шаг 4. Добавить WAF-правила для гранулярности

Если нужно разграничить политику по разделам сайта (например, разрешить боту обходить /blog, но закрыть /api и /dashboard):

# Закрыть /api/* для всех AI-ботов, даже верифицированных
(starts_with(http.request.uri.path, "/api/") and
 cf.bot_management.verified_bot and
 http.user_agent contains "Bot")
→ Block
 
# Разрешить /blog/* для поисковых AI-ботов
(starts_with(http.request.uri.path, "/blog/") and
 cf.bot_management.verified_bot)
→ Allow

Шаг 5. Настроить оповещения

Notifications → Create → Security Events — можно настроить алерт при резком росте AI-трафика. Это полезно для обнаружения агрессивного краулинга до того, как он создаст нагрузку на origin.

Стратегия: что разрешать, что блокировать

Главный принцип: разделяйте поисковые боты и тренировочные боты. Они решают разные задачи и их блокировка даёт разные последствия для GEO-видимости бренда.

Как связать настройки Bot Management с мониторингом GEO

Управление ботами — это инфраструктурное решение, но его последствия видны в маркетинговых метриках. Вот где они пересекаются:

Domain Citation Rate — метрика того, как часто AI-системы ссылаются на домен как источник. Если заблокировать поисковый бот, домен перестаёт попадать в индекс этого провайдера и Citation Rate падает. GEO Scout измеряет этот показатель раздельно для каждого AI-провайдера, поэтому падение от блокировки конкретного бота видно изолированно.

Mention Rate — как часто бренд упоминается в ответах без прямого цитирования. Зависит от накопленных обучающих данных, поэтому блокировка GPTBot влияет на него медленнее — через несколько циклов переобучения модели.

Log-анализ AI-ботов — данные Cloudflare AI Audit дополняют анализ логов на стороне сервера. Cloudflare видит все запросы, включая те, что не дошли до origin (заблокированы на уровне CDN). Серверные логи показывают только то, что прошло. Вместе это полная картина.

Практический маршрут: после изменения политики в Bot Management подождите 7-10 дней и сверьте данные AI Audit (количество запросов от конкретного бота) с метриками в GEO Scout (Domain Citation Rate для соответствующего провайдера). Корреляция между разрешённым трафиком и цитируемостью обычно чёткая.

Альтернативы Cloudflare: что делать без него

Не все инфраструктуры стоят за Cloudflare. Альтернативные подходы:

AWS WAF с Bot Control. Managed Rules группа AWSManagedRulesBotControlRuleSet включает детекцию AI-ботов. Менее детальная, чем Cloudflare AI Audit, но работает для EC2 и ALB без смены CDN. Стоимость — $10/млн запросов за Bot Control.

nginx rate limiting по User-Agent:

# /etc/nginx/conf.d/ai-bots.conf
geo $is_ai_training_bot {
    default 0;
    # CCBot диапазоны (обновляйте регулярно)
    # Проверяйте актуальные IP через whois CCBot
}
 
map $http_user_agent $ai_bot_limit_key {
    default                 "";
    "~CCBot"               $binary_remote_addr;
    "~Bytespider"          $binary_remote_addr;
}
 
limit_req_zone $ai_bot_limit_key zone=ai_training:10m rate=10r/m;
 
server {
    location / {
        limit_req zone=ai_training burst=5 nodelay;
    }
 
    location /api/ {
        # Закрыть /api для всех известных AI-ботов
        if ($http_user_agent ~* "(GPTBot|CCBot|ClaudeBot|PerplexityBot)") {
            return 403;
        }
    }
}

Fastly Next-Gen WAF (Signal Sciences). Аналог Cloudflare Bot Management для инфраструктур на Fastly. Детекция по поведенческим паттернам, а не только по User-Agent.

Self-hosted: fail2ban + лог-анализ. Для небольших сайтов: парсинг access.log, выявление агрессивных краулеров по частоте запросов, автоматический бан через iptables. Требует поддержки и не даёт визуализации AI Audit.

Принципиальное ограничение любой альтернативы: нет готового реестра AI-ботов с автоматическим обновлением. Cloudflare поддерживает список самостоятельно и обновляет его при появлении новых агентов. На nginx и AWS WAF обновление словарей User-Agent — ручная операция.

Конфликт интересов: блокировка vs. GEO-видимость

Здесь возникает реальное противоречие, которое команды часто не замечают до тех пор, пока не фиксируют падение в данных мониторинга.

Логика безопасника: «Боты нагружают сервер, скрапят контент, непонятно кому отдают данные — блокируем всё AI.»

Логика GEO-специалиста: «Если заблокировать ClaudeBot и PerplexityBot, бренд пропадает из cited sources в Claude и Perplexity. Это снижает Domain Citation Rate и в итоге — органический трафик из AI-поиска.»

Правильное решение — не «блокировать всё» и не «разрешать всё», а гранулярная политика по типу бота:

• Поисковые боты (OAI-SearchBot, ClaudeBot, PerplexityBot, Googlebot, BingBot) — Allow без ограничений для публичного контента.
• Тренировочные боты (GPTBot, CCBot) — политика зависит от позиции компании по использованию контента для обучения LLM.
• Неверифицированные агенты — Block или AI Labyrinth.
• Агрессивные краулеры (ByteSpider и аналоги) — Block или жёсткий Rate Limit.

Важно держать это разграничение в технической документации проекта, иначе следующий DevOps-engineer при очередной настройке WAF может «упростить» правила и случайно заблокировать поисковые боты.

Чек-лист настройки Cloudflare AI Audit

• Bot Management включён (тариф Pro или выше)
• AI Audit открыт, данные за последние 30 дней изучены
• Верифицированные поисковые боты (OAI-SearchBot, ClaudeBot, PerplexityBot, Googlebot, BingBot) — политика Allow
• GPTBot — политика определена осознанно (Allow или Rate Limit, не Block без понимания последствий)
• CCBot — Block или Rate Limit 10 req/min
• Unverified AI боты — Block или AI Labyrinth
• ByteSpider — Block
• WAF-правила закрывают /api/, /admin/, /dashboard/ от всех AI-ботов
• Rate Limit настроен для тренировочных ботов
• AI Labyrinth активирован для категории Unverified
• Оповещение при аномальном росте AI-трафика настроено
• Политики задокументированы в wiki/runbook команды
• Через 7-10 дней после изменений — сверка с данными GEO-мониторинга

Итог

Cloudflare AI Audit превратил управление AI-ботами из ручной работы в настраиваемую политику. Ключевое — разделять поисковые и тренировочные боты: первые дают цитируемость, вторые отдают контент на обучение LLM. Блокировать всё подряд — значит терять видимость в AI-ответах. Разрешать всё — значит отдавать контент без контроля.

Ожидаемый pay per crawl добавит третий вектор: монетизацию. Контент перестанет быть просто «пропускать или не пропускать» — он получит цену.

Для команд, которые уже работают с GEO-метриками, Bot Management — это не только инфраструктурная задача. Каждое изменение политики влияет на Domain Citation Rate и Mention Rate. GEO Scout ежедневно мониторит эти показатели в 10 AI-провайдерах — включая разбивку по провайдерам, которая позволяет видеть, какой именно бот даёт цитируемость, а какой только создаёт нагрузку.

Если вы только начинаете работу с AI-ботами, прочитайте смежные материалы: как анализировать логи AI-ботов, технический чек-лист сайта для нейросетей и что такое Domain Citation Rate.