Прежде чем банить SiteUpTimeBot, спросите свою DevOps-команду

Если фильтровать access.log по siteuptimebot, часто всплывает целый пласт машинных хитов — это и есть SiteUpTimeBot. Платформа synthetic monitoring — имитирует обращение к странице и фиксирует latency. Используется DevOps и SRE для раннего обнаружения простоев. Идентификатор в реестре: «SiteUpTimeBot». Прежде чем блокировать, полезно знать закономерность всей категории uptime-мониторов: у известных аналогов вроде UptimeRobot прямо заявлено, что их трафик практически всегда преднамеренный — кто-то конкретно настроил проверку именно для этого сайта. Это не случайный сторонний обход, а чей-то реальный, часто внутренний health-check.

Что такое SiteUpTimeBot

Сначала спросите свою команду, а не банить сразу

Прежде чем принимать решение, стоит уточнить у DevOps или SRE-команды (своей или клиента), не настроен ли под этим именем реальный мониторинг доступности сайта. Как и у большинства сервисов этой категории, появление такого бота почти всегда означает, что кто-то — вы сами, ваш хостинг-провайдер, агентство или клиент — сознательно поставил конкретный URL на отслеживание, а не что сайт стал целью постороннего обхода. Отдельно стоит учитывать путаницу с похожими названиями: у сервиса Uptime.com когда-то был собственный бот с похожим именем, официально выведенный из эксплуатации ещё в 2019 году, хотя мониторинг от того же провайдера продолжается уже под другим UA. Похожая история может быть и с SiteUpTimeBot — не исключено, что в старых конфигурациях мониторинга остались упоминания сервисов, которые давно не используются или сменили название.

Зачем SiteUpTimeBot приходит на сайт

SiteUpTimeBot проверяет доступность и скорость ответа — свой или чужой uptime/health-check.

• Какие зоны чаще трогает: /, /health, /status, главная, критичные посадочные
• Что ищет: контент, метаданные, availability или ссылочный граф — в логике категории «Мониторинг доступности»
• Чем отличается от браузерного пользователя: нет нормальной сессии, другие интервалы, повторяемый path-паттерн

Типичный кейс: маркетинг видит всплеск хитов в Метрике/GA, но сессии пустые. Причина — SiteUpTimeBot. Правильная реакция — не «выключить сайт», а точечно запретить UA/политику бота, предварительно убедившись, что мониторинг действительно не нужен.

Как выглядит типичное поведение легитимного uptime-монитора

Для сравнения: у известных сервисов этой категории паттерн обычно простой и лёгкий — короткие HEAD- или GET-запросы к одному и тому же URL с фиксированным интервалом (от 30 секунд до нескольких минут, реже раз в час), минимальный расход трафика, отсутствие интереса к глубоким разделам сайта. Если SiteUpTimeBot в ваших логах ведёт себя похоже — это дополнительное подтверждение, что перед вами именно мониторинг, а не замаскированный скрапер.

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

Отдельной строки в публичной сводке top-bot TrafficVeil у siteuptimebot может не быть, но в категории «Мониторинг доступности» такие агенты дают характерный фон: частые probe-запросы засоряют логи; чужой мониторинг может ходить чаще, чем нужно вашему SLA. Смотрите не только абсолютный RPS, но и качество хитов: глубина обхода, повторы одних и тех же URL, отсутствие cookie/сессий и концентрация на служебных или листовых страницах.

Как найти SiteUpTimeBot в логах

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

# Топ URL, которые вычитывает бот
grep -i "siteuptimebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

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

# Суточная активность
grep -i "siteuptimebot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация

Подделать User-Agent может любой скрипт. Для решения allow/deny смотрите связку: UA + ASN/IP + частоту + набор URL. Если оператор публикует диапазоны — сверяйте их; если нет, опирайтесь на поведение и политику TrafficVeil.

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

robots.txt для SiteUpTimeBot

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

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

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

Важно: Disallow/403 для siteuptimebot, если пользы нет. Если агент игнорирует robots.txt, переходите к nginx/Apache или запрету в TrafficVeil.

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

Nginx

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

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

Apache (.htaccess)

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

TrafficVeil

• Найдите siteuptimebot / SiteUpTimeBot в ботах домена или в /system/bots
• Для нежелательного сценария — категория «запретить»; для мягкого — rate-limit
• Allow только при явной пользе от SiteUpTimeBot
• После изменения сверьте логи: хиты SiteUpTimeBot должны уйти в блок/лимит, а нужные поисковики остаться

Рекомендации: что делать с SiteUpTimeBot

• Если это не ваш checker — смело ограничивайте
• Если ваш — внесите IP в allowlist TrafficVeil, не полагаясь только на UA
• Если нагрузка мешает — сначала rate-limit, затем полный запрет
• Не режьте слишком широко User-agent: *, чтобы случайно не закрыть Googlebot/YandexBot

С кем не путать SiteUpTimeBot

Стратегия allow/deny для SiteUpTimeBot