Web Feeds in 2026: A Survey
9 points by EvanHahn
9 points by EvanHahn
CMS software should not silently create and advertise feeds that publishers never see or maintain; feeds should be visible, testable, and consciously enabled
I can empathize with the point, but many interesting sites only have feeds because CMSs auto‑generate them. I see many technical blogs, especially those that write HTML by hand or use static site generators, don't have a feed. And if many technical people aren't aware that web feeds exist or don't care enough to support them, how do you expect others to do better?
Doesn't look like JSONfeed has gotten any traction based on these numbers.
These are raw access counts for the feeds for my blog from last month:
A bit of traction for JSON, but not much.
I think the major adoption of JSONfeed is on WordPress (https://wordpress.org/plugins/jsonfeed/ shows 1,000+ active installs), but I suspect those are hosted along-side the RSS feed. There's a chicken and egg problem for adoption as just using RSS or Atom would continue working. I've been ignoring it.
WHATWG should deprecate the feed link relation; the cowpath is well and truly paved.
The link in question is from 2006. It was removed from the spec in 2009. Now, there’s just https://html.spec.whatwg.org/multipage/links.html#rel-alternate:rel-alternate-4.
I have no idea why mnot remembered about rel=feed, yet didn’t remember or look and see that it’s long, long gone.
It is still mentioned in https://microformats.org/wiki/existing-rel-values (which is the registry HTML refers to), but as POSH (Plain Old Semantic HTML) usage, meaning unspecified and potentially inconsistently used. https://microformats.org/wiki/rel-feed and https://indieweb.org/rel-feed speak of it in the past tense and with a somewhat different meaning, to do with h-feed. I wonder how many of those mnot found were actually that.
if autodiscovery is more deliberate and in a central place on the site, it has a better chance of leading to working, useful feeds.
I don’t get the logic behind this.
Concerning his proposed .well-known feed autodiscovery mechanism: can’t we just use OPML, or a freshly-defined profile of it (its spec is pretty underdone; it’s visibly from the RSS side of organic-in-the-worst-way-imaginable rather the Atom side of careful design). It’s already the standard interchange method for feed lists, and it includes roughly the same functionality, and you’re already dealing with XML for Atom and RSS so “JSON is easier” loses some weight. And I’m not impressed by his JSON format; it has a surprising number of dubious decisions in it given how small it is.
Very cool and beautifully built.
I maintain two projects related to web feeds (https://blogroll-network.alexsci.com/ and https://blog-quest.alexsci.com/) so I'll share my perspective.
I like the spec for a single place to store feed information, but until the new approach gains significant traction among feed reader/discovery software, sites would be wise to continue linking feeds on every page. This poses a challenge for adoption as sites won't see a benefit until this becomes the dominant discovery approach and they can remove other auto-discovery methods.
I push back on the concept of freshness. It's OK for sites to only update when they have something worth posting. I'm more likely to subscribe to a feed if it has good content but posts less than yearly. They aren't "abandoned".
I didn't realize rel=feed was a thing!