WordCountBot — один из ботов, у которых при проверке в открытых источниках не находится ни официальной страницы оператора, ни задокументированного назначения, ни диапазона IP-адресов. Сам факт такого отсутствия прозрачности — уже часть ответа на вопрос, почему TrafficVeil относит его к нежелательным. Ниже — как распознать этот User-Agent в логах, на что реально указывает его активность и как ограничить доступ через robots.txt, веб-сервер или TrafficVeil.
Что известно о WordCountBot и чего установить не удалось
Название бота указывает на функцию подсчёта объёма текста на странице — это типичная задача для сервисов конкурентного контент-анализа: такие инструменты сканируют массу страниц подряд, чтобы оценить длину текста, плотность ключевых слов или глубину проработки темы у конкурентов в нише. Но в отличие от Googlebot, Bingbot или того же W3C-валидатора, у WordCountBot нет публичной страницы с описанием сервиса, нет официального документа с диапазоном IP и нет ответа на вопрос, кто именно им управляет и с какой целью. Это не редкость среди ботов, помеченных в базах как «нежелательные»: часть таких агентов работает от лица закрытых SEO-инструментов, скраперов контента или сервисов, которые не заинтересованы афишировать себя владельцам сайтов.
Как работает WordCountBot
- Идентифицируется в access.log по паттерну User-Agent
wordcountbot; - Выполняет автоматические HTTP(S)-запросы к публичным URL сайта;
- По косвенным признакам (название, поведение похожих инструментов) — обход страниц для анализа объёма и структуры контента;
- В панели TrafficVeil относится к кластеру «Прочие краулеры и сервисы» с меткой «нежелательный» и может быть запрещён или ограничен точечно.
Почему отсутствие документации — сам по себе сигнал
У крупных легитимных краулеров (поисковых, валидаторов, агрегаторов) почти всегда есть публичная страница с объяснением цели обхода, контактами и часто — официальным списком IP для верификации: это в их интересах, потому что иначе владельцы сайтов будут блокировать их вслепую. Отсутствие такой страницы у бота, который тем не менее регулярно обходит чужие сайты, обычно означает одно из двух: либо это внутренний служебный агент стороннего SaaS-продукта, не рассчитанный на паблик, либо инструмент, оператор которого сознательно не хочет попадать в списки для блокировки. В обоих случаях у владельца сайта нет способа получить пользу от такого трафика — только нагрузку, поэтому дефолтная рекомендация «нежелательный» в базе TrafficVeil для таких агентов обоснована.
Нагрузка на сервер
На отдельных доменах поведение WordCountBot может выглядеть как волна автоматических запросов без пользовательских сессий: много ответов 200 OK, но без роста реальных визитов или конверсий. Стоит обращать внимание на такие признаки:
- рост RPS без роста конверсий;
- последовательный обход пагинации или каталога, характерный для массового сбора текста, а не точечной проверки одной страницы;
- повторяющиеся запросы к тяжёлым (объёмным по контенту) страницам — логично для бота, который именно измеряет длину текста;
- запросы к HTML без сопутствующей загрузки CSS, JS и изображений — признак скрипта, а не реального браузера или полноценного рендерящего краулера.
Как найти бота в логах
# Все запросы
grep -i "wordcountbot" /var/log/nginx/access.log
# Количество запросов за сегодня
grep -i "wordcountbot" /var/log/nginx/access.log | grep "$(date '+%d/%b/%Y')" | wc -l
# Уникальные IP
grep -i "wordcountbot" /var/log/nginx/access.log | awk '{print $1}' | sort -u
# Частота по дням
grep -i "wordcountbot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -cВерификация: почему для этого бота она особенно важна
User-Agent легко подделать, а для бота без официального сайта и без публичного списка IP это особенно актуально: сослаться на «доверенный источник» с описанием диапазонов адресов, как это можно сделать для Googlebot через обратный DNS на *.google.com, здесь не получится. Единственный практичный путь — сопоставить IP с ASN и репутацией сети:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"Если один и тот же паттерн User-Agent приходит с разных, никак не связанных между собой подсетей — вероятно, часть трафика вообще не имеет отношения к настоящему WordCountBot, а просто маскируется под него, чтобы обойти простые фильтры по имени.
Блокировка через robots.txt
# Полная блокировка
User-agent: wordcountbot
Disallow: /
# Точечное ограничение
User-agent: wordcountbot
Disallow: /admin/
Disallow: /cart/
Disallow: /account/
Allow: /
# Разрешить полностью
User-agent: wordcountbot
Allow: /Учитывайте: раз у бота нет публичного заявления о соблюдении стандарта исключений, полагаться только на robots.txt рискованно — агент вполне может его игнорировать. Для гарантированного контроля нужны серверные правила или блокировка на уровне TrafficVeil.
Управление на уровне сервера
Nginx — жёсткая блокировка или мягкий rate-limit:
if ($http_user_agent ~* "wordcountbot") {
return 403;
}
# Мягкий вариант — rate limit
limit_req_zone $binary_remote_addr zone=wordcountbot:10m rate=15r/m;
location / {
if ($http_user_agent ~* "wordcountbot") {
limit_req zone=wordcountbot burst=30 nodelay;
}
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} wordcountbot [NC]
RewriteRule ^ - [F,L]Управление через TrafficVeil
- Откройте список известных ботов в панели домена или в разделе
/system/bots. - Найдите
wordcountbot/WordCountBot. - Поскольку бот уже помечен в базе как «нежелательный», по умолчанию логично оставить категорию «запретить» либо жёсткий rate-limit, а не «разрешить».
- При необходимости используйте массовые операции allow/deny без правки origin-сервера.
- Проверьте логи: запросы должны уходить в блок или лимит согласно выбранной политике.
Практические рекомендации
- Раз бот не привязан к известному публичному сервису, приносящему пользу сайту (поиск, превью в соцсетях, легитимный мониторинг), по умолчанию оправдан запрет или жёсткий rate-limit;
- Не блокируйте поисковые роботы Google/Yandex случайно, если рядом настраиваете широкие правила по неймингу;
- Сначала измерьте долю запросов бота в логах или в аналитике TrafficVeil, потом принимайте решение — если объём небольшой, спешный жёсткий 403 не даст ощутимого эффекта на нагрузку, но полезен как гигиена;
- Для всплесков вместо полного 403 обычно достаточно rate-limit, особенно если часть трафика может оказаться спуфингом с других IP;
- Контент лучше отдавать server-side, если хотите контролируемую индексацию только легитимными агентами, а не любым скриптом, представившимся ботом.
Похожие боты и сервисы для сравнения
| Бот | Кластер | User-Agent | Метка |
| 360Spider | Прочие краулеры и сервисы | 360spider | нежелательный |
| A360-Search | Прочие краулеры и сервисы | a360-search | нежелательный |
| AASA-Bot | Прочие краулеры и сервисы | aasa-bot | нежелательный |
| ABEvalBot | Прочие краулеры и сервисы | abevalbot | нежелательный |
| ActiveComply | Прочие краулеры и сервисы | activecomply | нежелательный |
Итоговая стратегия
| Цель сайта | Рекомендация |
| Нужен пример редкого исключения — бот подтверждённо приносит пользу конкретному бизнесу | Точечно разрешить в TrafficVeil, зафиксировав причину |
| Бот не нужен и только грузит сервер (типичный случай) | Disallow + запрет в TrafficVeil или 403 на nginx/Apache |
| Нужно ограничить, но не блокировать полностью из-за риска спуфинга | Rate-limit вместо полной блокировки |
| Нежелательный бот по базе TrafficVeil без известной пользы (данный случай) | Запретить в /system/bots и контролировать по логам |