Why the Blogger Reading List Randomly Stops Updating
So if you’re still using Blogger (and don’t ask why, it’s stable, it works, it’s free), you’ve probably hit the dumb hiccup where your Reading List just stops showing new posts from certain blogs. Not all of them — just a few. Usually the ones you actually care about, too.
This happened to me after I added a batch of blogs one afternoon (maybe 12 or so), and half of them never updated again. No errors. No indicators. It just sat there, silently ignoring updates unless I clicked each one manually. A quiet betrayal.
Turns out, Blogger’s Reading List uses some mysterious backend process to periodically poll the blog’s RSS or Atom feeds. That’s fine. Except it:
Doesn’t follow feed redirects properly (like a 301 from http to https)
Chokes if the feed is over ~512KB
Quits polling entirely if there’s a malformed XML tag — permanently
Randomly caches certain feeds longer than others for no reason
There’s no dashboard where you can see polling status or logs. So if the feed fails once? It’s just… gone. You either re-add the blog or wait weeks hoping it refreshes. You don’t get an error, and the UI still pretends it’s subscribed.
How Blogger Detects and Parses Feed Content
Here’s the thing: Blogger doesn’t let you manually specify the RSS or Atom feed. You paste a blog URL, and it tries to find the feed for you.
Seems straightforward, right? It’s not. Blogger uses a basic crawler that looks for <link rel="alternate" type="application/rss+xml" href="..."> in the HTML. If that’s missing — or worse, if the page sets multiple conflicting feeds — Blogger gives up and picks the first one it sees.
A Medium-based blog I added just pointed to /feed which redirected to a feed proxy, which itself returned an Atom response but with HTTP 203. Blogger ignored the whole thing.
Best case, you can trick Blogger into using the correct feed by appending the feed URL directly, like:
https://example.com/feed/posts/default
Instead of just https://example.com. But the UI doesn’t officially support adding feeds this way — it just doesn’t stop you either. Total Schrödinger’s feature.
That Weird Blogger + FeedBurner Behavior
Remember FeedBurner? Yeah, you do. Some bloggers still route their RSS through it, because they added it in 2007 and never changed anything. When Blogger hits one of these links, you’d think it would just fetch the FeedBurner output.
But nah. What actually happens:
Blogger follows the feed link to FeedBurner
FeedBurner redirects to the source blog’s old feed
If there’s another redirect (like http-to-https), Blogger stops
So you end up with Reading List showing an old snapshot from 2016 — whatever FeedBurner last returned before the redirect chain broke. It looks normal in the UI because the title and favicon resolve.
If you try removing and re-adding the blog with the raw FeedBurner URL, it sometimes works… unless the feed is cached hard. I once fixed it by adding URL parameters like ?t=1 to bust the cache, which felt dumb, but it triggered a refresh.
Patch Feed Discovery Using Inspect Element
This is the dumbest trick I’ve used but it’s worked repeatedly. If Blogger won’t discover a feed on its own:
Go to the blog’s homepage in Chrome or Firefox
Right-click → View Page Source
Search for type="application/rss+xml"
Copy the actual feed URL (should end in .xml or /feed)
Paste that direct URL into the Blogger “Add” field under “Manage Reading List”
For most WordPress-powered blogs, you can just append /feed. For Blogger-hosted ones, use /feeds/posts/default. The only ones that break consistently are Ghost blogs, which often use JavaScript-based routing and don’t expose anything feed-like unless you knew to append /rss/.
A friend fed me this trick:
ex. https://someghostblog.com/rss/
Totally undocumented but worked like a charm. Bookmark that pattern — it took me 20 minutes of trial and error plus curl headers to figure out.
How Cache Misfires Bug Out Entire Lists
I learned this after rebuilding my Reading List from scratch (don’t ask). Turns out, if one feed throws a malformed entry, Blogger’s local caching routine for your account sometimes bails on the entire list refresh.
So you’re subscribed to 25 blogs. But one messed-up XML CDATA tag from a Tumblr post nukes the polling batch, and… all of them stop refreshing. Indefinitely. Add a new blog? That one works. The old 25? Still frozen.
I stumbled into a workaround by accidentally removing a blog that was no longer active (404). Suddenly, all the others updated at once. My hunch is that Blogger caches per-user feed snapshots, and one busted feed poisons your local retrieval session.
If that happens again:
Remove any dead or stale blogs first
Wait 10–30 minutes before re-adding anything
Consider clearing browser storage just to be safe
Bonus level weirdness — signing in from a second Google account (incognito) and viewing your own Reading List sometimes triggers a background refresh. It shouldn’t work. It occasionally does.
No HTTPS? No Reading List
I had one personal indie blog break completely. Turns out it was still on HTTP because the domain’s nameservers hadn’t been updated properly since years ago. Blogger refused to fetch the feed. Didn’t complain — just always “No recent posts” even though the XML looked perfect in the browser.
You’d assume it’d follow an HTTP response. It didn’t. I flipped the domain to Cloudflare, redirected all HTTP to HTTPS, and tada: suddenly, Reading List recognized the posts again.
This is a weird undocumented edge: Blogger fetch logic now requires SSL. If your blog is exposed over HTTP but doesn’t redirect cleanly, it won’t populate. I’ve since seen this break other integrations too — like in AdSense’s auto-detect for site monitoring tools.
When Feedburner Fallbacks Lead to Duplicate Blogs
Got burned by this while trying to centralize links. I added a blog using both its direct Blogger link and its old FeedBurner one (don’t ask — I forgot I already followed it). Blogger happily let me add both… with slightly different favicons and display names.
Thing is, the duplicate showed up as two entries in the list, but updates only showed under one version. Total mystery until I realized FeedBurner and Blogger were returning the same root feed, but FeedBurner’s was throttled due to usage.
Worse: if you delete the wrong one? You might kill your cached subscription and need to re-add from scratch. Blogger definitely isn’t deduplicating by feed GUID or title. It’s just checking the feed URL string, and that’s it.
The Nonexistent Debugging Experience
This part kills me. There is no API. There is no interface to refresh an individual feed. No logging. No error returns. Nothing like what Feedly or even Inoreader gives you. You’re flying blind, and support links inevitably lead you to ancient Google Groups threads or canned help docs at support.google.com.
In their defense, it’s not even presented as a production-level feature. The Reading List is tucked in a dying corner of the Blogger dashboard. But like, lots of folks still use it — and having zero visibility into feed status is rough.
Your only real option is removing/re-adding blogs until stuff starts appearing again. If it still doesn’t? Check SSL certs, malformed feeds, and make sure they’re outputting under 1MB with proper headers. Yeah, I’ve used curl -I to debug Blogger’s feed ingestion. It’s come to that.
