ContentBot: скорее точечный fetcher, чем сборщик для AI

ContentBot принадлежит не безымянному AI-пайплайну, а реальной, работающей с 2021 года компании ContentBot.ai (Майами, США) — платформе AI-генерации контента для маркетологов и блогеров, в одном ряду с Anyword и Copy.ai. Черновик утверждает, что «почти наверняка ваш контент интересен как сырьё для AI-продукта» в духе GPTBot — но по функциям самой платформы более вероятен другой, гораздо менее тревожный сценарий.

1. Что такое ContentBot на самом деле

ContentBot.ai — AI-платформа для генерации блог-постов, лендингов и рекламных текстов, с более чем 77 000 зарегистрированных пользователей, интеграциями с WordPress, Chrome, Google Docs и другими сервисами. Среди функций платформы — «AI Importer» и инструменты массового импорта CSV/PDF, которые позволяют пользователям загружать существующий контент (свой или чужой) в качестве референса или сырья для дальнейшей AI-обработки внутри сервиса.

Это принципиально другая модель, чем у training-краулеров вроде GPTBot: там бот системно обходит веб по расписанию для пополнения обучающих датасетов модели. Здесь, судя по функциям продукта, более вероятен user-triggered fetcher — запрос к конкретному URL, который инициировал конкретный пользователь платформы, импортируя чужую или свою страницу как референс для генерации контента.

2. Зачем ContentBot приходит на сайт

• пользователь платформы использует функцию AI Importer или массового импорта, указав ваш URL как источник для анализа/референса перед генерацией собственного контента;
• это может быть как ваш же собственный сайт (если вы сами пользуетесь ContentBot для своего контент-маркетинга), так и сайт конкурента, который кто-то использует как ориентир;
• в отличие от training-краулеров, которые системно проходят /blog/, /product/, /category/ по расписанию, такие запросы, вероятнее всего, единичны и привязаны к конкретному моменту работы конкретного пользователя.

Если в логах фиксируется постоянный систематический обход широкого набора страниц сайта, а не единичные точечные запросы к конкретным URL — это может говорить и о другом сценарии, не описанном в открытых источниках платформы; в таком случае стоит опираться на наблюдаемое поведение, а не на предположение о разовом fetcher-запросе.

3. Нагрузка и риски

Если верна гипотеза о user-triggered fetcher, нагрузка от ContentBot должна быть эпизодической и точечной — по одному-два запроса на конкретный URL, а не системный краулинг каталога. Формулировка черновика про «ваш контент интересен как сырьё для AI-продукта» ближе по духу к bulk-краулерам вроде GPTBot, которые системно индексируют контент для обучения модели — для user-triggered fetcher это не совсем точное описание риска.

Тем не менее, поскольку официальной документации по самому крауleру нет, нельзя полностью исключить и более широкий сбор данных — платформа явно занимается AI-генерацией контента, для качества которой в принципе полезны большие объёмы примеров текста.

4. Как найти ContentBot в логах

# Базовый поиск
grep -i "contentbot" /var/log/nginx/access.log

# Топ URL — если гипотеза о fetcher верна, ожидаем немного точечных URL, а не широкий обход
grep -i "contentbot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "contentbot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность — эпизодические точечные хиты vs регулярный фон
grep -i "contentbot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

# Проверка гипотезы: сколько уникальных URL всего запрошено этим UA
grep -i "contentbot" /var/log/nginx/access.log | awk '{print $7}' | sort -u | wc -l

Верификация. Строку UA подделать может любой скрипт. Для решения allow/deny смотрите связку UA + IP/ASN + частоту + набор URL — при отсутствии официальных диапазонов для ContentBot это единственный доступный способ:

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

5. robots.txt для ContentBot

# Жёсткий запрет
User-agent: contentbot
Disallow: /

# Разрешить всё
User-agent: contentbot
Allow: /

# Компромисс: закрыть личный кабинет и служебные разделы, оставить публичку
User-agent: contentbot
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

6. Блокировка вручную и через TrafficVeil

Nginx:

if ($http_user_agent ~* "contentbot") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=contentbot:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "contentbot") {
        limit_req zone=contentbot burst=20 nodelay;
    }
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} contentbot [NC]
RewriteRule ^ - [F,L]

TrafficVeil:

• найдите contentbot в разделе ботов домена или в /system/bots;
• если наблюдаемый паттерн — единичные запросы к конкретным URL, а не системный обход — это, вероятно, безобидный разовый fetcher по чужому пользовательскому запросу, и жёсткая блокировка не даст заметного эффекта на общую нагрузку;
• если наблюдается систематический обход каталога/блога — это не соответствует ожидаемому паттерну user-triggered fetcher, здесь уместнее относиться к боту как к обычному AI-краулеру;
• после изменения сверьте логи: хиты ContentBot должны уйти в блок/лимит, а нужные поисковики остаться.

7. Что делать: короткий алгоритм

• Сначала посмотрите на паттерн: единичные точечные URL или широкий систематический обход — от этого зависит вся дальнейшая логика;
• Паттерн точечный, нагрузка минимальна — можно не трогать, реального риска для контента как при training-краулерах здесь меньше;
• Паттерн широкий и системный — относитесь как к обычному AI-краулеру: Disallow, если польза не нужна;
• Нагрузка мешает независимо от паттерна — rate-limit как промежуточный шаг;
• Не блокируйте по маске User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.

8. Открытый вопрос по категоризации

Категория «AI и LLM-краулеры» формально не ошибочна — ContentBot действительно AI-компания. Но, как и в случае с Anyword, стоит различать training-краулеры (GPTBot, ClaudeBot, CCBot — системный фоновый обход для обучения моделей) и user-triggered fetcher-ы, к которым, судя по функции AI Importer, ближе ContentBot — точечные запросы по прямому указанию конечного пользователя платформы. Возможно, для таких ботов стоит завести отдельную под-категорию с иной логикой оценки риска.

9. Стратегия allow/deny для ContentBot