Parse.ly в логах: аналитика издателей, а не ваш сервис

Токен parse.ly в access.log относится не к анонимному «сервисному обходу», а к краулеру давно известной компании: Parse.ly — сервис контент-аналитики, основанный в 2009 году и с некоторых пор входящий в состав Automattic (той же компании, что владеет WordPress.com). В каталоге TrafficVeil бот отмечен как легитимный в категории «Прочие краулеры и сервисы».

Что такое parse.ly на самом деле

Parse.ly — платформа контент-аналитики для издателей: она измеряет, как читатели взаимодействуют с материалами, какие темы и авторы работают лучше, откуда приходит трафик. Основная аудитория сервиса — новостные редакции и контентные издатели, а не e-commerce или, например, гемблинг-проекты, поэтому визит этого краулера на нетипичный для отрасли сайт стоит сначала проверить, а не сразу считать ожидаемой интеграцией.

Официальная документация Parse.ly раскрывает техническое поведение краулера: он не исполняет JavaScript и забирает только то, что уже присутствует в исходном HTML-коде страницы. Ещё одна особенность — краулер группирует разные представления одного и того же материала (например, обычную страницу и её AMP-версию, или несколько страниц одной фотогалереи) через так называемый Parse.ly canonical URL, чтобы аналитика не дробилась на части.

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

Если сайт действительно подключён к Parse.ly как клиент сервиса, краулер регулярно вычитывает страницы, чтобы обновлять данные о содержании и вовлечённости — это часть штатной работы аналитической системы. Активность обычно привязана к фиксированным интервалам, как задача по расписанию, и концентрируется на публичных URL, иногда затрагивая открытый API и статику.

Если же ваш сайт к Parse.ly не подключён — а для сети гемблинг-проектов это более вероятный сценарий, чем для новостного издания, — стоит в первую очередь выяснить, не осталась ли интеграция от прошлого подрядчика или редизайна, прежде чем считать этот трафик ожидаемым.

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

Отдельной строки в публичной сводке топ-ботов TrafficVeil у parse.ly может не быть, но в категории «Прочие краулеры и сервисы» такие агенты дают характерный фон: на отдельных доменах серии запросов выглядят как мини-волны автоматизации без единой конверсии. Смотрите не только на абсолютный RPS, но и на:

• регулярность интервалов — поведение, близкое к cron-задаче, типично именно для этого краулера;
• ограниченность набора URL — публичные страницы с содержательным материалом, а не весь каталог целиком;
• отсутствие cookie и признаков сессии.

Как найти parse.ly в логах

Ищите конкретный токен parse.ly, а не общее слово «bot».

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

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

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

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

Официальная строка UA известна и легко проверяется на соответствие — если заголовок в логах существенно от неё отличается, это повод присмотреться внимательнее. Тем не менее для окончательного решения смотрите связку UA + ASN/IP + частота + набор URL, а не один заголовок:

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

robots.txt для parse.ly

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

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

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

Важно: если сайт не является клиентом Parse.ly, полный запрет ничего не сломает — краулер просто перестанет вычитывать страницы, аналитика которых всё равно никому не нужна на вашей стороне.

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

Nginx

if ($http_user_agent ~* "parse.ly") {
    return 403;
}

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

Apache (.htaccess)

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

TrafficVeil

• найдите parse.ly в ботах домена или в /system/bots;
• если сайт не подключён к Parse.ly как клиент — категория «запретить»; если подключён, но нагрузка мешает — rate-limit;
• allow оставляйте только при подтверждённой активной подписке на сервис;
• после изменения сверьте логи: хиты parse.ly должны уйти в блок/лимит, а нужные поисковики остаться нетронутыми.

С кем не путать parse.ly

Стратегия allow/deny для parse.ly

Главный вывод по parse.ly: это открытый, легко проверяемый оператор с понятной технической документацией — но для сети сайтов, не связанных с контентной журналистикой, сам факт визита стоит сначала объяснить, а уже потом решать между allow и запретом.