rel=canonical is a hint, not a directive — Google overrides it whenever its own duplicate clustering disagrees, and "Duplicate, Google chose different canonical than user" in Search Console is the receipt. The eight cases below cover nearly every canonical bug I've had to fix. The one-line summary: be byte-consistent everywhere, never point a canonical at a redirect or a noindexed page, and remember that canonicals consolidate signals while noindex destroys them.
1. Trailing slashes and case
/page, /page/, and /Page are three different URLs. Pick one form, 301 the others at the edge, and use the chosen form in every internal link, sitemap entry, and canonical tag — to the byte. The subtle failure is voting against yourself: internal links saying /app/jellyfin while the canonical says /app/jellyfin/ gives Google two ballots for two candidates, and it may elect the one you didn't want. This site standardises on trailing slashes; the choice matters less than the uniformity.
2. Tracking parameters
?utm_source=newsletter creates a duplicate of every URL it touches. A self-referencing canonical on the clean URL handles it — provided the canonical is absolute and genuinely clean. Since Search Console retired the URL Parameters tool in 2022, canonical tags plus consistent internal linking are the whole mechanism; there is no console setting to fall back on. Never link internally with tracking parameters; measure internal campaigns in your analytics events instead.
3. Faceted and filter URLs
?sort=stars&max-ram=512 is where canonicals get misused hardest. If the parameter only reorders or subsets the same items, canonicalise to the unfiltered page. But if a facet captures real standalone demand — "free self-hosted CRM" — canonicalising it away throws away a rankable intent; give it a real, crawlable page with its own content instead. The diagnostic workflow for telling those cases apart at scale is in duplicate content: diagnosis before medicine.
4. Pagination
Every page in a paginated series canonicalises to itself — page 2 to page 2, never to page 1. Pointing page 2+ at page 1 is the most damaging common bug on large sites: it declares your deep pages duplicates of the first page, and everything discoverable only through them loses its crawl path. rel=prev/next has been retired since 2019, so self-canonical paginated pages plus real links between them is the entire correct implementation.
5. Host and protocol variants
http://, https://, www, and bare-domain versions of the site are a redirect job, not a canonical job. Handle them with 301s at the server or CDN so that exactly one origin ever returns 200. Using canonical tags to patch over a live http + https split leaves both origins serving content and asks Google to sort it out — it usually will, but "usually" is doing load-bearing work in that sentence.
6. Cross-domain syndication
Since Google's 2023 guidance change, canonical tags are no longer the recommended fix for syndicated copies — if you don't want the copy ranking, the copy should carry noindex. If a partner republishing your work won't add it, expect to occasionally be outranked by your own article; publishing first and requiring a dofollow link back is the practical mitigation. A cross-domain canonical remains legitimate where you control both domains and one is the true home.
7. Canonical plus noindex on the same page
The two tags contradict each other: canonical says "I am that page over there", noindex says "drop me entirely" — and Google's crawl team has warned for years that the noindex can effectively bleed onto the canonical target when signals get consolidated. Decide what you mean. Duplicate you want consolidated: canonical alone. Page you want gone: noindex alone (or better, 404/410).
8. Canonical pointing at a redirect or dead page
The canonical target must return 200, be indexable, and self-canonicalise. Chains like "A canonicals to B, B 301s to C" get resolved eventually, but each hop is a chance for Google to give up and choose its own canonical. These accumulate silently after restructures — which is why rewriting canonicals to final destination URLs belongs on every migration checklist, same pass as the redirect map.
The reference card
| # | Case | Rule |
|---|---|---|
| 1 | Slash and case variants | One form, 301 the rest, byte-consistent everywhere |
| 2 | Tracking params | Self-canonical on the clean URL; never link with params |
| 3 | Facets | Canonicalise reorderings; real pages for real demand |
| 4 | Pagination | Every page self-canonical, never to page 1 |
| 5 | Host/protocol | 301s, not canonicals |
| 6 | Syndication | Copy gets noindex; canonical only within your own domains |
| 7 | Canonical + noindex | Never both — pick the intent |
| 8 | Redirecting target | Targets must be 200, indexable, self-canonical |
Seeing what Google actually chose
The URL Inspection tool shows both the user-declared and Google-selected canonical for any URL — when they differ, Google is telling you your signals disagree somewhere in cases 1–8. At scale, watch the "Duplicate, Google chose different canonical than user" bucket in the Pages report; a rising count under one URL pattern almost always traces to a template bug rather than 500 individual accidents, the same pattern-level logic described in why Google ignores 40,000 pages.
What I'd do
Encode the rules as build-time assertions rather than audit findings: every canonical absolute, every target 200 and self-canonical, every sitemap URL matching its page's canonical exactly, no page carrying both canonical-away and noindex. That's a 30-line script on a static site, it runs on every deploy, and it converts this whole class of bug from "discovered in Search Console three weeks later" to "build failed, fixed in ten minutes."