RSS is still good plumbing.
That is not nostalgia. It is a statement about ownership. If the site has a feed, readers can follow along without signing into another platform, waiting on an algorithm, or remembering to check the homepage by hand.
The web has spent a lot of time inventing louder ways to distribute writing. RSS keeps doing the quiet job. For a personal site, that quiet job is enough.
the feed is for the reader
A feed gives the reader control over how and when to read.
They can use a local reader, a hosted reader, an email bridge, a script, or a terminal client. They can group by topic or by priority. They can follow two sites or two hundred. They can let the post arrive and deal with it later.
That matters for technical writing. Most posts are not emergencies. They are better read when someone has time to pay attention. RSS fits that pace without asking for a new account or a notification system in the middle.
breakage usually looks small
Feed bugs are usually not dramatic. They are irritating.
A title is missing. A link points to localhost. A draft leaks. A GUID changes and the reader thinks an old post is new. Dates jump around. HTML shows up escaped. The feed validates locally and still breaks in one reader because the content shape was slightly off.
That is why I like checking feeds the same way I check routes and sitemap output. The public contract is small enough to smoke test.
At minimum:
homepage links to the feed
feed parses
latest post appears once
draft posts are absent
post links are absolute
dates sort correctly
items do not duplicate after rebuild
None of that is fancy. It is just the difference between a site that publishes and a site that feels haunted.
stable ids matter more than people think
The item ID only becomes visible when it is wrong.
If the ID changes on every build, readers think every run is a new publication. If the ID is tied to a mutable title, a title edit can look like a new post. If old items get regenerated with a different date, the archive starts to churn for no reason.
For a static site, I want the feed identity to line up with the canonical post URL or slug. Once a post is public, the feed should remember that it exists.
summaries are attention routing
A feed summary is not marketing copy.
It should tell a subscriber whether the post is worth opening. For technical writing, that usually means naming the actual topic and the angle.
Bad:
Thoughts on web publishing.
Better:
Why feed validation matters more than a social share button on a personal site.
That summary is a small routing decision for attention. It should help the reader decide, not decorate the archive.
the feed is also a check on the archive
RSS exposes problems that the browser can hide.
If the date is wrong, the title is empty, the canonical URL is bad, or the excerpt is malformed, the feed often catches it first. That makes it useful as a publishing test. The same metadata powers cards, sitemaps, search, and preview surfaces, so a feed check pulls its weight.
I would rather have one XML file complain early than discover the same bug through a broken archive card three days later.
machine clients make the case stronger
RSS is not only for humans.
Scripts, agents, feed readers, archivers, and newsletter bridges can consume it without scraping the homepage. That gives the site a predictable interface for external tooling.
In an AI-heavy world, that matters more than it used to. A feed is a stable entrance into the archive. It is much better than asking a bot to inspect the layout and hope the DOM still looks the same next week.
keep it obvious
The feed should be easy to find.
Link it in the head. Put it in the footer. Use a stable path. Do not make the reader guess whether the site exposes /rss.xml, /feed.xml, or something else hidden in a script.
The point of the link is not ceremony. It is to say the site supports a durable way to follow the writing without permission from a platform.
That is enough.
RSS is plumbing, and plumbing is only boring until it breaks. A small site with a good feed is easier to trust than a small site that depends on a platform feed or a redesign to stay discoverable.
The maintenance cost is tiny. The payoff is a distribution path that does not flinch when the rest of the web gets loud.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.