Feedspot: что это за бот, зачем он читает RSS и нужно ли его блокировать

Feedspot — сервис для чтения, агрегации и распространения обновляемого контента. Его основной продукт Feedspot Reader позволяет подписываться на RSS-ленты блогов, новостных сайтов, подкастов и других источников и получать их обновления в едином интерфейсе.

Поэтому автоматические запросы Feedspot в access.log обычно относятся не к обычному просмотру сайта человеком, а к сервисному получению контента.

Однако считать Feedspot исключительно RSS-fetcher тоже было бы слишком узко. У сервиса есть RSS Builder, который способен получить обычный URL, проанализировать выбранный пользователем участок страницы и превратить его в автоматически обновляемый RSS-feed.

Поэтому Feedspot может обращаться как к:

/feed/
/rss/
/atom.xml
/blog/feed/

так и к обычным HTML-страницам.

Что делает Feedspot Reader

Feedspot Reader предназначен для объединения разных источников в одной ленте.

Пользователь может добавить интересующие его:

• блоги;
• новостные сайты;
• RSS feeds;
• подкасты;
• другие поддерживаемые источники.

После этого Feedspot показывает свежие публикации в своём интерфейсе, чтобы пользователю не приходилось вручную посещать каждый сайт.

Именно такой сценарий объясняет характерный машинный паттерн в access.log: один и тот же feed URL может автоматически проверяться через определённые промежутки времени.

Почему Feedspot регулярно приходит на сайт

RSS основан на обновляемом документе. Чтобы понять, появилась ли новая статья, агрегатору необходимо периодически получать feed и сравнивать его с предыдущим состоянием.

Условно это выглядит так:

Feedspot
↓
GET /feed/
↓
проверка новых элементов
↓
через некоторое время
↓
GET /feed/

Для RSS-reader повторные запросы являются нормальным поведением.

Поэтому большое количество одинаковых обращений к одному feed URL не обязательно означает scraping или DDoS.

Feedspot может получать не только RSS

Это важное уточнение для антибот-классификации.

Feedspot предлагает RSS Builder, который позволяет создать RSS-feed даже для сайта, где готовой ленты нет.

По официальному описанию пользователь:

1. указывает URL страницы;
2. Feedspot получает страницу;
3. пользователь выбирает участок с нужным контентом;
4. Feedspot преобразует его в структурированный feed;
5. feed затем автоматически обновляется.

Поэтому нормальный Feedspot-трафик может включать:

GET /blog/
GET /news/
GET /products/
GET /articles/

а не только:

GET /feed.xml

Почему это важно для TrafficVeil

Если классификатор считает нормальным Feedspot только при обращении к RSS-файлам, он может ошибочно помечать запросы RSS Builder как подозрительные.

Поэтому behavioral profile лучше строить шире:

Feedspot
→ RSS fetch
→ Feed monitoring
→ RSS Builder page fetch

Feedspot не является поисковым crawler

Feedspot не следует классифицировать рядом с Googlebot или YandexBot.

Главная задача сервиса — не построение универсального поискового индекса интернета, а получение контента для feed-reader и связанных функций.

Поэтому правильная категория:

RSS & Feed Fetchers

а не:

Search Crawlers.

Как выглядит нормальный Feedspot-трафик

Как найти Feedspot в access.log

Базовый поиск:

grep -i "feedspot" /var/log/nginx/access.log

Количество запросов:

grep -ic "feedspot" /var/log/nginx/access.log

Самые часто запрашиваемые URL:

grep -i "feedspot" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

Топ IP:

grep -i "feedspot" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

HTTP-коды:

grep -i "feedspot" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -rn

Как отдельно найти feed-запросы

grep -i "feedspot" /var/log/nginx/access.log \
| grep -iE '/feed|/rss|atom\.xml|rss\.xml|feed\.xml'

Так можно быстро определить, какая часть Feedspot-трафика действительно связана с классическими RSS/Atom endpoint.

Как определить HTML-fetch от Feedspot

Можно наоборот убрать типичные feed URL:

grep -i "feedspot" /var/log/nginx/access.log \
| grep -ivE '/feed|/rss|atom\.xml|rss\.xml|feed\.xml'

Это помогает найти обычные веб-страницы, которые Fetchspot получает, например, в рамках RSS Builder или другой функции.

Какие HTTP-коды особенно важны

Для feed fetcher полезно анализировать:

• 200 — feed или страница успешно получена;
• 301/302 — источник перенесён;
• 304 — контент не изменился;
• 403 — WAF или сервер запрещает доступ;
• 404 — feed больше не существует;
• 429 — сработал rate limit;
• 5xx — проблема origin.

Для RSS-сервиса большое количество корректных conditional/unchanged responses может означать эффективную работу обновлений, а не бесполезный трафик.

Можно ли доверять User-Agent feedspot

Нет.

Как и любой другой HTTP User-Agent, строка:

User-Agent: Feedspot

может быть подделана.

Поэтому TrafficVeil должен разделять:

Как проверять Feedspot

При отсутствии публичного официального IP-feed лучше использовать несколько сигналов:

• User-Agent;
• IP;
• ASN;
• ASN organization;
• network type;
• reverse DNS;
• TLS/HTTP fingerprint;
• запрашиваемые URL;
• периодичность;
• историю активности.

Как проверить ASN и reverse DNS

IP="1.2.3.4"

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

Эти данные следует рассматривать как дополнительные сигналы, а не как самостоятельное доказательство принадлежности Feedspot.

Как выглядит поддельный Feedspot

Представим:

User-Agent: Feedspot

GET /.env
GET /.git/config
GET /wp-login.php
GET /backup.zip
GET /vendor/phpunit/
GET /phpmyadmin/

Такое поведение не похоже на получение RSS или отслеживание публичной страницы.

TrafficVeil должен классифицировать источник по реальной активности:

Feedspot UA spoofing / suspicious automation.

Какие страницы не должны быть нормальной целью

Для обычного Feedspot-сценария подозрительно массовое обращение к:

• служебным конфигурациям;
• backup-файлам;
• закрытым административным URL;
• случайным vulnerability paths;
• тысячам несвязанных API endpoint.

Название легитимного сервиса не должно снижать security score такого поведения.

Соблюдает ли Feedspot robots.txt

В сторонних bot-каталогах Feedspot классифицируется как feed fetcher, но отдельной официальной crawler-policy Feedspot с опубликованным механизмом robots.txt compliance обнаружить не удалось.

Поэтому для TrafficVeil безопаснее:

robots.txt compliance: Unverified

robots.txt для Feedspot

Полный декларативный запрет:

User-agent: Feedspot
Disallow: /

Частичное ограничение:

User-agent: Feedspot
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /internal/
Allow: /feed/
Allow: /rss/

Такой вариант логичен, если владелец хочет оставить классическую RSS-синдикацию, но не разрешать получение других разделов.

Но robots.txt не является системой авторизации

Если URL действительно нельзя отдавать посторонним клиентам, он должен быть защищён:

• authentication;
• authorization;
• ACL;
• WAF;
• закрытым API;
• сетевыми правилами.

robots.txt лишь сообщает автоматизированному клиенту желаемые правила обхода.

Блокировка Feedspot через Nginx

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

Такое правило блокирует по заявленному UA, независимо от происхождения источника.

Блокировка через Apache

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

Стоит ли использовать Rate Limit

Для RSS-fetcher Rate Limit может быть полезнее полного Block, если Feedspot нужен, но слишком часто проверяет ресурс.

Но перед этим стоит посмотреть:

• сколько запросов приходится на один feed;
• как часто повторяется запрос;
• возвращается ли большой response body;
• работает ли caching;
• попадает ли запрос на origin;
• есть ли условные HTTP-запросы.

Как снизить нагрузку RSS без блокировки

Для feed traffic часто можно значительно снизить стоимость запросов без запрета агрегатора.

Полезно:

• кэшировать RSS/Atom;
• отдавать корректные ETag;
• использовать Last-Modified;
• поддерживать conditional requests;
• не генерировать feed тяжёлым SQL-запросом при каждом обращении;
• отдавать feed через CDN, если архитектура позволяет.

Для TrafficVeil это особенно интересный случай: иногда лучше оптимизировать cache, чем блокировать легитимный RSS-fetcher.

Почему Feedspot может создавать много hits, но мало нагрузки

Представим:

10 000 Feedspot requests
95% CDN cache HIT
5% origin

Такой бот может выглядеть крупным источником запросов, но практически не нагружать приложение.

И наоборот:

500 RSS requests
0% cache HIT
динамическая генерация XML + SQL

могут оказаться дороже.

Поэтому для категории RSS & Feeds особенно важны:

• Cache HIT Ratio;
• Origin Requests;
• Average Response Size;
• Bandwidth;
• Origin CPU impact.

Какую пользу Feedspot может приносить сайту

В отличие от многих технических crawler Feedspot способен приносить реальную контентную дистрибуцию.

Пользователь Feedspot может подписаться на источник и получать новые публикации через Reader. Сам сервис также поддерживает большую базу RSS-источников и тематические каталоги.

То есть автоматический запрос:

Feedspot → /feed/

может быть частью цепочки:

сайт
↓
Feedspot
↓
подписчик
↓
переход на публикацию

Что произойдёт после блокировки Feedspot

Для Google или Яндекса прямых последствий нет.

Но могут перестать нормально обновляться:

• подписки пользователей Feedspot;
• Feedspot Reader;
• связанные feeds;
• RSS Builder feed;
• другие функции Feedspot, которым нужен этот URL.

Поэтому Feedspot отличается от crawler, который не предоставляет владельцу сайта никакой потенциальной дистрибуции.

Повлияет ли блокировка на SEO

Feedspot не является Googlebot или YandexBot.

Поэтому точечное правило:

User-agent: Feedspot
Disallow: /

не является запретом для:

Googlebot
Googlebot-Image
YandexBot
Bingbot

Тем не менее возможна потеря дополнительного распространения контента через Feedspot.

Как учитывать Feedspot в аналитике

Запросы Feedspot не нужно считать обычными пользовательскими визитами.

Для TrafficVeil:

Automated Traffic
→ RSS & Feed Fetchers
→ Feedspot

Рекомендуется:

• исключать из Human Traffic;
• не считать конверсией;
• не относить к Malicious Bots при нормальном поведении;
• учитывать отдельно как RSS/service traffic;
• показывать feed requests отдельно от HTML fetch;
• анализировать cache efficiency.

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

Рекомендуемая карточка TrafficVeil

Стратегия Allow / Monitor / Rate Limit / Block

Что показывать пользователю TrafficVeil

Вместо общего:

«Легитимный бот. Решение зависит от бизнес-пользы.»

лучше написать:

Feedspot — RSS-reader и сервис синдикации контента. Он периодически получает RSS/Atom-ленты, а через RSS Builder может также проверять обычные веб-страницы. Блокировка может остановить обновление подписок Feedspot, поэтому при небольшой нагрузке рекомендуем Allow или Monitor.

Итог

Feedspot — легитимный сервис для чтения и агрегации контента, а не поисковый crawler. Его Reader позволяет пользователям подписываться на сайты и RSS-источники, поэтому автоматические периодические запросы к feed URL являются ожидаемым поведением.

Но Feedspot не ограничивается готовыми RSS-файлами. Его RSS Builder умеет получать обычную веб-страницу и превращать выбранный участок в автоматически обновляемый feed. Поэтому TrafficVeil не должен считать каждый запрос Feedspot к HTML аномалией.

Базовая политика — Allow / Monitor. Если polling создаёт нагрузку, сначала стоит проверить cache, ETag, Last-Modified и нагрузку на origin, а уже затем переходить к Rate Limit.

При этом конкретный запрос не следует считать подтверждённым только из-за User-Agent feedspot. При необычном поведении TrafficVeil должен учитывать IP, ASN, fingerprint и реальные URL, чтобы отличить легитимный RSS-fetcher от spoofing или другого автоматизированного клиента.