Если в аналитике внезапно растёт число хитов, а сессии остаются пустыми — это может быть не баг счётчика, а NewsRoom.BI: краулер, который приходит не за пользователями, а за данными о самом сайте. В отличие от многих агентов из категории «прочие краулеры и сервисы», у него есть конкретный оператор и понятная бизнес-логика — просто она работает не в интересах владельца посещаемого сайта. Ниже — кто и зачем его запускает, как отличить его в логах и как настроить доступ через robots.txt, сервер или TrafficVeil.
Что такое NewsRoom.BI и кто им управляет
NewsRoom.BI — краулер для сбора конкурентной и маркетинговой аналитики, которым управляет компания Marfeel. Его задача — собирать данные с публичных страниц по заказу клиента, которому нужна видимость рынка или конкретного набора конкурентов: чаще всего это цены, карточки товаров и рекламные креативы. Формально это делает его «сервисом для чужого бизнеса», а не краулером с пользой для сайта, который он обходит — отсюда и метка «нежелательный» в базе TrafficVeil, хотя сам по себе бот не вредоносный и не пытается скрыть, что он бот.
Зачем NewsRoom.BI приходит на конкретный сайт
Типичный сценарий: кто-то — конкурент, агентство или аналитическая служба самого сайта — настроил в Marfeel задачу на мониторинг определённого набора страниц, и краулер выполняет её по расписанию заказчика. Обход концентрируется на страницах, представляющих коммерческий интерес: прайсинг, карточки товаров/услуг, рекламные баннеры и промо-блоки — а не на всём сайте подряд равномерно. Блокировка бота не ломает ничего для реальных посетителей — она просто закрывает конкретному заказчику видимость в это окно мониторинга.
Технический профиль бота
| Параметр | Значение |
| Оператор | Marfeel |
| Назначение | Сбор конкурентной/маркетинговой аналитики по заказу клиента |
| Рендеринг JavaScript | Нет |
| Верификация по IP | Официального диапазона нет — только User-Agent |
| Частота обхода | Высокая при активной задаче мониторинга, по требованию заказчика |
| Соблюдение robots.txt | Да, по имеющимся наблюдениям |
| Соблюдение Crawl-delay | Не всегда одинаково |
| Влияние на SEO при блокировке | Отсутствует — это не поисковый краулер |
Нагрузка и на что реально смотреть
Поскольку бот не рендерит JavaScript и не заходит равномерно по всему сайту, а концентрируется на конкретных URL, характерная картина в логах — это не широкий равномерный фон, а «мини-волны» обращений к одному и тому же узкому набору страниц без роста сессий или конверсий. Стоит смотреть не только на абсолютный RPS, но и на глубину и повторяемость обхода: если одни и те же карточки товаров или страница с ценами вычитываются заметно чаще остального сайта — это характерный след именно такого типа бота, а не общего сканирования.
Как найти NewsRoom.BI в логах
# Базовый поиск
grep -i "newsroom.bi" /var/log/nginx/access.log
# Топ URL, которые вычитывает бот
grep -i "newsroom.bi" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "newsroom.bi" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Суточная активность
grep -i "newsroom.bi" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
Стоит учитывать, что в реальных логах строка может встречаться в разных написаниях — с точкой, дефисом, подчёркиванием или пробелом между «NewsRoom» и «BI» — поэтому для точного поиска удобнее регулярное выражение вида newsroom[-_. ]?bi, а не только буквальная подстрока.
Верификация: User-Agent — не доказательство
Официального списка IP Marfeel для этого краулера не публикует, поэтому верификация строится только на строке User-Agent — а её, как и у любого бота, легко подделать. Для повышения уверенности стоит смотреть на связку признаков: совпадение UA, разумную частоту, характерный набор URL (цены, карточки, промо) и поведение, не совместимое с обычным пользователем — отсутствие cookie и сессии, механическую регулярность интервалов.
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"
robots.txt для NewsRoom.BI
По имеющимся наблюдениям, этот краулер относится к добросовестным в части robots.txt — то есть директива действительно способна ограничить его обход, в отличие от многих непрозрачных ботов, которые её попросту игнорируют.
# Жёсткий запрет
User-agent: NewsRoom.BI
Disallow: /
# Разрешить всё
User-agent: NewsRoom.BI
Allow: /
# Компромисс: закрыть чувствительные разделы, оставить публичный контент
User-agent: NewsRoom.BI
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /
Если бизнес-цель — не дать конкурентам мониторить именно цены, стоит закрывать не сайт целиком, а конкретно раздел с прайсингом и карточками товаров: это точнее соответствует тому, за чем на самом деле приходит бот.
Управление на уровне сервера
Nginx:
if ($http_user_agent ~* "newsroom.bi") {
return 403;
}
limit_req_zone $binary_remote_addr zone=newsroombi:10m rate=10r/m;
location / {
if ($http_user_agent ~* "newsroom.bi") {
limit_req zone=newsroombi burst=20 nodelay;
}
}
Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} newsroom.bi [NC]
RewriteRule ^ - [F,L]
Серверные правила стоит держать про запас даже при рабочем robots.txt — на случай, если конкретный запуск задачи в Marfeel или её клиент решит проигнорировать директиву, либо если под этим же UA придёт спуфинг-трафик с других IP.
Управление через TrafficVeil
- Найдите
newsroom.bi/NewsRoom.BIв списке ботов домена или в разделе/system/bots. - Для сценария «не хотим быть видны конкурентам» — категория «запретить»; для сценария «видимость не критична, но раздражает частота» — rate-limit.
- Allow имеет смысл только если мониторинг заказан самой компанией (например, собственная маркетинговая команда использует Marfeel для анализа своих же страниц).
- После изменения сверьте логи: хиты NewsRoom.BI должны уйти в блок или лимит, а поисковые боты — остаться доступными.
Практические рекомендации
- Блокировка NewsRoom.BI не влияет на позиции в Google или Яндексе — это не поисковый краулер, а инструмент конкурентной разведки;
- Решение allow/deny здесь — не техническая, а бизнес-стратегия: часть компаний сознательно не против быть на виду у конкурентов, часть предпочитает закрыться;
- Если объём обращений умеренный и не создаёт нагрузки, а вопрос именно в видимости цен — точечный Disallow на разделы с прайсингом часто разумнее полной блокировки сайта для этого UA;
- При росте частоты выше комфортного уровня — сначала rate-limit, и только при повторных нарушениях переходить к полному запрету;
- Не расширяйте правило на весь User-agent: *, чтобы случайно не закрыть Googlebot или YandexBot заодно с NewsRoom.BI.
Похожие боты и сервисы для сравнения
| Бот | Кластер | User-Agent | Метка |
| 360Spider | Прочие краулеры и сервисы | 360spider | нежелательный |
| A360-Search | Прочие краулеры и сервисы | a360-search | нежелательный |
| AASA-Bot | Прочие краулеры и сервисы | aasa-bot | нежелательный |
| ABEvalBot | Прочие краулеры и сервисы | abevalbot | нежелательный |
| ActiveComply | Прочие краулеры и сервисы | activecomply | нежелательный |
Итоговая стратегия
| Ситуация | Действие |
| Мониторинг заказан самой компанией через Marfeel | Allow, при желании — закрыть только /admin, /cart, /api |
| Нежелательно быть видимым для конкурентов, но нагрузка не критична | Disallow на разделы с ценами/каталогом через robots.txt |
| Объём обращений мешает работе сервера | Rate-limit на nginx или в TrafficVeil |
| Нужен полный и гарантированный запрет независимо от соблюдения robots.txt | Deny в /system/bots + серверное правило |
| Подозрение на подделку UA (аномальные IP/паттерны) | Не полагаться на строку UA — проверять IP/ASN и поведение |