BlogVault — ещё один случай, похожий на MainWP: если этот UA появляется в логах, чаще всего это означает не постороннего бота, а вашу же (или клиента) систему резервного копирования WordPress. BlogVault — реальный, хорошо известный сервис backup/staging/миграции для WordPress с более чем миллионом заявленных резервных копий сайтов, а не безымянный «прочий сервис».
1. Что такое BlogVault на самом деле
BlogVault — платный SaaS-сервис для WordPress: автоматическое резервное копирование (инкрементальное, включая базу данных, темы, плагины, медиафайлы), staging-окружения для тестирования изменений, миграция сайтов между хостингами и базовая security-функциональность (сканирование малвари, файрвол, аудиты уязвимостей). Владелец сайта или его агентство подключает конкретный WordPress-сайт к своему аккаунту BlogVault — именно после этого на сайте появляется трафик от бота.
Важный технический момент, о котором сообщает сама компания: обработка резервного копирования и staging выполняется на серверах BlogVault, а не на ресурсах сайта — то есть сервис специально спроектирован так, чтобы не создавать заметной нагрузки на origin, а не наоборот.
| Параметр | Значение |
| Название | BlogVault |
| Оператор | BlogVault — официально задокументированный сервис резервного копирования и безопасности WordPress, blogvault.net |
| Роль | Резервное копирование, staging-окружения, миграция и security-сканирование конкретного WordPress-сайта, к которому владелец подключил сервис |
| User-Agent / паттерн | BlogVault/1.0 (+https://blogvault.net) |
| Кто обычно инициирует | Сам владелец сайта или его агентство — сервис платный и требует сознательного подключения конкретного сайта к аккаунту |
| Верификация | Официально задокументирована: комбинация User-Agent и обратного DNS (rDNS); IP-адреса динамические, отдельного статичного списка нет |
| robots.txt | Технически можно настроить Disallow, но это напрямую сломает функциональность вашей же (или клиентской) системы бэкапа |
| Категория (Cloudflare Radar) | Monitoring & Operations |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем BlogVault приходит на сайт
- плановое резервное копирование — по расписанию, которое настроил владелец аккаунта (ежедневно/еженедельно/ежемесячно, до 90 дней истории по умолчанию, до 365 дней в расширенных планах);
- создание или обновление staging-окружения для безопасного тестирования изменений перед публикацией на боевом сайте;
- миграция сайта между хостингами — единоразовый, но объёмный процесс переноса;
- malware-сканирование и аудит уязвимостей — часть заявленной security-функциональности сервиса.
Типичный кейс: в логах регулярно появляется BlogVault с определённой периодичностью, соответствующей расписанию бэкапов — это ожидаемое, штатное поведение подключённого сервиса, а не аномалия.
3. Нагрузка и риски
Прямого риска для контента (republishing, скрытый сбор данных для третьих лиц) практически нет — это узкоспециализированный сервис резервного копирования с понятной, официально заявленной целью. Сама компания подчёркивает, что архитектура спроектирована так, чтобы минимизировать нагрузку на сайт во время бэкапа/staging.
Главный практический риск здесь другой: если сайт был передан от одного подрядчика другому, а старое подключение BlogVault осталось активным, владелец может не осознавать, откуда идёт этот трафик — и по ошибке заблокировать собственную (или прежнюю) систему бэкапа, решив, что это посторонний бот.
4. Как найти BlogVault в логах
# Базовый поиск
grep -i "blogvault" /var/log/nginx/access.log
# Топ URL, которые запрашивает сервис
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA — помните, что диапазон динамический
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Регулярность — должна соответствовать расписанию бэкапов, если сервис подключён осознанно
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
# Проверка: установлен ли на сайте активный плагин BlogVault
wp plugin list --status=active | grep -i blogvaultВерификация. BlogVault официально рекомендует связку User-Agent + обратный DNS (rDNS) для подтверждения подлинности запроса — IP-адреса динамические, отдельного фиксированного списка компания не публикует:
IP="1.2.3.4"
dig +short -x "$IP"Первый и самый быстрый шаг диагностики здесь — не техническая проверка IP, а простой вопрос: подключён ли сайт к чьему-либо аккаунту BlogVault сознательно, и если да — к чьему именно.
5. robots.txt для BlogVault
# Жёсткий запрет — сломает функциональность бэкапа, если сервис используется
User-agent: BlogVault
Disallow: /
# Разрешить всё — необходимо, если сайт реально использует BlogVault для бэкапов
User-agent: BlogVault
Allow: /Обратите внимание: пример правила из независимых каталогов ботов (полный Disallow: / для BlogVault) — это ровно та конфигурация, которая незаметно сломает резервное копирование, если её применить бездумно на сайте, где сервис реально используется.
6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "blogvault") {
return 403;
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} blogvault [NC]
RewriteRule ^ - [F,L]TrafficVeil:
- прежде чем блокировать — проверьте, не используется ли BlogVault сознательно для бэкапов, staging или миграции конкретно этого сайта;
- если сервис используется — allow, дополнительно ограничивать не требуется, нагрузка и так минимальна по архитектуре самого сервиса;
- если сайт сменил подрядчика и подключение осталось от прежнего — правильное решение не блокировать техническими средствами, а отвязать сайт от старого аккаунта BlogVault, иначе бэкапы могут продолжать уходить бывшему подрядчику;
- после изменения сверьте логи и, если применимо, убедитесь, что собственные бэкапы продолжают создаваться штатно.
7. Что делать: короткий алгоритм
- Первый шаг всегда один: выяснить, подключён ли сайт к чьему-либо аккаунту BlogVault сознательно;
- Подключён и используется — allow, это ваша (или клиентская) инфраструктура резервного копирования;
- Подключение осталось от прежнего подрядчика — отвязать аккаунт через саму BlogVault, а не просто заблокировать трафик технически;
- Сайт точно не использует BlogVault и подключения никогда не было — Disallow + запрет в TrafficVeil обоснован;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать BlogVault
| Бот / сосед | Кластер | Комментарий |
| MainWP | Прочие краулеры и сервисы | Та же модель «сначала спросите, подключено ли сознательно» — только для управления сайтом, а не для бэкапов |
| UpdraftPlus | Прочие краулеры и сервисы | Прямой конкурент BlogVault — другой популярный WordPress-сервис резервного копирования с той же логикой подключения |
| Silktide | Прочие краулеры и сервисы | Аналогичная логика «настроено кем-то из вашей организации», но для аудита доступности, а не бэкапов |
| 2ip Bot | Прочие краулеры и сервисы | легитимный, но принципиально другая модель — сторонний сервис без привязки к владельцу конкретного сайта |
9. Стратегия allow/deny для BlogVault
| Ситуация | Действие |
| Сайт сознательно подключён к BlogVault для бэкапов | Allow — это собственная (или клиентская) инфраструктура резервного копирования |
| Подключение осталось от прежнего подрядчика | Отвязать аккаунт через саму BlogVault, а не блокировать технически |
| Сайт точно не использует сервис | Disallow + запрет в TrafficVeil |
| Неясно, чьё это подключение | Проверить настройки плагина/аккаунта, прежде чем принимать решение |
| Подозрение на подделку UA | Проверять через официально рекомендованную связку UA + обратный DNS, а не по одной строке заголовка |