What the tag is and where it goes
One line, in the head of the HTML, before anything else has a chance to break it:
link rel="canonical" href="https://example.com/the-real-page"
It says: several addresses may serve this content, and this is the one I want indexed. Google then attributes the links, the content signals and the ranking to that address rather than splitting them across duplicates.
Two rules about placement that account for a large share of failures. It must be in the head, not the body — a canonical injected into the body by a script or a page builder is ignored, and a stray unclosed tag earlier in the head can push it into the body without you noticing. And the URL should be absolute, including the protocol and host, not /the-real-page.
For non-HTML files — PDFs, images, downloads — there's no head to put it in, so it goes in the HTTP response as a Link header instead. Same effect, different plumbing.
When you actually need one
Canonicals earn their place when the same or near-identical content genuinely has to live at more than one address. Most sites generate these accidentally, at scale, without anyone deciding to.
- Tracking and campaign parameters.
?utm_source=newslettercreates a distinct URL serving identical content. Every email you send makes more. - Faceted navigation and filters.
?colour=blue&size=mon an ecommerce category, where the underlying product set barely changes. - Sort orders and views.
?sort=price-asc, print stylesheets, AMP variants,/page/2archives that repeat their intro. - HTTP vs HTTPS and www vs non-www. Four possible addresses for a homepage if the server doesn't redirect properly.
- Trailing slashes and case.
/services/and/servicesand/Servicesare three URLs to a crawler. - Syndicated content. You publish an article, a partner republishes it. A cross-domain canonical on their copy points back at yours.
Why Google treats it as a hint
This is the part that trips up everyone who has read the documentation once. Google's own guidance describes rel=canonical as a signal it considers, not an instruction it obeys. There's a defensible reason: canonical tags are wrong constantly.
Templates emit them in bulk. Plugins guess. Migrations leave the old domain in the href. A single bad rule can point ten thousand URLs at a homepage. If Google obeyed every canonical without checking, one bad deploy would remove entire sites from the index — and a fair number of people would deliberately canonicalise a competitor's content to themselves.
So Google collects the evidence. Your canonical tag is one piece. Redirects are a stronger piece. Internal links, sitemap inclusion, hreflang annotations, HTTPS preference and which URL is shorter and cleaner are all pieces. Then it selects a canonical and tells you what it chose. When your tag and your behaviour disagree, behaviour wins.
Five signal conflicts that make Google overrule you
If URL Inspection shows a Google-selected canonical different from your declared one, it's nearly always one of these five. Work down the list.
- Not conflicts — plain bugs that break the tag entirely: multiple canonical tags on one page (Google ignores all of them), the tag rendered in the
body, a relative URL, and a canonical injected by client-side JavaScript that contradicts one already in the raw HTML.
- Your internal links point at the other URL. You canonicalise A to B, then link to A from your navigation, your breadcrumbs and forty blog posts. Google counts the votes. Fix the links, not the tag.
- Your sitemap lists the non-canonical URL. Sitemap inclusion is itself a canonicalisation signal. Listing both versions, or listing only the duplicate, contradicts the tag directly. Sitemaps should contain canonical URLs and nothing else.
- The pages aren't actually duplicates. If A and B differ substantially, consolidating loses content, so Google declines. This is the most common cause on content sites and the one people misdiagnose as a bug.
- The canonical target has a problem. It 301s somewhere else, it 404s, it carries a noindex, or it canonicalises onward to a third URL. A canonical chain is broken by definition and Google resolves it however it likes.
- Protocol, host or slash mismatch. Your canonical says
http://, your site serveshttps://. Or it sayswwwand every link says non-www. Or the trailing slash differs from what the server returns. Google prefers the version it consistently observes.
Canonical vs redirect vs noindex
Three tools that all remove a URL from competition, in three different ways, with three different consequences for your existing rankings. Picking the wrong one is how people lose traffic while tidying up.
| Tool | What happens to the user | What happens to signals | Use it when |
|---|---|---|---|
| 301 redirect | Sent to the other URL. The old one is unreachable. | Consolidated onto the target. Strongest and least ambiguous. | The old URL should not exist any more. |
| rel=canonical | Nothing. Both URLs still load normally. | Consolidated onto the target — if Google agrees. | Both URLs must stay usable: parameters, filters, print views, syndication. |
| noindex | Nothing. The page loads and works. | Dropped. Nothing is passed anywhere. | Users need the page, search never should: thank-you pages, internal search results, thin filter views. |
Self-referencing canonicals, and why they're worth the trouble
A self-referencing canonical is a page pointing at itself. Google has said it isn't strictly required, and technically that's true. It's still the cheapest insurance in technical SEO.
The reason is parameters. The moment someone shares your page with ?fbclid= or ?utm_campaign= attached, that address exists and gets crawled. With a self-referencing canonical in the template, every one of those variants resolves back to the clean URL automatically, without you maintaining a parameter list forever.
Three implementation rules. Absolute URLs. Matching exactly what the server serves — same protocol, same host, same trailing-slash convention. And generated dynamically from the canonical route, not from the requested URL, or the tag will helpfully canonicalise the parameter version to itself and defeat the whole point.
One exception worth knowing: paginated series. Pages 2 and beyond of an archive should self-canonicalise, not point at page 1. Google retired rel=next/rel=prev support, and canonicalising deep pages to the first one hides the products or articles that only appear there.
How to check what Google actually chose
Never assume the tag worked. Verify it, per URL, in Search Console.
Paste the URL into URL Inspection and read two fields: User-declared canonical — what your tag says — and Google-selected canonical — what Google decided. If they match, you're done. If they don't, you have one of the five conflicts above, and the selected URL usually tells you which.
At scale, the Pages report groups the same information. "Alternate page with proper canonical tag" means everything is working as designed. "Duplicate, Google chose different canonical than user" means you've been overruled. "Duplicate without user-selected canonical" means there's no tag at all and Google picked for you. If a whole content type shows the second or third status, it's a template problem, not a page problem — and it's often the reason a page isn't indexed at all.