Publish a post through a normal CMS and you get a dashboard the same day: pageviews, unique visitors, time on page, a referrer breakdown. Publish the exact same content as an RSS feed and you get one thing — a line in a server log saying a URL was requested. No session opened. No cookie set. Nothing calls home to say what happened after the file left your server.
That is not a missing feature waiting for someone to build it — it is the architecture behaving as designed, the same pull-model architecture our guide to what RSS actually is walks through at the file level. It explains something people get backwards about RSS usage: the format did not fade from mainstream publishing because it lost a popularity contest. It faded because a channel nobody can measure is a channel nobody can defend in a budget meeting, a business fact, not a technical one. What follows: what a feed’s server log can prove about that usage, what it can’t, why the one available signal is unreliable by design, and how a sibling protocol — podcasting — solved the identical problem without ever solving the underlying blindness.
A Fetch Is Not a Reader
A feed is a file at a URL. Reading it in a desktop client involves no request to the publisher at all — the content already arrived as XML, and the app just renders what it has. What does reach the publisher is a machine’s request to refresh that file, carrying no concept of “reader”: no login, no session token, no callback firing when a human’s eyes land on an item. The RSS 2.0 specification — published by Harvard’s Berkman Klein Center (version 2.0.1, 15 July 2003) and maintained since by the RSS Advisory Board (version 2.0.11, 30 March 2009) — defines exactly zero elements for reporting readership back to a publisher. The only elements that touch the subject point the other way: ttl tells an aggregator how long it may cache a feed before refetching, skipHours/skipDays tell it when not to bother, and cloud lets a client register to be notified of updates. Every one of those is an instruction from publisher to client. None of them is a signal from client to publisher.
Moving to push instead of polling doesn’t fix this — it removes the last ambient signal you had. WebSub, the W3C Recommendation (first published 23 January 2018 and revised 2 June 2026) that formalized the old PubSubHubbub push model, puts a hub between publisher and subscriber so updates arrive instantly instead of being polled for. Its own text states the tradeoff without hedging: “the publisher is unaware of the subscribers, if any.” A pull-based feed at least generates a request every time a client checks in; a well-run push setup generates fewer requests, not more visibility.
What Your Server Log Can Actually Tell You
A log is still useful — just not for what most people want from it. What lands in an access log is a fixed field set: IP address, timestamp, status code, bytes served, occasionally a referrer, and a User-Agent string. Every one describes the request, not the person behind it, and that gap is where most naive feed-analytics attempts fail.
The first problem is fan-out. Hosted readers don’t fetch a feed once per subscriber — they fetch it once, on a schedule, and serve the cached result to everyone behind it. Feedly’s own fetcher documentation says its crawler “shouldn’t retrieve feeds from most sites more than once every hour on average,” dropping to about once a day once a feed advertises a WebSub push hub; BazQux documents the identical pattern. That means a log might show a couple dozen requests a day from a hosted reader’s crawler, standing in for a subscriber base that could be six orders of magnitude larger — and the better a feed’s push setup is, the fewer requests represent the same number of people.
Occasionally that gap becomes visible instead of theoretical. Queried on 2026-08-16, Feedly’s public search API returned a subscribers count of 1,448,937 for The Verge’s feed. Read correctly, that’s the sharpest illustration available of how far a feed’s real reach can diverge from an access log. Read incorrectly — as “RSS readership,” as a percentage of anything, as comparable across services — it stops meaning anything. It counts Feedly accounts holding one URL, on one service, on one date. It says nothing about NetNewsWire, Inoreader, a self-hosted Miniflux instance, or any client that never phones home at all.
The Best-Behaved Clients Leave the Faintest Trace
There’s a second distortion, running the opposite direction from fan-out: it rewards bad manners. RFC 9110, the current HTTP Semantics standard (June 2022), formalizes conditional requests — ETag, Last-Modified, If-None-Match, If-Modified-Since — and the 304 Not Modified response they enable. A well-behaved client checks in hourly, gets a cheap 304 twenty-three times and one real 200, and downloads the content once a day. A poorly-written client ignores all that and re-downloads the full file on every poll — and counted naively, that rude client looks many times more “active,” though its actual readership hasn’t changed at all.
RFC 5005, Feed Paging and Archiving (September 2007), adds a related wrinkle: most feeds expose only a rolling window of recent items. A subscriber offline for a week silently misses whatever scrolled off the end, and the log has no way to show that, because nothing was ever requested. Counted volume and delivered volume are not the same number, and the log doesn’t say by how much they diverge.
The One Weak Signal, and Why It’s Weak
If there’s a genuine signal buried in a feed’s traffic, it’s the User-Agent string. Feed and podcast clients overwhelmingly self-identify, and the Open Podcast Analytics Working Group maintains an open catalogue of them — podcast-rss-useragents, 519 entries covering bots, apps, libraries, browsers, and devices. Ten of those entries carry a reportssubs flag, meaning the client embeds its own subscriber count in the request header: BazQux Reader, Fathom, Feed Wrangler, Feedbin, Feedly, Inoreader, NewsBlur, Newsify, Overcast, and Player FM — a real, grep-able floor on your audience, sitting in log lines almost nobody reads.
It’s still weak for three reasons. Most readers, including large ones, don’t report a count at all, so the ten that do are a slice, not the whole picture. User-Agent strings are trivially spoofable and frequently generic. And robots.txt, the usual filter for “legitimate crawler” versus everything else, doesn’t apply here by design — Feedly and Google’s Feedfetcher both document ignoring it, reasoning that a feed fetcher “behaves as a direct agent of the human user, not as a robot.” Bots, preview generators, and link-unfurlers hit feed URLs constantly and are structurally indistinguishable, at the log level, from a genuine reader checking in.
Podcasting Solved This Without Solving It
Podcasting runs on the same protocol — an RSS feed with an <enclosure> element pointing at an audio file — and hits the identical wall: no client tells a server that a file was actually played. The difference is that podcasting had real advertising money riding on the answer, so the industry didn’t wait for a technical fix. It negotiated a definition instead, through the IAB Tech Lab’s Podcast Measurement Technical Guidelines, now on version 2.2 (May 2024, following v2.1 in 2021, v2.0 in 2017, v1.0 in 2016). The guidelines say the quiet part out loud: “Most players that initiate a podcast download (client) send no information about playback… ad play is calculated based on server logs.”
What v2.2 specifies is a set of rules for turning ambiguous traffic into an auditable number, not a way of seeing playback. A download counts if enough bytes were served — roughly a minute of audio, a threshold each publisher calculates per episode — inside a 24-hour window; a 304 doesn’t count, since it means the client already had the file. Uniqueness comes from IP-plus-User-Agent pairs, an estimator the guidelines admit cuts both ways: IP-hopping inflates counts, recycled IPs deflate them, “at the same time.” The standard’s own definition stays careful about what it isn’t: a Download is “a unique file request that was downloaded… and potentially listened to, at least in part” — not a confirmed listen. Apple’s own platform behavior sharpens the point: Apple Podcasts pauses automatic downloads for a show once a listener hasn’t played its last five episodes in fifteen days. Nobody unsubscribed; the number simply stopped being generated, because the software manufacturing “download” events decided to stop. Podcasting didn’t solve the blindness — it agreed on a shared, imperfect, disclosed method for guessing, and an ad market was willing to transact against the guess.
I went looking for a broader picture of feed volume from Podcast Index, which aggregates podcast feed metadata across the open ecosystem. Its public statistics endpoint returned an HTTP 403 both when a researcher checked it on 2026-08-16 and again when I checked it directly while writing this piece, so no figures from Podcast Index appear here. That’s a small demonstration of the argument, not an aside: even the tool built to look at RSS from the outside isn’t visible from the outside right now.
What You Can Honestly Measure About Your Own Feed
None of this means your own numbers are worthless — they’re a floor, not a total, and treating them as anything else is where feed analytics goes wrong. Worth actually doing:
- Log the full field set — IP, timestamp, status code, bytes served, referrer when present, User-Agent — you cannot reconstruct it after the fact.
- Classify User-Agents against the OPAWG open lists and keep an explicit “unclassified” bucket, since its growth is often the first sign your traffic composition shifted, before any total does.
- Harvest the ten readers that self-report subscriber counts, and query a hosted reader’s public API for your own feed on a schedule — storing the date beside every number, since an undated count is close to meaningless a year later.
- Track
200-to-304ratio as hygiene, not traffic. A falling304share usually means clients got worse-behaved, not that readership grew. - Tag outbound links with campaign parameters and report the results as clicks, never as reads — it’s the one feed event that behaves like an ordinary, measurable web request.
- Watch trends, not levels. Every number here is a biased estimate of something else, but the bias tends to hold steady week over week, so a trend is trustworthy long before any single count is.
None of this adds up to a defensible answer about RSS usage — “how many people actually read via a feed.” That question isn’t unanswered because nobody built the right dashboard yet — it’s unanswered because the protocol was never given a channel for the answer to travel back on, and every attempt to bolt one on (a tracking pixel in an item body, a per-subscriber feed URL) buys its precision by reintroducing the exact identifier the format’s blindness was quietly protecting, a tradeoff a companion piece in this series takes on directly. The honest position worth actually holding: you can measure your own feed’s fetches, in useful and specific ways. You cannot measure the format’s popularity, and neither can anyone telling you a percentage.
Frequently Asked Questions
Does RSS have any built-in way to report readership? No. Neither the RSS 2.0 specification nor its maintained successor defines any element for a client to report back that content was read. The only readership-adjacent elements — ttl, skipHours, skipDays, cloud — carry instructions from publisher to client, not the reverse.
Can I find out how many people subscribe to my own feed? Partially. Ten catalogued readers embed a subscriber count in their User-Agent string, at least one hosted reader exposes a subscriber count for any feed through a public API, and click-throughs tagged with campaign parameters are fully measurable. None of that totals to a real number; each is a floor on one slice of your audience.
Why does one crawler visit represent so many more readers than it looks like? Hosted readers fetch a shared feed once on a schedule and fan the result out to every subscriber behind it, server-side. The log shows the fetch, not the fan-out — Feedly and BazQux both document polling roughly hourly, less often once a feed supports push via WebSub.
Is a podcast “download” the same thing as a listen? No. The IAB Tech Lab’s guidelines define a download as a file request meeting a byte-volume threshold within a time window — evidence data moved, not confirmation a person pressed play or heard any of it. Apple’s own listening analytics are a separate, later, app-side number for exactly this reason.
If tracking would solve the visibility problem, why don’t more feeds just add it? Because every mechanism that makes a feed genuinely measurable — a pixel in each item, a unique URL per subscriber — works by re-identifying the reader across every fetch. That converts a format chosen partly because it avoids per-person tracking into the kind of surveillance its readers opted out of by using it. It’s a real tradeoff, worth making on purpose rather than by a plugin’s default.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
RSS and Atom in Action
Harold, Powers · Manning
Before you build any kind of feed measurement on top of the protocol, it helps to know exactly what’s in a feed and what isn’t. This is the strongest of the RSS/Atom-era format books for that — it walks the actual elements (ttl, cloud, enclosure, and the rest) that this article leans on to show what a feed can and can’t report back. It’s a 2003-vintage title, which is itself part of the point: no newer RSS-specific book exists, because the format finished changing while it kept working. Read the free spec first — Harvard’s RSS 2.0 reference and the RSS Advisory Board’s maintained edition cost nothing and are both short — and treat this as the deeper-dive supplement.
The Age of Surveillance Capitalism
Shoshana Zuboff
This article’s closing point — that adding tracking to a feed buys measurement precision by reintroducing the exact identifier the format’s blindness was quietly protecting — is a small, concrete instance of the argument Zuboff makes at book length: that “free” measurement is never actually free, and the missing piece is usually a person’s behavior turned into a data asset. If that trade interests you beyond RSS, we’ve also published a summary of the book itself.
Free and directly relevant: the IAB Tech Lab’s Podcast Measurement Technical Guidelines (the actual v2.2 rules this article summarizes) and the Open Podcast Analytics Working Group’s user-agent catalogues are both free, current, and more precise than anything a paperback could be.