WebsitePulseBot — не «компонент проверки виджета», а реальный, давно работающий (с 2000 года) сервис мониторинга WebSitePulse, который умеет значительно больше простого health-check. Помимо базовой доступности, сервис проверяет содержимое страницы на несанкционированные изменения, симулирует пользовательские транзакции и даже предлагает полноценный in-browser мониторинг на движке WebKit. В каталоге TrafficVeil бот отмечен как легитимный в категории «Прочие краулеры и сервисы».
Что такое WebsitePulseBot на самом деле
WebSitePulse предлагает целую линейку мониторинга: серверный и сетевой (проверка каждую минуту с многих точек мира), веб-страничный (content monitoring — отслеживание несанкционированных изменений содержимого, признаков дефейсмента сайта, скорости загрузки), веб-транзакционный (симуляция реальных пользовательских сценариев — например, оформление заказа) и in-browser мониторинг на движке, идентичном Google Chrome (WebKit), с полной поддержкой JavaScript и CSS.
Официально задокументированный агент — «WebSitePulse Remote Monitoring Agent», который инициирует и выполняет тесты удалённых компонентов e-business (серверов, сайтов, email-систем) сразу из нескольких точек присутствия в интернете.
| Параметр | Значение |
| Название | WebsitePulseBot |
| User-Agent (токен/паттерн) | websitepulsebot (в некоторых каталогах также фигурирует как «websitepulse checker») |
| Оператор | WebSitePulse — сервис мониторинга сайтов и серверов (websitepulse.com, с 2000 года) |
| Назначение | Комплексный мониторинг: аптайм, производительность, содержимое страницы (детект несанкционированных изменений), веб-транзакции, in-browser проверка на движке WebKit |
| Список IP-адресов | ❌ Отдельного полного публичного списка не обнаружено; проверяйте ASN и не доверяйте только строке UA |
| Соблюдение robots.txt | Большинство репутационных операторов мониторинга соблюдают директивы; для точного ответа стоит проверить поведение по факту логов |
| Используется для обучения моделей | Нет — назначение строго про мониторинг доступности, содержимого и производительности |
| Категория TrafficVeil | Легитимный / Прочие краулеры и сервисы |
Зачем WebsitePulseBot приходит на сайт
В зависимости от того, какой именно тип мониторинга настроил клиент WebSitePulse, поведение бота заметно различается. Простая проверка доступности — это лёгкий, узкий запрос к одной-двум страницам с интервалом вплоть до раза в минуту. Content monitoring («Webpage Monitoring») специально ищет несанкционированные изменения содержимого, поэтому периодически сверяет полный текст страницы, а не только код ответа. Web Transaction Monitoring может имитировать целый пользовательский сценарий — например, переход от каталога к оформлению заказа, — что создаёт заметно более широкий след в логах, чем простой health-check.
Нагрузка и риски именно для WebsitePulseBot
Отдельной строки в публичной сводке топ-ботов TrafficVeil у websitepulsebot может не быть, но из-за разнообразия типов мониторинга нагрузка здесь особенно неоднородна. Смотрите не только на абсолютный RPS, но и на:
- тип затронутых URL — узкий набор для простого аптайм-чека, широкий многошаговый путь для транзакционного мониторинга;
- частоту — вплоть до раза в минуту для серверного/сетевого мониторинга;
- отсутствие cookie и признаков полноценной сессии для базовых проверок (транзакционный мониторинг может имитировать сессию гораздо реалистичнее);
- концентрацию на служебных или, наоборот, содержательных страницах в зависимости от выбранного клиентом типа мониторинга.
Как найти WebsitePulseBot в логах
Ищите конкретный токен websitepulsebot, а не общее слово «bot».
# Базовый поиск
grep -i "websitepulsebot" /var/log/nginx/access.log
# Топ URL, которые вычитывает бот
grep -i "websitepulsebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "websitepulsebot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Суточная активность
grep -i "websitepulsebot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
Верификация: User-Agent легко подделать. Для критичных решений дополнительно проверяйте IP/ASN, частоту, path-паттерны — набор URL, соответствующий одному из описанных типов мониторинга (узкий health-check, content-проверка или многошаговая транзакция), хорошо согласуется с легитимным использованием сервиса:
IP="1.2.3.4" whois -h whois.cymru.com " -v $IP" dig +short -x "$IP"
robots.txt для WebsitePulseBot
# Полная блокировка User-agent: websitepulsebot Disallow: / # Точечное ограничение User-agent: websitepulsebot Disallow: /admin/ Disallow: /cart/ Disallow: /account/ Allow: / # Разрешить полностью User-agent: websitepulsebot Allow: /
Учитывайте: не все агенты строго соблюдают robots.txt. Если сайт использует Web Transaction Monitoring, точечное ограничение стоит настраивать особенно аккуратно — оно не должно затрагивать шаги реального симулируемого сценария (например, страницу оформления заказа), иначе мониторинг перестанет корректно проверять именно ту функциональность, ради которой его настроили.
Управление на уровне сервера
Nginx
if ($http_user_agent ~* "websitepulsebot") {
return 403;
}
# Мягкий вариант — rate limit
limit_req_zone $binary_remote_addr zone=websitepulsebot:10m rate=15r/m;
location / {
if ($http_user_agent ~* "websitepulsebot") {
limit_req zone=websitepulsebot burst=30 nodelay;
}
}
Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} websitepulsebot [NC]
RewriteRule ^ - [F,L]
Через TrafficVeil
- откройте список известных ботов в панели домена или
/system/bots; - найдите websitepulsebot / WebsitePulseBot;
- если мониторинг настраивала ваша команда — allow, уточнив у неё конкретный тип мониторинга (простой аптайм, content или транзакционный), чтобы случайно не сломать нужную функцию;
- если чужой и не нужен бизнесу — запрет;
- проверьте логи: запросы должны уходить в блок/лимит согласно выбранной политике.
Рекомендации по оптимизации
- Оценивайте пользу: если это ваш собственный мониторинг — allow; если чужой и не нужен бизнесу — блокируйте или rate-limit;
- не блокируйте поисковые роботы Google/Yandex случайно, если рядом настраиваете широкие правила;
- сначала измерьте долю запросов бота в логах/аналитике TrafficVeil, потом принимайте решение;
- для всплесков чаще достаточно rate-limit вместо полного 403;
- если используется Web Transaction Monitoring — согласуйте точечные ограничения так, чтобы не сломать шаги реального проверяемого сценария.
Сравнение с похожими ботами
| Бот | Кластер | User-Agent | Метка |
| 2ip Bot | Прочие краулеры и сервисы | 2ip bot | легитимный |
| AccessStatus | Прочие краулеры и сервисы | accessstatus | легитимный |
| AddThis.com | Прочие краулеры и сервисы | addthis.com | легитимный |
| Agent | Прочие краулеры и сервисы | agent | легитимный |
| AgentReadinessScanner | Прочие краулеры и сервисы | agentreadinessscanner | легитимный |
Сводная таблица стратегии
| Цель сайта | Рекомендация |
| Мониторинг настраивала ваша команда | Allow / разрешить в TrafficVeil, уточнив конкретный тип мониторинга |
| Мониторинг чужой и не нужен бизнесу | Disallow + запрет в TrafficVeil или 403 на nginx/Apache |
| Мониторинг свой, но беспокоит частота или широта транзакционных проверок | Rate-limit вместо полной блокировки |
| Настроен Web Transaction Monitoring | Точечные ограничения согласовывать так, чтобы не сломать шаги реального сценария |