Tag Soup and Taxonomy Purgatory: Stop Letting the CMS Run the Archive
If your archive is just a reverse-chron list of posts, sorry, but you’re basically handing your best content a bag of rocks and shoving it into traffic. Every CMS I’ve touched in the wild—WordPress, Ghost, whatever flat-file mess someone proudly called “headless”—builds archives as if users are archaeologists who will gladly dig through tags from 2019 to find something useful.
I once walked into a client’s Ghost instance where their most-read piece ever was buried three clicks deep behind a category they hadn’t updated in two years. It was technically accessible, sure… but only if someone manually typed the slug. You know how many people do that? Zero.
The problem? Most CMS-generated archive pages rely way too heavily on a rigid taxonomy model—categories, tags, months—and assume the content ages like wine. It doesn’t. It ages like milk.
Instead of trusting your CMS to define relevance, create your own thin-layer routing logic. Pull your content directory into a JSON object, apply some filters based on metadata scores (promo flags, view counts, conversion, etc.), and generate custom feeds that aren’t time-bound. You can even build time-aware weightings if you’d rather fight entropy manually.
Yes, this requires cracking open the backend. But trust me, hacks like this redirect blog SEO value from “Look, we blogged in Q1 2020” to “Here’s our eight posts that actually convert.”
Stop Making Author Archives Act Like They’re Portfolio Pages
Here’s the thing: no one wants to browse all of “Matthew’s” posts unless Matthew is some kind of celebrity. Author archives make sense in the newsroom model—if you’re Wired and people actually follow bylines. But on a standard dev or product blog? You’re just bloating the route map.
In one particularly annoying Hugo-based system, we noticed that author pages had better SEO than the blog categories themselves… because the CMS was auto-generating them and stuffing the header with structured data that looked more authoritative. Net result: people Googling “Websocket sketchy bug” landed on Editor Dave’s archive instead of the actual article where we fix the bug.
If you’re stuck with author pages, either:
Patch the routing to redirect author archive slugs to a curated list of their most-read entries.
Add disallow rules in robots.txt for /author/* if you’re not maintaining them.
Control template output: keep just the top 3–5 pieces surfaced, and kill off the pagination entirely.
Otherwise, they’ll act like weird content traps that dilute search relevance and misdirect internal traffic.
Disabling Smart Caching Extensions for Admin Views (Because, Yeah…)
Sounds obvious, right? You’d think. But I lost about four hours once because a semi-random combination of Cloudflare cache rules and the W3 Total Cache plugin decided to cache the backend of my static blog generator. Yes, the admin view. I was seeing old post drafts—some of which I had already deleted—resurrect themselves in preview windows like ghost code.
This led to one of the most haunted early mornings of my blogging life. I thought the CMS DB was corrupted. Spoiler: it wasn’t.
Data that lied to me:
GET /admin/posts/1110-preview HTTP/2
200 OK
x-cache: HIT
x-cloudflare-cache-status: HIT
It looked legit. But it was a fake 200 with stale content. The actual content was way newer. Bypassing cache via query string fixed it (?no-cache=1), but long-term fix was to set Cloudflare and local cache rules to exempt anything under /admin/* or /preview/* paths. Use Page Rules or transform rules for that—don’t just purge cache globally unless you enjoy rate limiting.
AdSense on Archive Pages ≠ Automatic Revenue
I made the mistake of just blanket-enabling AdSense on all pages once. Immediate revenue spike! And then… a slow decline. Why? Turns out archive pages serve impressions without meaningful interaction. People bounce fast, especially from shared post directories. AdSense’s ML picks up that low engagement and slowly downranks your property for higher-value ads.
The worst part is there’s no clear warning from AdSense support about this. I only found out after poking through the Ad Experience Report and seeing horrible CLS scores tagged specifically to multi-ad slots on “/archives” or “/tags/python”.
What fixed it: limiting ads to posts over a certain engagement threshold. I used a dumb JS wrapper to check scroll depth + time on page, and only then load AdSense via lazy embed. Worked better than Auto Ads… which ironically placed 3 slots inside footers on 404s.
Structured Data Gotchas in Archive and Pagination URLs
Google really hates duplicate structured data—especially when it’s tied to paginated collections. If you’re injecting Article schema in your head tags, don’t let it leak into /archives/page/2/ and beyond. It causes soft penalties that don’t trigger actual search console errors, just causes demotion on SERPs that feels like a ghost algorithm strike.
Real example: I defined an Article object in the layout template with Liquid. Cool, right? But that ran per-render, even on archive loops. So page 2 of my blog feed had twelve structured articles with identical metadata to page 1. Google didn’t freak out, but everything started drifting down in ranking. Worse: I couldn’t prove anything.
The fix:
Use conditional logic to suppress or rewrite structured data on collections. OR define only list-level schema (ItemList) with real index position properties instead of nested Article details. You can keep JSON-LD above the fold for single posts. Just don’t broadcast post-specific schema in bulk views.
Busted Internal Linking from Auto-Generated Excerpts
You ever audit your own blog and find that your internal links are pointing to archive pages instead of canonical content? Because I have. And it’s always because somebody trusted a CMS to auto-generate excerpts.
Some systems (looking hard at WordPress circa 5.4) strip HTML from excerpts but retain plaintext URLs inside tag bodies. So you end up with sentences like “read more in our blog” where <a> tags are stripped but the href survives. Result? Broken or partial links showing on snippet cards, and sometimes getting reinterpreted as plain text anchors in crawlers.
Worse, because it’s inconsistent—some themes sanitize, some don’t—you might only spot the anomaly on older posts. Or translated versions. I lost a week once trying to figure out bounce spikes from Taiwan traffic, only to discover that our zh-TW excerpts were leaking half-formed links stripped of context.
Run a crawler (like Screaming Frog or Sitebulb) and inspect your meta description and top-of-feed snippets. Strip markup deliberately or rebuild excerpts manually with real summaries—not just a {{ content | truncate: 160 }} hack job.
Collections Without Signals: Stop Equating Tags with Themes
Tags aren’t collection signals. They’re loose associations. When you generate an archive page based on the “analytics” tag, you’re bundling together anything from a throwaway GA4 update to deep-dives on funnel optimization. That doesn’t help the reader—or you, if you’re trying to service intent for search or share.
I saw one site segment their posts into user-definable “tracks”—basically editorial playlists. They’d surface these on the archive landing page as “Working With Large CSVs,” “Real Browser Testing,” or “Fixing Things in Production At 2AM.” Way more engaging than raw tags.
If you control your markup and routing, you can implement soft tagging systems using frontmatter or YAML arrays like:
Then render those as optional collections with prioritized SEO and custom slugs. They’ll look like curated themes—as they should.
Scheduling Hell: Syncing Archive Updates Across Caches With File-First Systems
One time I had a static build deployed via Netlify, Varnish in front, and Cloudflare on edge—oh, and also a site-wide service worker that loved returning old JSON. Whenever I updated archive metadata (like tagging posts into a new collection), half the visitors wouldn’t see the change until two deploy cycles later.
The trick was never the CMS—it was all the layers that sat between the content and the eyeballs.
Cloudflare cache needs proper Cache-Control: no-store on your manifest/index pages
Service workers must version their cache and perform cache.delete during update events
Netlify’s asset hashing only works if your archive pages aren’t named the same every cycle (“archives.html” is a trap)
Add a build-time timestamp to metadata files and ping it somehow: a background AJAX check or HEAD request could do
Don’t just hit refresh and hope. Archive structures lag behind unless you coordinate all your caches like you’re defusing a UX landmine.
