If you’ve inherited a creaky old WordPress site or a custom CMS duct-taped together in 2009, your first problem is often just figuring out where the RSS feed lives — or if it even exists. WordPress usually has it at /feed, but I once spent an hour debugging a non-working feed only to realize some SEO plugin had helpfully forced it to /rss.xml and then broken the rewrite rule.
Static site generators like Jekyll, Hugo, or Eleventy typically output a feed at build time, and it’s usually declared in the head tag — assuming you remembered to add it. Problem is, some deploy pipelines auto-strip that line depending on the environment. I ran into this with Netlify on a newer Hugo site — the dev branch had a feed, but prod didn’t. Hilarious and horrifying.
If nothing else, open the page source and Ctrl+F for application/rss+xml. You’d be surprised how often the right path is hidden in a legacy meta tag.
Dealing With FeedBurner’s Ghost
Yes, it’s technically still alive, but please — stop using FeedBurner unless you like gambling every time Google memory-holes a product. I once migrated a client off FeedBurner only to realize someone had embedded the FB-edited feed into a half-dozen old press releases… so unchecking it meant their partners’ widgets all broke for a week. Good times.
If you’re stuck on it, at least make sure you set a canonical link rel=”alternate” back to your actual feed. That way, clients can eventually wean off the FeedBurner endpoint without melting down. Also, many modern feed readers now bypass the redirect and hit the origin feed anyway.
RSS Caching and When It Ruins Your Updates
One of the dumber bugs I hit: Cloudflare cached the RSS XML file for 96 hours despite no headers authorizing that. That was back when I was still on the free tier and hadn’t set page rules to bypass caching for XML. If your feed updates but your readers don’t see it, check your CDN first — especially if you’re behind Cloudflare or Fastly.
Things I Now Assume Every Time an RSS Feed Acts Weird:
The XML file is stuck in edge cache
The feed validator is tripping on a smart quote or emoji
There’s a hidden meta http-equiv=”refresh” lurking in the head
The feed request is being redirected by a plugin you forgot existed
A user-agent string ban is quietly blocking your parser
Someone embedded a malformed CDATA close tag and goodnight sweet XML
Actually saw some e-commerce plugin decide to inject a base64-encoded analytics pixel into the feed — upstream reader threw an unreadable parse error that only resolved when I stripped out the plugin entirely. “Aha,” I said to no one, “now we’re doing HTML tracking scripts… in RSS.”
Auto-Discovery Tags That Don’t Actually Work
This one took me forever to believe because in theory the link rel=”alternate” type=”application/rss+xml” method is the blessed way. But I tracked a problem where the feed existed and was served fine, but wasn’t picked up by Firefox’s old built-in reader or several other aggregators. Turned out it was due to the feed being linked below a broken meta charset — they silently failed traversal when the preceding head node contained invalid character encoding. Firefox’s parser decided “nah.”
I only figured this out by opening the dev tools, manually grabbing the HTML, and running it through a feed validator hosted on a university domain (w3.org still works too if you’re in desperate mode). Encoding issues don’t just make the XML unreadable — they screw up even discovery from HTML.
Feed Readers That Aggressively Throttle or Rewrite Links
Ever wonder why your feed stats show 50 subscribers but your server only logs four requests per day? Some readers are clever — they cache remotely, poll once an hour, and hand off a static internal copy to their users. Feedly, for example, does this. So does Inoreader. This means if you’re inserting dynamic content (ads, personalized snippets, whatever), most users will never see it unless you implement per-user feeds or break standard RSS completely.
Also, some readers rewrite your internal links to go through their own proxy/click tracker. One client noticed that all their UTM parameters were randomly gone in half their referral reports. Turned out a reader was stripping utm_* from links, possibly to prevent affiliate hijacking. The joy of opaque middlemen.
RSS in Email: It Mostly Works, Except When It Doesn’t
I once set up a Mailchimp campaign to pull in blog posts via RSS-to-email. Everything looked fine until an hour after send. Four thousand subscribers got an email where the first image in every post showed up broken. Why? Because I had used relative paths in the img src and Mailchimp prepends its tracking domain… which doesn’t do smart resolution. Absolute URLs only, every time.
Second issue: if your CMS delays post timestamps for scheduled publishing, but the feed gets built by a cron job running independently, sometimes a post shows up “in the past” and gets skipped by some email tools. RSS readers often handle delayed timestamps just fine. Mailchimp’s parser? Not so much.
How Podcatchers Handle RSS Is Technically Legal, Functionally Junk
Podcast RSS feeds are a separate beast. First, they rely on iTunes-specific namespaces (itunes:subtitle, itunes:image, etc). Miss one tag and you get a lovely blank avatar in Apple Podcasts.
What I didn’t expect was how aggressively some apps will ignore enclosure types. One show I helped host had an episode where the enclosure tag pointed at an MP3, but the MIME type was set incorrectly to application/octet-stream. The episode showed up in the feed, but Apple Podcasts refused to show the play button. Same site, same file, but Pocket Casts played it. Blind.
“If your CDN doesn’t set the Content-Type header, and iTunes doesn’t like what’s there: boom. No download. No warning. No log. Just silence.”
Undocumented Quirks That Break Feed Validity
You would think tools like Feed Validator or the W3C checker would catch everything. Nope. One ghost-level bug we spent half a day chasing came down to this: an ampersand in a title tag inside item that was encoded as amp inside a CDATA block. Perfectly allowed XML. Totally unreadable result in most feed aggregators. Why? Because many readers double-decode CDATA even when they shouldn’t.
This isn’t in any spec. This isn’t in any validator I’ve seen. Your only way to catch this is to manually open the feed in the target reader or parse it yourself via curl and grep.
Feed Size Limits and When They Cut Off Posts
There’s no single universal limit, but from painful experience: if your feed is bigger than around one megabyte, half the readers will silently truncate it. Some even cut it by number of item entries — I’ve found 20, 50, and 100 item hard caps depending on the service. Also, if your feed is paginated (like with atom:link rel=”next”), make sure those URLs are absolute and reachable. Relative pagination breaks about half the tools I’ve tested.
I saw one Shopify blog generate a feed with 75 items and 30kb of inline CSS inside each item’s description. Burned the entire 1MB ceiling instantly. Result: only the first handful of items actually made it through. The rest? Dropped off the planet.
Just because the file serves cleanly in the browser doesn’t mean the client sees it all. Log everything during testing. Tail your access logs and watch the User-Agent strings closely — you’d be surprised how many little bots still hit with curl or YahooFeedSeeker/1.0.
