Superfeedr feed fetcher
Superfeedr is a feed-handling service that polls and processes RSS/Atom feeds and pushes updates to subscribers, historically supporting real-time feed delivery via PubSubHubbub/WebSub. It fetches your feed URLs to detect new items, not your pages for search ranking. Its activity appears in logs as repeated feed fetches from Superfeedr infrastructure.
What this means
Superfeedr handles feeds on behalf of applications and subscribers: it polls or receives feed updates, normalises them, and pushes new items downstream, often using WebSub/PubSubHubbub for real-time delivery. To do that it fetches your RSS/Atom feed URLs.
This is feed handling, not search indexing. Superfeedr is reading your feed to detect new entries, not crawling your pages to rank them.
How it identifies itself
Superfeedr fetches feeds from its own infrastructure, typically with a self-identifying client. Match on the documented identity where available rather than an exact version. The fetch pattern is repeated polling of feed URLs rather than broad page crawling.
Because exact tokens and ranges are not exhaustively published and may change, this entry is marked partially verified; the feed-polling behaviour and Superfeedr infrastructure are the reliable signals.
- Purpose: RSS/Atom feed handling and push delivery
- Often uses WebSub/PubSubHubbub for real-time updates
- Fetches feed URLs, not pages for ranking
How it appears in analytics and logs
A Superfeedr request is a feed poll or fetch to detect new items for subscribers. It is feed-handling automation hitting your feed URLs, not a content crawl or human audience.
Diagnostic use case
Recognise feed-fetching traffic from Superfeedr in logs, separate it from search crawling and page indexing, and read it as feed subscription activity.
What WebmasterID can help detect
WebmasterID classifies feed-fetching automation server-side as bot traffic and shows which feed URLs it polls, so feed delivery does not inflate human analytics.
Common mistakes
- Treating feed polling as search indexing.
- Counting feed fetches as human page views.
- Blocking feed fetchers and then wondering why subscribers stop getting updates.
Privacy and accuracy notes
Identification uses the request user-agent and feed context only. No visitor identity is involved. WebmasterID records the fetch as a bot event, separate from human analytics.
Related pages
- Feedbin feed reader fetcher
Feedbin is a hosted RSS/Atom feed reader that polls feeds on behalf of its subscribers so they can read new items. It fetches your feed URLs to detect updates, not your pages for search ranking. Its activity appears in logs as repeated feed fetches from Feedbin infrastructure, with a self-identifying client.
- Feedfetcher-Google — feed fetcher
Feedfetcher-Google is the user agent Google uses to fetch RSS and Atom feeds for Google products. Google documents that Feedfetcher is not used for indexing, and that because feed fetches are user-requested subscriptions, it is handled differently from indexing crawlers.
- Monitoring bots vs search crawlers
Monitoring bots (uptime and performance checkers such as Pingdom and UptimeRobot) fetch your pages on a schedule to confirm availability, not to index them. They differ from search crawlers, which build a search index, and from SEO crawlers, which gather competitive data. Telling them apart keeps synthetic checks out of human analytics.
- Website observability
See feed and monitoring fetches reaching your endpoints, server-side.
Sources and verification notes
- SuperfeedrFeed-handling / WebSub push service; exact fetcher tokens and ranges not exhaustively published.
- W3C — WebSubStandard for real-time feed delivery used by feed services.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.