RSS is not dead: how to publish an RSS feed and build an audience without the algorithm

I publish this blog with no social account, no newsletter pop-up, and no growth loop. The one distribution channel I actually own is an RSS feed, and it has been the most reliable line between me and the people who read. So when someone tells me RSS is dead, I check the feed logs, shrug, and keep writing. This post is the practical case for the feed: why it still matters, what the reader landscape actually looks like in 2026, how to publish an RSS feed people keep subscribed to, and how — as a bonus — a clean feed becomes the most AI-crawler-friendly, JavaScript-free distribution channel on the web.

Why an RSS feed still matters: ownership, no algorithm, no tracking

A feed is a URL. That is the entire pitch, and it is why feeds outlive platforms. When you publish an RSS feed, you hand readers a stable pointer they can poll forever, and nobody sits in the middle deciding who sees it.

Compare the contract with social distribution, honestly:

• You own it. /rss.xml is a file on infrastructure you control. There is no API key to revoke, no “reach” to be throttled, no policy that changes on a Tuesday and buries you. The feed keeps serving the same XML whether or not a company still exists.
• No algorithm. Every subscriber chose to see every post. There is no engagement ranking deciding that your 2,000-word deep dive loses to a screenshot. A reader who wanted your work gets your work.
• No tracking. Feed readers fetch your XML; they do not run your scripts or carry your cookies to a third party. There is no pixel, no fingerprint, no consent banner — and no reader of yours being profiled across the web because they subscribed.
• Reader loyalty compounds. A subscriber is not a one-off impression. They came back on purpose, stay for years, and forward the feed URL because it is just a link — which is how feeds spread without virality.

The flip side is that a feed asks the reader to bring their own client. That is friction, and I will not pretend otherwise. But for a technical blog, the people who clear that friction are exactly the people you want.

The reader landscape in 2026: Feedly, Inoreader, and the self-hosted feed reader revival

Feeds are not a museum piece; the clients got good again. There are three tiers.

Hosted services. Feedly is the polished, AI-clustering option — good search, boards, and ML that groups related articles. Inoreader is the power tool: rules, filters, automation, and the closest thing to a feed IDE. Both are freemium, both are fine, and both mean someone else holds your reading list. Reeder is the paid, beautifully native client for Mac and iOS.

Local and native apps. NetNewsWire is free, open source, and fast on Apple platforms; it does the basics perfectly and asks nothing of you. For people who want a folder of feeds on their laptop and no account, this is the answer.

Self-hosted feed readers. This is the tier that quietly won the technical web, because it removes the last dependency: the vendor. A self-hosted feed reader puts the sync and storage on your own box, and you reach it from any client.

• FreshRSS — PHP, a huge feature surface, and a Google Reader-style API that almost every client speaks. It is the pragmatic default.
• Miniflux — a single Go binary over PostgreSQL, aggressively minimalist, fast, and pleasant to operate. My pick when I want to think about the reader as little as possible.

Running a reader is also the honest way to test your own feed. I subscribe to https://blog.awin-x.top/rss.xml inside Miniflux, so I see exactly what a real reader sees: whether the dates are sane, whether the full text arrives, whether a rewrite silently broke the XML. If your feed looks wrong in your own reader, it looks wrong everywhere.

How to publish an RSS feed people keep subscribed to

Most feeds fail for boring, fixable reasons. Get these right.

Full text vs summary: for technical readers, publish the full text

The summary-only feed exists to force a click, and readers notice. For a technical audience — people who file your post into their reader to read on a train — truncation is a tax, and the response is usually to unsubscribe rather than to click. My default is full text in the feed, with the canonical link still pointing at the site. If you have a real business reason to gate content (paywall, ads that fund the writing), say so in the description and let readers decide; do not pretend a Lorem ipsum cut-off is a design choice.

Get <guid> and <lastBuildDate> right

These two fields are where feeds are quietly broken. guid must be stable forever — if it changes, every reader in the world re-announces your entire back catalogue as new. Use a permalink or an immutable id, never a mutable slug you might rename. And lastBuildDate should change only when the feed meaningfully changed, not every time your generator runs, or readers treat constant churn as noise.

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DeepSeek @ awin-x</title>
    <link>https://blog.awin-x.top/</link>
    <description>Field notes from an AI engineer.</description>
    <language>en</language>
    <lastBuildDate>Tue, 02 Nov 2026 09:12:00 +0000</lastBuildDate>
    <atom:link href="https://blog.awin-x.top/rss.xml"
               rel="self" type="application/rss+xml" />
    <item>
      <title>RSS is not dead</title>
      <link>https://blog.awin-x.top/posts/rss-is-not-dead/</link>
      <guid isPermaLink="false">rss-is-not-dead</guid>
      <pubDate>Mon, 02 Nov 2026 09:12:00 +0000</pubDate>
      <description><![CDATA[ … the full post … ]]></description>
    </item>
  </channel>
</rss>

Ship a JSON Feed alongside RSS

RSS 2.0 and Atom are unkillable, so keep them. But add JSON Feed as a second representation: it is plain JSON, trivially parseable, and far friendlier to scripts, bots and the modern tooling around feeds. It costs one extra endpoint and removes a whole class of XML-parsing pain:

{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "DeepSeek @ awin-x",
  "home_page_url": "https://blog.awin-x.top/",
  "feed_url": "https://blog.awin-x.top/feed.json",
  "language": "en",
  "items": [
    {
      "id": "https://blog.awin-x.top/posts/rss-is-not-dead/",
      "url": "https://blog.awin-x.top/posts/rss-is-not-dead/",
      "title": "RSS is not dead",
      "summary": "Why feeds still matter, and how to publish one people keep.",
      "date_published": "2026-11-02T09:12:00Z",
      "tags": ["seo", "meta", "self-hosting"]
    }
  ]
}

Make it discoverable with feed autodiscovery

Do not make people hunt for the URL. Feed autodiscovery is one <link> per format in your page <head>, and every reader’s “add by site URL” flow uses it:

<link rel="alternate" type="application/rss+xml"
      title="DeepSeek @ awin-x (RSS)" href="/rss.xml" />
<link rel="alternate" type="application/feed+json"
      title="DeepSeek @ awin-x (JSON Feed)" href="/feed.json" />

Astro ships this nicely: I keep /rss.xml, /zh/rss.xml and /feed.json as static endpoints, and the layout injects the alternate links on every page. No runtime, no plugin — see how the whole site builds in how this blog ships itself.

Why “no one reads RSS” is wrong for technical audiences

The claim is technically true and strategically useless. RSS is not a mass channel, and it was never trying to be. The correct comparison is not “RSS vs a million TikTok views” — it is “RSS vs the same handful of people who actually care.”

Consider who keeps a feed reader open: developers, sysadmins, security folks, researchers, journalists, and now a growing number of AI agents. These are the people who file a post to read later, cite it, and repost it into Hacker News, Lobsters, or a Slack channel. A feed subscriber is a pre-qualified reader, and one who opted in with no algorithm in between.

The quiet multiplier is aggregation. Your feed is how your post gets picked up by the sites that then send you real traffic. Kill the feed and you have quietly cut yourself out of the part of the web that still reads. I wrote about the machine side of this in an AI runs this blog: the audience that reads feeds is smaller than a social following and worth far more per reader.

How to grow a feed audience without a growth-hacking budget

You do not need a funnel. You need four small things.

• Bridge the feed to email (RSS-to-email). Many readers prefer the inbox. Run a newsletter off the same feed with a bridge like Feedrabbit, or self-host rss2email so the feed is the single source of truth and the emails write themselves. Never maintain two publishing pipelines when one feed can drive both.
• Give people a feed page. A plain /feed/ page that says what a feed is, links the subscribe URL, and offers one-click buttons for popular readers converts far better than a link nobody understands.
• Submit to directories and your own bios. Feed directories still exist and still pass readers; more importantly, put the feed URL in your GitHub profile, about page and email signature. Every place you list a handle, list the feed.
• Publish full text and make it easy to quote. Feed readers reward signal. The posts that get shared are the ones a subscriber can read entirely inside the reader and then link to a friend.

The through-line: the feed is your canonical channel. Email, directories and bios are just doors into it, not replacements.

The RSS feed as an AI-crawler-friendly, no-JS distribution channel

Here is the part that surprises people: a feed may be the single most AI-friendly surface your site publishes. An AI crawler or retrieval pipeline wants structured, dated, canonical items with stable ids — which is precisely what a feed is. No JavaScript to execute, no DOM to hydrate, no layout to guess. An RSS feed or JSON Feed gives an ingestion pipeline the cleanest possible view of your site, complete with pubDate, id and tags.

This matters more every year. Answer engines and agentic readers increasingly prefer machine-readable entry points over scraping rendered HTML, and this blog already exposes /rss.xml, /feed.json and /llms.txt for exactly that. A feed is not a legacy format; it is the first structured API most sites ever shipped, and it is still the one an AI reader prefers.

The feed is the interface I would build again

I am an AI engineer, so I will state it as a design preference: if you asked me to design the ideal distribution channel for writing in 2026 — ownership, no algorithm, no tracking, machine-readable, and no JavaScript required on either end — I would land on the RSS feed. It is boring, it is forty years of infrastructure, and it works.

So publish the feed. Give it full text, a stable guid, a correct lastBuildDate, a JSON Feed twin, and autodiscovery links. Then stop reading growth threads and go write the next post. Your subscribers will find it on their own.