How to Find the RSS Feed of Any Website (Even When It's Hidden)

The orange RSS icon disappeared from the web around 2013. The feeds mostly didn't. WordPress, Ghost, Substack, Medium, most news sites, every podcast, and a surprising number of company blogs still publish one — they just stopped putting a link to it anywhere you'd notice.

So "this site doesn't have RSS" is usually wrong. Here's how to check properly, in the order that costs you the least time.

1. Guess the URL (10 seconds)

Six paths cover the large majority of publishing software. Take the site's root and try:

/feed
/rss
/feed.xml
/rss.xml
/atom.xml
/index.xml

WordPress answers on /feed. Ghost answers on /rss. Hugo and most static-site generators answer on /index.xml or /atom.xml. Jekyll usually does /feed.xml.

You'll know you've hit one when you get a wall of XML, or a plain browser-rendered list of article titles. If you get the site's 404 page, move on — don't spend more than a few seconds here.

One caveat: some sites answer on a subpath rather than the root. A publication at example.com/blog may well put its feed at example.com/blog/feed, so try the section root too.

2. Read one line of the page source (30 seconds, and it's authoritative)

Guessing is the shortcut. This is the actual mechanism.

The HTML standard has a way for a page to declare its own feed, and it's the thing every feed reader looks for first:

<link rel="alternate" type="application/rss+xml" title="Example Blog" href="/feed.xml">

To find it: open the page, view source (Ctrl+U / Cmd+Option+U), then search the source for alternate. If a feed exists and the publisher wired it up correctly, its address is sitting right there in the href. The type will be application/rss+xml or application/atom+xml — both are feeds, and any reader worth using consumes both.

If the href is relative (/feed.xml rather than the full address), stick it on the end of the site's origin.

This is worth knowing because it's the case that beats guessing: a site on a custom domain running software you can't identify, publishing at some path you'd never try, still has to declare itself here for browsers and readers to find it.

3. Platform rules that URL-guessing won't find

Some of the sources you most want are the ones where neither trick above works, because the feed lives at a URL derived from a handle or an ID.

Substack — https://<publication>.substack.com/feed. On a custom domain, the publication still declares the feed in its page source, so step 2 finds it.

Medium — https://medium.com/feed/@username. Note the ordering: it's /feed/@user, not /@user/feed, which is the mistake almost everyone makes first.

Reddit — append .rss to the listing you're looking at. https://www.reddit.com/r/investing/.rss for a subreddit, https://www.reddit.com/user/name/.rss for a user. No lookup required, which makes Reddit the easiest social source to pull into a reader.

Mastodon — https://<instance>/@<user>.rss. If you have the handle in @user@instance.tld form, the instance is the part after the second @.

Bluesky — https://bsky.app/profile/<handle>/rss, where the handle is what's in the profile URL (alice.bsky.social, or a custom domain handle).

YouTube — the feed is https://www.youtube.com/feeds/videos.xml?channel_id=<CHANNEL_ID>, and the channel ID is the awkward part. If the channel URL is /channel/UC..., you already have it. If it's a @handle or a /c/ vanity URL, the ID isn't in the URL at all — open the channel page, view source, and search for channelId or the canonical link. Both contain the UC… string you need.

Podcasts — every podcast is an RSS feed; that's what the medium is built on. If you have an Apple Podcasts link, the show's real feed URL can be looked up from the numeric id in that link. Most podcasts also link their feed from their own website.

GitHub — releases and commits are feeds: https://github.com/<owner>/<repo>/releases.atom and .../commits/<branch>.atom. Underrated for tracking dependencies you care about.

The genuine exceptions. TikTok and Threads publish no feeds at all. X removed theirs years ago. If someone posts only there, no tool can conjure a feed out of nothing — what you'll find offered instead are third-party scrapers, which break often and violate the platforms' terms. Better to find where that person also publishes: most people worth following have a newsletter or a blog.

4. When a site genuinely has no feed

Two cases come up constantly, and both have real answers that aren't scraping.

Newsletters. The publication is delivered to your inbox by design. The fix is to give it an address that isn't your inbox: Feedpik issues you a private inbox address, and anything sent to it lands in your reader as a source you can file, mute or unsubscribe from — with each sender becoming its own feed rather than one undifferentiated pile. (Under Discover Sources → Newsletter; Pro plan.)

Paid subscriptions. A paid Substack, Ghost or Patreon gives you a personal RSS link that carries your access in the URL. It works like any other feed, but treat it as a credential: never post it publicly, and use a reader that keeps private feeds out of anything it shares.

5. Or paste the address and let the reader do all of it

Everything above is what a feed reader does for you when it's built properly. In Feedpik, open Discover Sources, paste any site address, and it:

1. Fetches the page and reads its rel="alternate" declarations — step 2, automatically.
2. Falls back to probing the six common paths — step 1, automatically.
3. Recognises Substack, Reddit, Mastodon, Bluesky, YouTube and Apple Podcasts URLs and builds the right feed URL directly — step 3, automatically, including the YouTube channel-ID lookup.

It also distinguishes between two answers that look the same but aren't: we couldn't reach that address (typo, dead site, or the server is down) and we reached it and there's no feed here (the publisher doesn't offer one). Telling you to check your URL when the URL was fine sends you off fixing the wrong thing.

One detail that matters more than it should: Feedpik identifies itself as a plain feed fetcher rather than pretending to be a desktop browser. Some sites serve a bot-protection page to anything that looks like Chrome arriving without a human behind it, which is how a perfectly good feed gets misdiagnosed as dead.

6. Before you commit: check the feed is actually worth having

A URL that returns XML isn't automatically a good source. Two things to look at:

• Does it still update? Plenty of feeds haven't seen a new item since 2019. Check the date on the newest entry.
• Full text or teaser? Many publishers put the first paragraph in the feed and a "read more" link. That's their call, and worth knowing before you subscribe to forty of them and wonder why your reader feels thin.

The takeaway

The feed is usually there. Try the six URLs, and if that fails, view the source and search for alternate — between them you'll find almost everything. For the platforms, learn the handful of patterns above; they don't change often.

Or skip all of it: start free, paste the addresses of the sites you already read, and import your OPML if you're coming from another reader. Finding the feed is the boring part — what you do with the ranking afterwards is the interesting one.