RSS feed 404 Not Found — how to diagnose and fix

If your feed URL returns 404 Not Found, feed readers can’t fetch updates, and search engines that rely on feed discovery signals may stop seeing new content quickly.

Fast checklist (5 minutes)

Confirm the exact feed URL your reader/validator is requesting.
Fetch it in a browser and as a plain HTTP request (some endpoints behave differently).
Make sure it returns 200 and XML (not HTML).
If the URL changed, ensure there’s one stable 301 from the old URL → new URL.
Add/verify feed discovery links on your site so humans and bots find the canonical URL.

Common symptoms (and what they usually mean)

Symptom	Likely cause	What to do
Feed URL returns 404 everywhere	The route/file doesn’t exist anymore	Restore the endpoint or add a 301 from the old path to the new feed URL
Feed URL works in browser, fails in reader	WAF, cookie wall, bot protection, or user-agent based behavior	Allowlist feed paths; verify the raw response is XML and returns 200 without JS/cookies
Feed URL returns 200 but it’s HTML	Login page, “blocked” page, or CMS rendering a template	Ensure the feed route outputs XML; check CDN/proxy rules for feed paths
Feed URL returns 403/401	Private feed or auth required	Use proper authentication (not embedded tokens), or publish a public feed endpoint

1) Confirm the feed URL you’re using is correct

Common “almost right” URLs:

Missing trailing path like /feed/ or /rss.xml
Using a post URL instead of the feed URL
Mixing http vs https and getting blocked/redirected

Common feed URL patterns (by platform)

These vary by site setup, but the feed URL is often one of:

WordPress: /feed/, /?feed=rss2, /comments/feed/ (comments feed)
Ghost: /rss/
Many static sites: /feed.xml, /rss.xml, /atom.xml

If you’re not sure, check your site’s HTML for feed discovery links (see below).

2) Check for recent site changes

Most 404 feed outages are caused by:

a theme/plugin change that disabled feeds
switching platforms (WordPress → headless, Substack → custom site, etc.)
changing permalink settings
moving behind a CDN/proxy and breaking rewrite rules

If the feed worked last week and suddenly 404s, start your investigation with the most recent change:

Deploys (routes, rewrites, static output paths)
CDN/WAF rules (path-based blocks, bot filtering, “origin unreachable” fallbacks)
CMS settings (feed enabled/disabled, permalink structure, plugin conflicts)

3) Fix redirect chains (if you moved URLs)

If you changed feed URLs, prefer:

one 301 from old → new
no loops
no 302s that flip-flop

Redirect chains (old → intermediate → new) often break some readers.

4) Verify the endpoint returns 200 and XML (not an HTML page)

A surprising number of “404” reports are actually one of these:

a 404 HTML page behind a reverse proxy
a login wall that returns 200 HTML
a bot/WAF block page that returns 200 HTML
a regional block page or cookie consent page

Quick commands to inspect the response

curl -I https://example.com/feed.xml
curl -L -I https://example.com/feed.xml
curl -L https://example.com/feed.xml | head

What you want to see:

HTTP/2 200 (or HTTP/1.1 200)
Content-Type: application/rss+xml or application/atom+xml (sometimes application/xml is fine)
the response body starting with <?xml ...?> and a <rss> or <feed> root element

5) Validate the “new” endpoint returns valid XML

Sometimes the URL is reachable but returns HTML (a login page, WAF block page, or 403/5xx body) — which looks like a feed outage to validators.

6) Make feed discovery explicit (so clients find the canonical URL)

On your homepage (or main template), include discovery links like:

<link rel="alternate" type="application/rss+xml" title="RSS" href="https://example.com/feed.xml">
<link rel="alternate" type="application/atom+xml" title="Atom" href="https://example.com/atom.xml">

This helps browsers, readers, and crawlers find the correct feed URL even if a user copies the wrong link.

Recommended workflow

Decide the canonical feed URL you want long-term.
Make it return 200 with valid RSS/Atom.
Add a stable 301 from any old URLs.
Validate and fix the feed output to ensure it remains parseable.

Prevent it from happening again

Treat your feed URL like a public API: keep it stable for years.
Add simple monitoring that checks: status code, content type, and XML parseability.
Avoid “smart” redirects based on user-agent/cookies for feed paths.
If you use a CDN/WAF, allowlist feed paths so validators and readers don’t get blocked.

FAQ

Why is my RSS feed returning 404?

The feed URL may have changed, the CMS feed endpoint may be disabled, a rewrite rule may be broken, or a proxy/CDN may be misrouting requests.

Will a 301 redirect fix feed readers?

Often yes, but some feed readers cache aggressively; you should keep redirects stable and avoid redirect chains.

What’s the safest long-term fix?

Restore a permanent feed URL that returns 200 with valid RSS/Atom, add a stable redirect if needed, and publish the canonical feed URL in your site metadata.

Fix RSS/Atom feeds and OPML lists

Paste a feed/OPML URL, upload a file, or paste XML — then validate and fix it.

Fix my feed / Import OPML Back to Help