Keeping Blog Drafts Organized Without Losing Your Mind

Table of Contents

Drafts Scattered Across Too Many Platforms

I had a week where I’d whipped up an amazing post about AdSense earnings volatility in Firefox Focus—but forgot which Google account had the Blogger draft. That’s how I learned that not all Blogger drafts autosave across login sessions.

If you’re juggling WordPress, Blogger, and a rogue Notion database like I am, your drafts are probably stashed all over. Some autosave silently. Some overwrite when you paste. Some just ghost the entire thing if your login expires mid-edit.

Blogger drafts are saved per account, even on custom domains
WordPress sometimes versions autosaves without telling you
A temporary Chromebook user login? Say goodbye to anything saved in localStorage
Google Docs can accidentally hijack tab memory if two drafts are open side by side, with the same filename
Notion won’t show unsynced edits made in app vs browser, unless you force refresh the workspace
Drafts in Buffer? Forget revisiting them after 90 days unless scheduled

The bandaid fix: pick a master writing surface and use that first, even if you hate it. Mine’s a specific Chrome profile with just Bear.app open, synced once a day. All other drafts flow into it or reference it conceptually. Otherwise you end up rewriting the same intro for four tools without realizing it.

Syncing Revision History Between Devices Actually Sucks

Blogger does not sync actual revision history across devices unless you explicitly save and reload the page. That bit me during a network dropout on mobile—I edited the meta description in Safari, reopened on desktop, and boom: back to the version from three hours ago. The draft had saved “partially” because the header cleared but post body hadn’t rehydrated.

The behavior on WordPress is better, but inconsistent: autosave kicks in every 60 seconds if you’ve been typing—but if you’ve been editing HTML view? Manual save only. And the feature that lets you revert to previous versions looks reliable until you realize it saves viewported content rather than source content when using some block-based editors. Brutal.

The workaround? Mobile edits must publish to a separate holding page if you’re editing longer than 5 minutes. Then merge manually. I built a shortcut on iOS that posts to a private label on Blogger so I can snapshot partial drafts from the toilet without screwing up my canonical.

Draft Publishing Inconsistencies in Blogger

Let’s talk about the Blogger booby trap: the Publish/Update button sometimes just saves without triggering RSS or the email subscription queue. It’s maddening.

Here’s the flow that causes it:

Edit a draft that’s been sitting for more than 14 days
Update title and body
Hit ‘Publish’ without touching the timestamp

You think it’s live. It shows in preview. The URL works. But…it is not picked up in Blogger’s feed. Email subscribers get nothing. Even FeedBurner just shrugs. The ghost publish issue doesn’t happen on new posts—only older drafts.

The clue: in the post’s JSON feed, the ‘updated’ timestamp matches original ‘published’, but the Atom entry is reordered. If you don’t touch the timestamp, RSS readers assume nothing changed.

To fix that, always either:

Change timestamp by +1 minute manually
Switch from ‘Published’ to ‘Draft’, refresh, then ‘Publish’ again

AdSense Draft Fragmentation Across Multiple Sites

It gets worse if you’re running AdSense across several blogs with different Google Accounts. Drafting posts for each with matching ad logic? Ugh. You’ll start copy-pasting snippets between tabs and end up wondering which unit ID belongs where.

The real kicker

There’s no unified UI in AdSense that shows which unit IDs are *live* versus sitting inside draft posts. So when you kill a layout on one blog, those ad units may still be referenced in Blogger drafts you haven’t published—or worse: in custom JS widgets injected sitewide.

I once published a 3-month-old post and instantly reloaded five old ad units that had been deprecated. My CTR tanked overnight. The Blogger compose view had preserved those divs in WYSIWYG somehow.

Weird quirk: If you remove AdSense from the Blogger layout UI but don’t purge the widgets XML manually, the post editor will resurrect it like a zombie. I’ve seen ghost iframes appear again just by editing a sidebar headline.

Blogger’s Autosave Doesn’t Trigger on Title Change

Insult to injury: changing only your post title doesn’t always trip Blogger’s autosave. If you edit the title, tab away, and come back, it might quietly revert. I lost like four variations of a post title riffing on “The Invisible CTR Rate Problem” because I assumed modifying the title counted as content interaction.

Here’s what reliably triggers autosave:

Typing into the post body
Switching tabs within the editor (from Compose to HTML)
Editing labels or categories

Here’s what doesn’t trigger it:

Changing the title only
Modifying the permalink
Editing location or search description metadata

If everything you edit was above-the-fold stuff, like title and tags, Blogger treats that session as “not dirty” and skips autosave logic. That kind of edge case isn’t documented anywhere. I only spotted it while sniffing Chrome’s network tab on a flight with no Wi-Fi.

Custom Domain + Draft Visibility + Feed Conflicts

So here’s a lovely undocumented edge case: on a Blogger blog with a custom domain, if you preview a post draft from the old blogspot subdomain link, your feed will flag incorrect canonical paths when you eventually publish. That’s because some feed crawlers cache the previewed slug before it’s formally published—and the preview pulls from *.blogspot.com.

The impact:

Blogger’s native feed borks article order
Email subscribers on anything pulling via feedproxy.google.com get misformatted posts
Some organic traffic gets funnelled to the wrong canonical via Twitter or Discord embeds

Fix? Only preview from the Blog domain, never from .blogspot.com. Don’t trust the Compose preview links unless you’ve set your draft environment to match the live domain. If you’re testing markup or AMP meta, use an incognito window too—Widget visibility is different in live-view vs. preview for some layout frameworks.

Also: Blogger doesn’t publish OpenGraph info until the post is publicly indexed. So link previews are sometimes wrong even after publishing—unless you manually hit the Facebook debugger. 2024 and we still need to do that.

Aha: Draft Template Logic Leaks Into Feed Templates

This one stumped me for almost a day: I had conditional markup in the Blogger template that selectively showed styles depending on whether I was viewing a draft. My logic looked roughly like:

<b:if cond='data:post.isDraft'>
   <style>.ad-placeholder { display: none; }</style>
</b:if>

All worked fine until I realized that very same logic was applying to RSS/Atom feed renders. Turns out, the Blogger feed renderer includes your post’s layout template logic (!), but does not resolve data:post.isDraft—so the style tag was leaked into the actual content body of my feed.

Some feed readers interpreted that raw CSS and flattened the rest of the post body. I had one subscriber email me that the whole post appeared as blank space below the header for two weeks.

Fix? Don’t conditionally inject styles using Blogger logic tags inside the post content container. Create separate in-template <b:if> blocks for post drafts vs feeds entirely. Feed rendering doesn’t obey contextual booleans the way templates do in preview mode.

Honestly, the Blogger feed infrastructure feels like it’s clinging on from a pre-JSON era—like a haunted PHP script they just stopped touching 8 years ago.

Version Sync Mistakes from Browser Extensions

I use too many browser extensions. I know this. The one that wrecked me last was a session keeper for Chrome that synced local tabs—but copied post drafts across profiles with active edit sessions open in each.

Chrome Profile A had a draft open in Blogger.
Chrome Profile B (same blog, different login) opened the same post.
Session buddy loaded both in parallel after a reboot.
I saved in Profile A.
Then autosave kicked in on Profile B… and overrode everything.

And that’s how I learned: Blogger doesn’t block concurrent draft editing. You’d think it’d lock the post behind a mutex or at least warn of a conflicting session. Nope. It’ll just clobber it if you leave the tab focused long enough.

Now I run with session isolation rules via extension containers and avoid dual login states entirely. Also, disable autosave-on-focus extensions. They look cool until they shred 3 hours of nuanced copywriting about GDPR banner design.