Your RSS feed is a published page that nobody proofreads

Your RSS feed is a second edition of your archive, delivered to readers who never see the page. Everything else you publish gets looked at by someone before or after it ships. The feed usually doesn't, because nobody on the team opens it, and the only check it normally gets is a validator, which tells you whether the XML parses and nothing about what it says.

The feed has readers the page never meets

Some people still read through feed readers, and they tend to be the most loyal readers a blog has: they subscribed on purpose and see every new post. Aggregators, newsletter tools and AI ingestion pipelines also read feeds, because a feed is cheaper to poll than a site is to crawl. For all of them, the feed is the publication. A post's title, its summary and its picture arrive in the feed's version, not the page's.

Search engines are a different case. Google's guide to building a sitemap accepts RSS, mRSS and Atom 1.0 feeds as sitemaps and notes that most content systems generate them automatically. The page carried a stamp reading "Last updated 2026-07-08" when we checked it on 18 October. So a feed can help Google find new URLs. But Google then reads the page, so a careless summary in the feed costs you nothing in search. That is the reason nobody notices it. The people who do read it are the subscribers.

A valid feed can still say the wrong thing

Our own feed went live on 15 October, at /feed.xml in English and /fi/feed.xml in Finnish. This morning was the first time anyone read it, so we read it the way a subscriber would. We put both feeds through the W3C Feed Validation Service first. Both came back valid, with zero errors and zero warnings.

The validator is right that nothing is broken. The things we were most worried about were fine too. The Finnish feed lists only posts that exist in Finnish, so no English titles slip in, there is no raw markup in any item, and all thirty images return a picture. The feed's source code was written to exclude English fallback posts from the Finnish feed, and it does.

The problem the validator couldn't see is editorial. The RSS 2.0 specification defines an item's description as "the item synopsis". Ours is the post's meta description, the same field we write for a search results page. We have argued that a meta description is only a candidate: it is written for a stranger choosing between ten results. In the feed it reaches someone who has already chosen us, and a promise like "how to test yours" reads as a pitch to someone already reading. Nobody decided that one field should serve both readers. It happened because the field already existed.

The second gap is in our own code. A comment above the feed builder says feeds are how readers and AI ingestion pipelines pick up new posts. That is true, but what they pick up is about 160 characters and a picture, because the feed carries no body text. The comment describes the feed we meant to build. The output is a shorter feed that nobody chose deliberately.

Summary or full text is a choice, not a default

Summary-only feeds are defensible. They send the reader to the page, where the hero, the language switch and the internal links are. They also give scrapers less to work with: a full-text feed is the easiest copy of your archive to take, though we have argued that copied posts rarely outrank you. Full-text feeds are defensible too. A subscriber who reads in a feed reader would rather not click through to read the post.

Either is fine, as long as someone chose it. Most feeds end up summary-only or full-text because that was the template's default. That is the same failure as the fields nobody translates: output nobody owns, because nobody looks at it after launch.

What to check, and when

A feed needs a reader, not just a validator, and it needs one at two moments. The first is launch. The second is any change to the templates or fields the feed draws from, because the feed changes whenever they do, and nothing in your normal review will show you.

The check takes ten minutes. Open each language's feed in a real reader or as raw XML. Read three items as a subscriber would and ask whether the summary makes sense to someone who already follows you. Confirm that the item count and the oldest item match what you meant to offer. Look at whether the images belong to the posts they sit under. Then compare what the feed actually delivers with what your code comments and documentation say it delivers.

The feed is part of the edition

We sell an engine that writes, illustrates and publishes posts on its own, which means its output appears in places nobody on the client's side will ever open. The page gets read and approved. The feed, the social card and the search snippet are produced from the same fields without anyone looking. If a channel ships something in your name, review it at least once, and again whenever it changes. Ours had been running for three days before anyone read it, and the problems it had were ones a validator can't detect.

We have put two questions on the list to be decided on purpose rather than inherited: what an item summary should say to someone who already subscribes, and whether the feed should carry the whole post.