1. When title tags duplicate across category pages with pagination
This one’s been haunting me since my ecomm days, where every category—”men’s t-shirts,” “warm hoodies,” whatever—had 10+ paginated versions. Guess what? They all had the same damn title tag unless you explicitly did something about it. Google does NOT treat ?page=2 as unique content, and it absolutely will group all those together and choose one canonical version at random if you leave titles duplicated across paginated URLs.
In Shopify, it’s a known headache. Unless you overwrite the {{ page_title }} logic for paginated views, your category pages become an SEO sinkhole. I didn’t figure this out until Google Search Console started hiding results from everything past page 1.
Useful snippet if you’re doing this manually:
{% if paginate.current_page > 1 %}
<title>{{ collection.title }} – Page {{ paginate.current_page }} | My Store</title>
{% else %}
<title>{{ collection.title }} | My Store</title>
{% endif %}
It’s simple once you know what to look for, but until then it’s invisible attrition to your rankings.
2. Screaming Frog misses some soft-302 meta redirect chains
I love Screaming Frog but it’ll quietly skip over some weird meta-refresh or JavaScript-based redirect bloopers that CMS plugins sometimes inject. On one site running some legacy Magento plugin for localized language switching, it added a <meta http-equiv="refresh"> tag that triggered a redirect AFTER the DOM load. Screaming Frog didn’t flag the redirect at all—because technically the server sent 200.
The duplicate description problem here? All localized pages had identical titles and descriptions, but were technically on different subfolders and language codes. And because the redirect was client-side, the Search Console report bundled all impressions into just one URL while showing crawl anomalies elsewhere. That took me two weeks to unravel.
Lesson: Run JS rendering AND plain HTML crawls. Compare differences by export. I now diff them weekly because of this nonsense.
3. Google Search Console deduplicates content guesses too aggressively
I once had a tech specs page per product—literally just 3–5 bullets of detailed SKU-level info—but shared the same H1, meta title, and description across them. Probably lazy. After an index purge, GSC started dropping all but one from index, saying they were duplicates. Their threshold is wild: even if the page content is 90% different, if the head section repeats too closely, they assume you’re spamming the index.
What fixed it? Not even content changes. Moving from identical meta titles to including precise model names made all the difference. The canonical tags were set right the entire time, but Google doesn’t always respect canonicals when it thinks content is too thin or templated.
Quick Aha:
meta name="description" content="Specs for [MODEL-NAME] with unique chipset, RAM and warranty info."
Adding references to SKU or product lines directly into the title and meta was enough to reverse the de-duped index loss, even with 90% similar body HTML.
4. CMS-based templating engines love to ignore conditional logic
One time in Craft CMS I set up dynamic meta title inheritance, thinking it would fallback from the page level to section level to site default. But their native conditional engine short-circuits if the variable is set—even if blank. So if your entry has an empty string explicitly stored, it won’t fallback. You’ll just output an empty <title>.
Fun thing about that? Google won’t use your fallback either. You’ll get “Untitled” in their index preview and your brand gets obliterated for weeks. And no, there’s no warning from Craft about this unless you explicitly test edge case data entries.
Best fix so far was a nasty looking if-else chain that checks for string length instead of existence.
Check your CMS logic. Some of them are dumber than they look.
5. Meta descriptions get rewritten unless you leave them oddly specific
I’ve fallen into the trap of writing “perfect” meta descriptions, only to get half of them ignored by Google. Turns out if you use boilerplate-y phrases like “Browse our selection of…” or “Learn more about our services,” the algo ignores them and tries to generate its own from content blocks.
My working theory: Google prefers pulling from body content when the description lacks precise nouns or matching query terms. So a generic sentence packed with fluff verbs triggers a rewrite.
What started working instead:
Numerical data with units (“150cm hardwood ladder with steel joints”)
Location constraints (“serving Brooklyn, Manhattan, and Queens only”)
Error codes or part numbers (“fixing HTTP 502 errors in nginx.conf”)
Long-tail modifiers (“non-toxic vegan dish soap for sensitive skin”)
Any mention of specific input/output (“uploads CSV returns JSON summary”)
Once I started writing them the way a user might phrase their real query, rewrites dropped off dramatically. Maybe 60–70% get respected now versus 20% before.
6. Internal canonical loops from faceted filters in ecommerce sites
I had a faceted navigation system that was supposed to add rel=canonical to the base product list page, no matter which filters were applied. Of course, some dev “optimized” it in a sprint and made the canonical point back to the current URL. So the canonical for /shirts?size=XL&color=red was… itself.
That made every filter combo get indexed independently. Around 300K URLs indexed for what should have been like 300 categories. Googlebot choked on it and started hitting our cached pages at weird intervals. Worst part? This isn’t flagged in most CMS platforms—your template passes validation just fine even if the canonical references self inappropriately.
Signs you have this issue:
Sudden jump in valid-with-warning pages in GSC
Massive increase in crawl frequency without traffic gain
Google picking random filter variants as preferred URL
Low coverage for core category URLs
Fix: Emit a hard-coded canonical against the base category page unless filters are designed as indexable landing pages. If you must allow some filter combos for SEO, whitelist them.
7. Browser extensions sometimes inject duplicate meta without warning
This one drove me nuts. On my own browser, I would view a site and everything looked clean in DevTools. But GSC still showed multiple <meta name="description"> tags per page. It turned out the Grammarly and a heatmap plugin were both injecting shadow DOM segments into the, and somehow overwriting meta info that bots pick up.
And no, it wasn’t visible unless I opened the source using curl or ran pages through a third-party fetcher like https://web-sniffer.net. Don’t trust your eyeballs in Chrome if you have extensions running—it’s not a faithful render of what bots see.
Real fix: Always check with curl or a remote fetcher. Example:
That’s when I realized I was debugging my own browser spoofs for four hours. RIP Tuesday.
8. Meta fields stored in CMS plugins sometimes truncate silently
My site had a bunch of titles cutting off mid-sentence. Turns out, the SEO plugin (was using a non-mainstream WordPress plugin—not Yoast) had a hard 60-character limit for meta titles, but didn’t warn on save. So you’d write “How to fix SSL handshake failures on Apache behind Cloudflare” and it’d save “How to fix SSL handshake failures on Apache” without any notice.
Flaw: Inline editors never validated or showed the char count. Unlike Yoast or RankMath which at least show a preview, this one just silently chopped after a point.
Always test saved output on the front-end using curl -i https://yoursite.com or DevTools > Network tab > Response tab. Just viewing the HTML inside the WordPress backend is not enough. You’re touching a meta-data interface that’s dumb outside the UI context.
