Canonical Tags: The Small Tag That Causes the Most SEO Damage
The canonical tag is one line of HTML, and it causes more accidental damage than almost anything else I see in technical SEO reviews. Not because the concept is hard — it’s genuinely simple — but because it’s easy to implement it in a way that quietly tells Google to ignore the exact page you’re trying to rank.
What a canonical tag is actually for
Google’s documentation frames the underlying problem clearly: when Google finds multiple URLs with the same or very similar content, it clusters them together and picks one version to treat as canonical — the one it considers “objectively the most complete and useful for search users.” Google decides this using a mix of signals: whether a page is served over HTTPS, whether it’s included in your XML sitemap, redirect relationships between URLs, and your declared rel="canonical" annotation.
The critical detail almost everyone misses: Google’s own documentation describes your declared canonical as a hint, not a rule. You can tell Google which URL you consider canonical, and Google can still choose a different one if its own signals point elsewhere. This isn’t a bug in the system — it’s the system working as designed. Google explicitly reserves the right to override your choice when it determines a different duplicate is “explicitly better suited for a search user,” such as serving a mobile-optimized URL to mobile searchers even if your tag names the desktop version as canonical.
The mistakes that actually cause damage
Every one of these shows up regularly in real WordPress sites, and each one is a case of the tag technically existing but not actually doing its job:
- Canonical tag placed outside the
<head>. Google’s parsing expects it in the document head. A canonical tag injected into the body — sometimes by a theme or plugin conflict — gets ignored outright. - Multiple conflicting canonical tags on one page. This happens more than you’d expect on WordPress, usually when an SEO plugin and a theme, or two plugins, both try to set the tag. When Google sees more than one canonical declaration, it either disregards all of them or picks one arbitrarily — neither outcome is one you chose.
- Canonical pointing at a URL that no longer resolves cleanly — a 404, a redirect chain, or a URL that itself redirects elsewhere. A canonical should point directly at the final, working version of the page, not at something that requires Google to do more work to resolve it.
- Blocking the non-canonical duplicate via robots.txt. This one is counterintuitive but important: if Google can’t crawl a duplicate URL at all, it can’t see the canonical signal on that page, and can’t properly consolidate it with the version you want ranked. Canonicalization requires Google to crawl both versions, not just the one you prefer.
- Canonicals injected only via JavaScript, invisible in the raw HTML response. Depending on when and how Google renders the page, a JS-injected canonical can be missed or seen inconsistently.
A canonical tag that Google can’t parse, sees duplicated, or can’t reach isn’t a weaker signal — it’s effectively no signal at all.
Why “self-referencing” isn’t optional
Every unique page should carry a canonical tag pointing at itself, not just pages you suspect have duplicates. This is standard, low-risk practice specifically because it removes ambiguity: if a URL parameter, tracking tag, or unexpected duplicate ever gets created for that page later — by a faceted navigation filter, a UTM-tagged share link, or a staging URL that accidentally got indexed — the self-referencing canonical already tells Google exactly which version matters, before the problem ever becomes visible in your traffic.
How this plays out on a typical WordPress site
The most common real-world source of canonical chaos I see isn’t a manual mistake — it’s WordPress’s own URL flexibility working against you. Pagination, search result pages, tag archives that largely duplicate category archives, and WooCommerce’s parameter-heavy filtered product URLs all generate multiple URLs that can serve near-identical content. A well-configured SEO plugin handles most of this automatically by setting sensible defaults, but it’s worth actually checking rather than assuming:
- Spot-check your canonical tags directly in page source on a sample of posts, category pages, and any filtered or paginated URLs — don’t just trust that a plugin is handling it correctly.
- In Search Console’s Page Indexing report, look specifically for “Duplicate, Google chose different canonical than user” — that status is Google telling you directly it disagreed with your declared preference, and it’s worth investigating why.
- If you’re running any kind of faceted filtering (WooCommerce attribute filters, for example), verify the filtered URLs canonicalize back to the clean unfiltered version rather than each combination trying to self-canonicalize.
A quick way to sanity-check an entire site at once
Rather than spot-checking pages one at a time, a full-site crawl exported to a spreadsheet with each URL’s declared canonical next to it is the fastest way to catch systemic problems — sort for pages whose canonical points somewhere other than themselves, then verify each one is intentional rather than accidental. Patterns worth flagging immediately: canonicals pointing to a staging or development domain that leaked into production, canonicals pointing to the homepage across a large batch of unrelated pages (often a plugin misconfiguration rather than a deliberate choice), and pages with no canonical tag output at all, which usually indicates the tag isn’t rendering rather than that it was deliberately omitted.
Canonical tags don’t need to be complicated to work correctly. They need to be consistent, singular per page, pointed at something that actually resolves, and visible to a crawler without requiring JavaScript execution. Get those basics right and the tag does exactly the quiet, unglamorous job it’s meant to do — most of the damage I see comes from one of those basics quietly failing, not from the concept being misunderstood.
Google Shopping, ChatGPT Checkout, and the New Product-Feed SEO
OpenAI's in-chat checkout converted at a third of normal click-through rates. Here's the real state of AI shopping, not the launch-day hype.
Read the post
Semantic Search and Embeddings, Explained for SEOs
AI Overviews didn't invent semantic search. RankBrain, BERT, and MUM already moved Google past keyword matching. Here's the real lineage.
Read the post
Caching Plugins and Core Web Vitals on WordPress: What Actually Moves the Needle
Caching plugin benchmarks are almost all vendor-claimed, not independently verified. Here's what WordPress core itself has actually shipped for speed.
Read the post