Jetpack в логах сайта: свой плагин или чужой бот

В логах сайт может выглядеть «живым», хотя рост даёт не аудитория, а Jetpack с User-Agent, содержащим jetpack. Это не сторонний краулер, а служебный трафик плагина Jetpack от Automattic (компании, стоящей за WordPress.com) — если сайт работает на WordPress и подключён к Jetpack, такие запросы обеспечивают бэкапы, сканирование безопасности, статистику и восстановление сайта. По метке TrafficVeil бот легитимный: решение allow/deny стоит принимать по тому, действительно ли сайт использует Jetpack, а не «на всякий случай».

1. Что такое Jetpack

Jetpack — это плагин безопасности, производительности и статистики для WordPress, который разрабатывает и поддерживает Automattic. Его серверная часть регулярно обращается к сайтам, где он установлен и подключён к аккаунту WordPress.com: снимает бэкапы, запускает сканирование на уязвимости, собирает метрики посещаемости и, при необходимости, восстанавливает сайт из копии. Связь между сайтом и облаком Jetpack идёт в том числе через файл xmlrpc.php, встроенный в ядро WordPress с версии 3.5.

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

Если сайт реально работает на WordPress с установленным и подключённым Jetpack, то трафик с этим UA — это ваш собственный плагин, общающийся с облаком Automattic ради функций, которые вы сами включили. Если же сайт не на WordPress или Jetpack на нём не установлен, легитимного повода для такого трафика в принципе нет — и тогда UA jetpack в логах либо ошибочно классифицирован, либо принадлежит стороннему скрипту, подделывающему строку.

• Какие зоны чаще трогает: xmlrpc.php, служебные REST-эндпоинты WordPress (/wp-json/), реже — публичные страницы при сборе метрик;
• Что ищет: подтверждение доступности сайта, данные для бэкапа/скана, статистику посещаемости — в рамках функций, которые администратор сайта включил в настройках Jetpack;
• Чем отличается от браузерного пользователя: нет обычной сессии, обращения идут по расписанию сервисных задач (бэкап, скан), а не по интересу к контенту.

Типичный кейс: в панели видно рост hits от UA с jetpack, но это не «лишний» бот, а часть работы вашего же плагина — если сайт на WordPress, для начала стоит свериться с настройками Jetpack, прежде чем блокировать этот трафик.

3. Нагрузка и риски именно для Jetpack

Для сайта, где Jetpack реально используется, этот трафик не «фоновый шум», а ожидаемая служебная нагрузка: если заблокировать его вслепую, сломаются бэкапы, сканирование безопасности и восстановление — то есть как раз то, ради чего плагин обычно и ставят. Здесь риск обратный привычному для других агентов: не «лишняя нагрузка от чужого бота», а «случайно отключить собственную защиту сайта».

Если же сайт точно не на WordPress или Jetpack на нём не подключён, риск смещается в обычную плоскость: искажение статистики «живого» трафика и расход ресурсов от запросов с подделанным UA, которые не несут никакой функциональной пользы.

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

Не ищите «просто ботов» — ищите конкретный токен jetpack и сразу проверяйте, действительно ли сайт использует WordPress+Jetpack.

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

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

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

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

# Проверить долю обращений именно к xmlrpc.php и /wp-json/
grep -i "jetpack" /var/log/nginx/access.log | grep -E "xmlrpc\.php|/wp-json/" | wc -l

Верификация. В отличие от большинства ботов из этой энциклопедии, у Jetpack есть официальный и обновляемый список IP — сверяйте его с актуальной машиночитаемой версией на сайте поддержки, а не полагайтесь только на строку UA.

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

5. robots.txt для Jetpack

Правила robots.txt здесь работают слабо: Jetpack — это не поисковый краулер, который читает и уважает файл правил, а служебный клиент вашего собственного плагина. Управлять его доступом эффективнее через настройки самого Jetpack (отключить нужные модули) или через firewall/IP-фильтр, а не через robots.txt.

# Вариант на случай стороннего скрипта с поддельным UA, а не реального Jetpack
User-agent: jetpack
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Важно: если сайт реально использует Jetpack, полный Disallow ломает функциональность плагина, а не просто «экономит» нагрузку.

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

Nginx (только если Jetpack на сайте не используется)

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

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

Apache (.htaccess)

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

TrafficVeil

• Прежде чем блокировать, проверьте в CMS сайта, установлен ли плагин Jetpack и подключён ли он к аккаунту WordPress.com;
• Если сайт не на WordPress или Jetpack точно не используется — можно смело выбирать «запретить» в /system/bots;
• Если сайт на WordPress и Jetpack нужен — Allow, а для лишних пиков используйте rate-limit, а не полный запрет;
• После изменения сверьте логи и, отдельно, работоспособность бэкапов/сканов в самом Jetpack — убедитесь, что блокировка не задела нужные функции.

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

• Сайт на WordPress с активным Jetpack — Allow, IP из официального списка Automattic можно занести в allowlist firewall;
• Сайт не на WordPress или Jetpack точно отключён — Disallow/403, легитимного трафика с этим UA у вас быть не должно;
• Нагрузка от реального Jetpack мешает, но функции нужны — используйте rate-limit точечно, полный запрет тут рискованнее, чем для сторонних ботов;
• Не режьте слишком широко правилом User-agent: *, чтобы случайно не закрыть Googlebot или YandexBot;
• Что вы теряете при неверной блокировке: если сайт реально использует Jetpack — бэкапы, сканирование безопасности, статистику и возможность восстановления сайта из копии.

8. С кем не путать Jetpack

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