Canonical Tags: The Rules Most Sites Get Wrong
A canonical tag is a strong hint, not a directive, and Google overrides it when the signals around it disagree. The five rules that keep it working, and the mistakes that break it.
A canonical tag is Google’s strong hint for which URL to index and rank when several versions of a page could compete for the same slot, but it is a hint, not a directive: Google overrides it whenever the other signals on your site disagree with what the tag says. That gap between “hint” and “instruction” is where most canonical tag problems start, and fixing it comes down to five specific rules rather than a vague sense of “add a canonical tag to everything.”
Sites that get this wrong usually have a canonical tag present on every page and still see the wrong URL indexed. The tag was never broken. The signals around it — the sitemap, the internal links, a stray redirect — were telling Google something different, and Google believed the majority.
What does a canonical tag actually do?
A canonical tag, written as <link rel="canonical" href="..."> in the page’s <head>, tells Google which URL in a set of duplicate or near-duplicate pages should be treated as the primary one for indexing and ranking. Product pages reachable through five different filter combinations, an HTTPS and HTTP version of the same page left live, or a print-friendly version of an article are all cases where a canonical tag consolidates signals — links, relevance, freshness — onto a single URL instead of splitting them across several.
Google’s own documentation calls rel=”canonical” annotations “a strong signal,” not a directive. In practice that means the tag competes with every other signal on the page. When they agree, the canonical works exactly as intended. When they disagree, Google’s algorithms pick a winner, and it isn’t always the URL named in the tag.
How do you implement a canonical tag correctly?
There are three valid methods, and which one applies depends on the file type and the CMS:
| Method | Where it’s used | Notes |
|---|---|---|
| HTML link tag | Standard web pages | Most common. Must sit in the <head>, not the <body>. |
| HTTP header | Non-HTML files (PDFs, images) | Set via Link: <url>; rel="canonical" in the server response. |
| XML sitemap | Site-wide hint | A weaker, secondary signal. Never a substitute for the on-page tag. |
For a standard WordPress or headless CMS page, the HTML link tag is the one that matters. Most SEO plugins generate it automatically, but automatic generation is exactly where the five rules below tend to break, usually silently.
What five rules keep a canonical tag working?
These are the conditions Google’s own guidance and independent crawl audits agree on. Break any one and the canonical tag becomes a suggestion Google is free to disregard.
Five rules that keep canonical tags working
- One tag per page — Max 1. A second rel=canonical in the head makes Google ignore both.
- Absolute, not relative URLs — Required. Full https:// path, exact casing, exact trailing slash.
- Points to a 200 status page — 200 OK. Never to a redirect, a 404, or a noindexed URL.
- Self-referencing by default — Default. Every indexable page canonicals to itself unless it’s a true duplicate.
- Matches sitemap and internal links — Consistent. Conflicting signals are the top reason Google overrides a canonical.
The fifth rule causes the most damage because it’s invisible in a single-page view. A page can look perfect in “view source” and still lose the canonicalisation fight because the XML sitemap lists a parameterised version, or forty internal links across the site point to a URL with a trailing slash the canonical tag doesn’t use.
What mistakes make Google ignore a canonical tag?
- Canonicalising to a redirecting URL. If the canonical target itself 301s somewhere else, Google has to resolve a chain, and it frequently indexes neither URL as intended.
- Canonicalising to a noindexed page. This sends a direct contradiction: “index this instead” pointing at a page marked “don’t index me.”
- Mixing relative and absolute paths sitewide. Templates that render
/product/123/in one place andhttps://example.com/product/123in another create URLs that look identical to a human and different to a crawler. - Faceted navigation without a canonicalisation rule. Every filter and sort combination generating its own URL, all “canonicalised” to themselves, produces thousands of near-duplicate pages competing with each other.
- JavaScript-injected canonicals that render inconsistently. If the tag is set via JavaScript, it must match the value in the raw HTML exactly, or Google’s two-pass rendering process sees two different answers.
Canonical tag vs noindex vs redirect: which one to use
These three tools solve different problems, and picking the wrong one is a common source of the mistakes above.
| Situation | Correct tool | Why |
|---|---|---|
| Two URLs, both need to stay live and reachable | Canonical tag | Consolidates ranking signals without removing either URL |
| One URL should stop existing entirely | 301 redirect | Forcefully passes signals and removes the old URL from users’ path |
| A page should never appear in search results, but stay live for users | Noindex | Removes the page from the index while leaving it crawlable and visitable |
A canonical tag and a noindex tag on the same page contradict each other and should never be combined. If a page shouldn’t be indexed, noindex it and drop the canonical tag entirely, or self-canonicalise and leave noindex off.
How do you audit canonical tags at scale?
On a site above a few hundred URLs, checking canonical tags page by page isn’t practical. A crawl with Screaming Frog or a similar crawler, configured to extract the canonical target, the HTTP status of that target, and whether the canonical is self-referencing, surfaces the five failure modes above in one pass. Cross-reference the crawl output against the XML sitemap: any URL in the sitemap that isn’t the canonical target for its own cluster is a conflicting signal worth fixing before the next crawl.
Frequently asked questions
What does a canonical tag actually do?
A canonical tag tells Google which URL among a set of duplicate or near-duplicate pages should be indexed and ranked. Google treats it as a strong hint rather than a command: it consolidates ranking signals like links and relevance onto the canonical URL, but it can and does choose a different URL if other signals on the page disagree with the tag.
Does every page need a self-referencing canonical tag?
Yes. Self-referencing canonicals, where a page points to itself, are standard practice on every indexable URL, not just on pages with duplicates. They remove ambiguity for Google and protect the page against parameter or tracking-tag variants being indexed as separate URLs later.
Why is Google ignoring my canonical tag?
The most common cause is conflicting signals: the sitemap lists a different URL, internal links point to a non-canonical version, or a redirect chain leads somewhere else. Google resolves the conflict by picking the URL the majority of signals agree on, which is frequently not the one in the rel=canonical tag.
Can I use a canonical tag instead of a 301 redirect?
No. A canonical tag is a hint for indexing and ranking; it does not change what users or bots receive when they request the URL, and it does not pass the same clear, forceful consolidation signal a 301 redirect does. Use a canonical when both URLs must stay live and reachable; use a redirect when one URL should stop existing.
Can a canonical tag point to a different domain?
Yes, cross-domain canonicals are valid and Google supports them, most commonly for syndicated content pointing back to the original publisher. Both domains need to be crawlable, and the target URL must return a 200 status, not a redirect or a login wall.
Sources
- How to Specify a Canonical with rel=”canonical” — Google Search Central
- Technical SEO: The Complete Working Guide
- Canonical vs noindex vs Redirect: A Decision Tree
Want this done on your site?
Every PalV’s DM engagement starts with a free audit of your actual website — a 12-point
crawl covering what is blocking indexation, on-page gaps against your primary keywords, speed
findings, and the three to five fixes worth making first. Delivered in two working days. No
payment details, and the findings are yours whether you hire us or not.
