Блокировать ли AI-ботов: практическая настройка robots.txt, логов и Cloudflare

К 2026 году спор «открывать AI-краулерам сайт или нет» перестал быть философским: у большинства владельцев контента накопилась реальная статистика нагрузки и трафика из AI-выдачи. Универсального «да» или «нет» нет и не будет — есть конкретная настройка под тип бота и тип сайта. Ниже — что смотреть в логах, что писать в robots.txt, где ловится обман через Cloudflare и как проверить, что правки вообще сработали.

Шаг 1. Посмотри в логах, кто реально заходит

Прежде чем блокировать, проверь фактическую картину — интуиция почти всегда расходится с логами.

Если сайт на своём сервере (VPS, выделенный, VDS-хостинг с shell-доступом):

grep -i "GPTBot" /var/log/nginx/access.log | wc -l
grep -i "ClaudeBot" /var/log/nginx/access.log | wc -l
grep -i "PerplexityBot" /var/log/nginx/access.log | wc -l

Смотри не только количество запросов, но и код ответа в конце строки (частые 429/503 — сервер уже давится) и путь запроса. Если бот ломится в /wp-json/, /search?q= или в закрытые формами разделы — это похоже на парсинг под видом AI-агента, а не на легитимный краулинг, и здесь работает уже не robots.txt, а бан по IP/User-Agent на уровне сервера.

На хостинге без shell — ищи «Логи доступа» / «Access logs» в панели (ISPmanager, cPanel → Logs → Raw Access Logs) либо подключи Cloudflare — там нагрузка по ботам видна в дашборде без консоли (см. шаг 4). Подробнее о том, как читать логи сервера, можно узнать в статье Как читать логи сервера для диагностики проблем индексации .

Проверь текущий robots.txt одной командой:

curl -IL https://ваш-домен.ru/robots.txt

Код 404 вместо 200 означает, что файла нет физически — разговор о блокировке ботов бессмыслен, пока файл не создан. Узнать, как правильно настроить robots.txt в 2026 году, поможет материал Что такое robots.txt в 2026 году: как настроить, проверить и не потерять индексацию .

Проверь и мета-теги: открой любую статью, Ctrl+U (просмотр исходного кода страницы), ищи <meta name="robots">. Если там уже стоит noai, noimageai — это добровольная директива: крупные модели не обязаны её соблюдать. Реальный контроль — только User-agent в robots.txt плюс правило на сервере или CDN.

Шаг 2. Раздели ботов на три группы — от этого зависит правило

Правило простое: если бот ищет ответ на конкретный запрос пользователя здесь и сейчас (поисковые AI) — он потенциально приводит человека на сайт через ссылку в ответе. Если бот собирает массив для тренировки будущей модели (обучающие) — прямой выгоды в моменте нет, только расход ресурсов сервера.

Шаг 3. Готовые блоки robots.txt под три типа сайта

Интернет-магазин или сервис — открыть максимум, цель — попасть в рекомендации AI-ассистентов:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Allow: /

User-agent: Google-Extended
Allow: /

Логика: если ChatGPT посоветует товар со ссылкой на карточку — это прямая продажа, риск «обучения на ценах» вторичен по сравнению с охватом.

Информационный сайт / блог / СМИ — правило «Search Yes, Training No»:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Сайт с платным контентом (paywall) — блок всех без исключения плюс проверка, что закрытые формой разделы физически не отдаются ботам напрямую (частая дыра — статичный кэш страницы, который CDN отдаёт до проверки авторизации):

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

Важный нюанс: robots.txt — это джентльменское соглашение, а не стена. Если видишь в логах, что «заблокированный» бот всё равно долбит сайт (шаг 1), добавляй жёсткое правило на уровне сервера — например, в nginx:

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

Это уже не рекомендация, а отказ в обслуживании — сработает даже для ботов, которые молча игнорируют robots.txt.

Шаг 4. Проверь, не перебивает ли Cloudflare твои же правила

Если сайт за прокси Cloudflare — настройки robots.txt могут быть просто декорацией. В разделе Security → Bots (в некоторых аккаунтах пункт называется «AI Scrapers and Crawlers» или встроен в AI Audit) стоит общий тумблер блокировки AI-ботов на уровне edge, до того как запрос вообще дойдёт до сервера. Частая ситуация: вебмастер закрыл бота в robots.txt, но забыл, что общий тумблер в Cloudflare либо, наоборот, пропускает бота как «доверенного», игнорируя локальный файл.

Проверка занимает одну команду — подмени User-Agent и посмотри на код ответа:

curl -A "GPTBot" -IL https://ваш-домен.ru/

Если получаешь 403 от Cloudflare, хотя в robots.txt бот разрешён (или наоборот, 200 там, где должен быть блок) — значит правило переопределяется на уровне edge, и искать проблему нужно в дашборде Cloudflare, а не в файле на сервере.

Шаг 5. Проверь эффект не на словах, а по факту индексации

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

• Если после блокировки обучающих ботов резко упал трафик из classic-поиска — вероятно, зацепило не того бота (например, случайно закрыли Googlebot вместе с Google-Extended — это разные user-agent, но их путают). Для массовой сверки статуса всех URL до/после правки удобно гонять список страниц через Rush Analytics — сервис делает пакетную проверку индексации и подсвечивает, какие адреса выпали.
• Для точечной проверки одной конкретной страницы (заголовки ответа, мета-роботы, статус в индексе) быстрее сделать экспресс-снимок через PR-CY, чем вручную собирать данные по каждому URL.
• Если после открытия сайта для поисковых AI-ботов (OAI-SearchBot, PerplexityBot) хочешь ускорить попадание конкретных обновлённых страниц в обычный поиск — не жди органического повторного обхода неделями, а отправь список URL через индексатор IndexMeNow: это быстрее, чем полагаться только на естественный краулинг.

Для Яндекса отдельно: правильный путь для мгновенного уведомления об изменениях — IndexNow-совместимый инструмент или Вебмастер Яндекса (раздел «Переобход страниц»), а не полагаться на то, что YandexAdditional сам всё найдёт. Блокировать YandexAdditional без явной причины не стоит — это часть общей экосистемы Яндекса, и последствия для доверия к ресурсу документированы не полностью, поэтому дешевле не трогать, если нет конкретной жалобы на утечку контента.

Чек-лист перед тем, как трогать robots.txt

1. Проверил логи сервера — знаю, какие боты реально заходят и с какой частотой (шаг 1).
2. Разделил ботов на поисковые / обучающие / гибридные, а не банил всех оптом (шаг 2).
3. Выбрал шаблон под тип сайта: e-commerce — открыть, инфосайт — «search yes, training no», paywall — закрыть всё (шаг 3).
4. Добавил серверное правило (403 по User-Agent) для ботов, которые игнорируют robots.txt.
5. Проверил через curl -A и дашборд Cloudflare, что edge-правила не противоречат файлу (шаг 4).
6. Через 3–5 дней после изменений сверил индексацию по списку URL, а не по ощущениям (шаг 5).

Если после всех правок сайт продолжает терять позиции в классическом поиске — это почти никогда не про AI-ботов напрямую, а про экономию краулингового бюджета: агрессивный обучающий бот на дешёвом хостинге может делить один и тот же лимит пропускной способности с Googlebot, что часто связано с неэффективным распределением Crawl budget . В таком случае в первую очередь режется именно обучающий трафик — GPTBot и ClaudeBot, — а поисковые AI-агенты остаются открытыми.

Дополнительное чтение: GPTBot, OAI-SearchBot, ChatGPT-User: как в 2026 году разделить доступ ИИ-ботов OpenAI без потери трафика и Как попасть в ChatGPT Search: OAI-SearchBot и robots.txt .