Almost every site you read regularly is already broadcasting a feed. WordPress generates one automatically. So do Substack, GitHub, YouTube, and every static-site generator worth using. The reason this feels like a lost skill is that browsers quietly stopped showing you the subscribe button years ago — but the machine-readable link behind that button never moved. It’s still sitting in the page, waiting for something to ask for it.
Finding a feed is a five-minute skill, not a technical one, and the same short ladder works whether the target is a newspaper, a YouTube channel, or a single GitHub repository’s release history. Work through it in order — most sites resolve at step one or two.
Step 1: Check the Page Source
Before guessing at URLs, check whether the site is telling you where its feed lives. Right-click the homepage, choose “View Page Source” (or press Ctrl+U / Cmd+Option+U), and search the <head> section for application/rss+xml or application/atom+xml.
This isn’t folklore — it’s a real, specified convention. The RSS Advisory Board published “RSS Autodiscovery 1.0” on 27 November 2006, defining exactly this pattern: a <link rel="alternate" type="application/rss+xml"> tag, placed inside the page’s <head>, with an href pointing at the feed. The WHATWG HTML Standard formalizes the same behavior for browsers and tools generally, instructing user agents to treat the first such alternate link in the document as the page’s default feed.
I checked this live on 2026-08-27 against wordpress.org/news/, and the source contains exactly this:
<link rel="alternate" type="application/rss+xml" title="WordPress News » Feed" href="https://wordpress.org/news/feed/" />That’s the whole trick. No login, no browser extension required — just a search inside a page you already loaded.
One catch: nothing obliges a site to publish this tag. The spec governs where the link goes if it exists, not whether it exists at all. Plenty of sites serve a perfectly valid feed with no autodiscovery link anywhere in the markup, because the CMS builds the feed automatically and nobody asked the theme to advertise it. That’s what step 2 is for.
Step 2: Guess the Conventional Path
If view-source comes up empty, try the handful of URL patterns that cover most of the web. I loaded each of the following live on 2026-08-27 to confirm they still resolve — these aren’t textbook examples, they’re feeds that returned real XML the day this was checked.
| Try this path | Confirmed working example (checked 2026-08-27) | Format returned |
|---|---|---|
/feed/ | wordpress.org/news/feed/ | RSS 2.0 |
/rss | news.ycombinator.com/rss | RSS 2.0 |
/atom.xml | jvns.ca/atom.xml | Atom 1.0 |
/index.xml | gohugo.io/index.xml | RSS 2.0 |
/feed.xml | jekyllrb.com/feed.xml | Atom 1.0 |
/feeds/posts/default | blog.chromium.org/feeds/posts/default | Atom 1.0 |
The pattern roughly maps to platform: WordPress sites answer at /feed/ (and /feed/atom/ for the Atom version); sites built with Hugo default to /index.xml; Jekyll sites use /feed.xml; anything still running on Blogger answers at /feeds/posts/default. /rss and /atom.xml show up on hand-built and older blogs that never adopted a framework’s default. None of these require you to know which platform a site runs on ahead of time — just try them in order until one returns XML instead of a 404.
Step 3: Let Your Reader Guess For You
In practice, you’ll rarely need to do steps 1 and 2 by hand. Most feed reader apps — the kind you’d use day to day, self-hosted or hosted — accept a plain homepage URL in the “add subscription” box and run the same autodiscovery check themselves: they fetch the page, scan the <head> for the alternate link, and fall back to the common paths if nothing turns up. Paste in the site’s homepage first; only pull up view-source yourself if that comes back empty, which is exactly when a page has a working feed but never published the discovery tag. (Choosing which reader to use is its own decision, with real tradeoffs between hosted and self-hosted options — that’s a separate question from finding the feed itself.)
Step 4: The Platforms Worth Knowing By Heart
A few sources come up often enough that it’s worth memorizing the pattern instead of re-deriving it each time. I re-verified all of these live on 2026-08-27.
A YouTube channel. YouTube exposes a channel’s uploads as an Atom feed at youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID. I confirmed this against a real channel ID and it returns a proper Atom document with YouTube’s own yt: namespace and video entries. The awkward part is finding the channel ID — view the channel page’s source and search for "channelId", or use any of the free channel-ID lookup tools. Once you have it, the feed URL is fixed and doesn’t change even if the channel later changes its display name or custom handle.
A GitHub releases page. Any public repository publishes its release history as an Atom feed at github.com/OWNER/REPO/releases.atom — no API key, no rate-limit headache. I checked this against a large, actively-maintained repository and it returned a clean Atom feed with one entry per release. This is the single most useful pattern in this list if you track software you depend on: subscribe once and every new release lands in your reader instead of requiring a manual check of the repo.
A Substack publication. Substack newsletters — including ones on custom domains — publish a full-text RSS 2.0 feed at /feed. I verified this against a live, actively-updated Substack and the feed carries complete article HTML in content:encoded, not just a summary and a link. That matters: some publishers deliberately truncate their feed to push you back to the site, but Substack’s default is full text, which is worth knowing before you assume a feed is a teaser.
A subreddit. Reddit has historically served .rss on a per-subreddit basis (reddit.com/r/SUBREDDIT/.rss). ⚠️ I was not able to independently verify this pattern on 2026-08-27 — the fetch was blocked at the tooling level in this environment, not by Reddit returning an error. That is not the same thing as evidence the feed is gone; it means try it yourself, or let your reader’s “add by URL” attempt it, before concluding it doesn’t work.
Beyond these four, the same pattern extends further than most people expect: Mastodon serves a per-account feed at /@username.rss, and Bluesky does the same at /profile/HANDLE/rss — both confirmed live on 2026-08-27. A social platform launched years after “RSS is dead” became conventional wisdom still ships a working feed for every account. Worth trying before assuming a newer platform has no feed at all.
Step 5: Validate Before You Trust It
Once you have a candidate URL, don’t just paste it into a reader and hope. The W3C Feed Validation Service at validator.w3.org/feed/ — still live and functioning as checked on 2026-08-27 — is exactly what it sounds like: “a free service that checks the syntax of Atom or RSS feeds.” Paste the URL in, and it will tell you plainly whether what you found is a well-formed feed or a page that merely looks like one. This takes ten seconds and saves you from adding a broken feed to your reader and wondering later why it never updates.
Step 6: When There’s Genuinely No Feed
Some sites really don’t have one — no autodiscovery link, none of the conventional paths resolve, and the platform simply never built feed support. For those, a small category of tools generates a feed from a page that doesn’t have one:
- RSS-Bridge — released into the public domain and, as of this check, listing 447 individual “bridges” covering sources like YouTube, Reddit, Telegram, and generic CSS-selector or XPath scrapers for arbitrary pages.
- RSSHub — an open-source project describing itself as “the world’s largest RSS network,” currently claiming over 5,000 independently-run instances covering a huge range of sites and platforms.
Both are worth knowing about, and both come with an honest caveat: they’re third-party software reverse-engineering a site that never agreed to be fed this way. A site redesign can silently break a bridge. Public instances get rate-limited or taken down without notice. Both projects mitigate this by caching aggressively — specifically to avoid getting the instance’s IP blocked by the source site — but “aggressive caching” also means the feed you get can lag the live page. Treat a bridge as a genuine gap-filler for a source that will never ship its own feed, not as a permanent, maintenance-free substitute for one.
Frequently Asked Questions
Do I need an account to subscribe once I find a feed? No. Fetching a feed URL is an ordinary web request — the same kind your browser makes loading any page. There’s no login step, and the site doesn’t need to know who you are for the feed itself to work. (Your reader app may want an account for its own sync features, which is a separate thing.)
What if the feed URL I found returns a 404? Work back up the ladder: re-check the page source for an autodiscovery link (sites sometimes serve the feed at a URL that doesn’t match any convention), try the site’s homepage in a reader that runs autodiscovery for you, and only reach for a bridge tool once both of those come up empty.
Why does the feed only show a summary instead of the full article? That’s a publisher choice, not a limitation of the format. Some sites deliberately publish summary-only feeds to drive clicks back to the page (and its ads); others, like Substack by default, ship full text. There’s no universal answer — you have to check the individual feed.
Is there a browser button for this anymore? Not reliably, and not worth counting on. The autodiscovery link in the page hasn’t gone anywhere, but most mainstream browsers no longer surface it in the address bar the way they once did. That’s a separate story from whether the feed itself works — it usually still does.
I found a working feed. What next? Paste the URL into whatever reader you’re using — that’s it, no separate “subscribe” step beyond adding it. If you haven’t picked a reader yet, that choice (hosted vs. self-hosted vs. a local app, and what each one costs you in setup or subscription fees) is worth its own decision, separate from the feed-finding itself.
Every technique above works because a feed is nothing more than a plain URL that returns XML on request. There’s no algorithm deciding whether you’re allowed to have it, no approval process, and once you’ve found it, it keeps working until the publisher takes it down. That’s the whole appeal — and it’s also why it’s worth the five minutes to go looking before assuming a site simply doesn’t have one.
Recommended Resources
Everything in this article comes from free, public documentation — the RSS Advisory Board’s autodiscovery spec, the WHATWG HTML Standard, and the W3C Feed Validation Service all cost nothing and are worth bookmarking before you buy anything.
If you want to go a level deeper than “here’s the URL pattern” — actually understanding how feed formats, autodiscovery, and parsing fit together well enough to build or debug your own — two books from the format’s own era still hold up as references:
- RSS and Atom in Action — the most complete treatment of both formats side by side, including autodiscovery and the mechanics this article walks through by hand.
- Developing Feeds with RSS and Atom — a shorter, more practical O’Reilly guide to the same mechanics, useful if you’re building or generating feeds rather than just consuming them.
Both are 2000s-era books — there’s no newer edition because the formats themselves stopped changing, not because the books are outdated. The specs haven’t moved either, which is exactly why they still work.