Canonicalization edge cases

The rule when signals disagree

Google decides one canonical per URL from many sources. When they disagree, the resolution is not "who is louder", it is a sequence with a clear decision order:

1. sitemap has no weight on its own for canonical resolution; it nominates a URL, and the robots, meta and header signals act on it.
2. HTTP Link rel=canonical and <link rel="canonical"> in the body are the strongest site signals.
3. internal links to the page carry weight, especially to one URL over another.
4. redirects present a move: a 301 wins by directing both to one place.
5. external links and URLs in use tip the balance for the URL humans and machines already see.

A common misunderstanding: a page's rel=canonical does not guarantee the search engine will *use* it. If the body says canonical: /product/red/ but every internal link goes to /product/red?color=red, and the sitemap lists the parameter URL, the evidence is split and Google may consolidate to the linked URL anyway. So a canonical is a statement you must repeat consistently, not a command.

Trailing slash, www and case

Small URL deltas create their own duplicate families:

• Trailing slash vs non-slash (/about/ vs /about). Pick one, redirect the other, and make internal links honor it. They can be treated as separate URLs, and a sitemap that mixes both sends mixed signals.
• www vs non-www should be an HTTP 301 at the server, not a canonical race. The www vs non-www article is the full recipe.
• Case sensitivity: /Product/ vs /product/ requests can resolve differently. Canonical headers should be added only after you normalize case server-side, or the canonical set duplicates.

The pattern that keeps all three tidy: normalize in one place (the .htaccess / config or the CMS's URL rewrite) and let the canonical stay a hint, not the fix.

Query parameters and faceted pages

?utm_ and ?sort= produce duplicates without a canonical. The modern approach is the faceted nav canonicals: choose a canonical logic (strip tracking, self-canonical for the primary facet combination, noindex for unhelpful combos) and emit a single rel=canonical per rendered URL.

Watch for the canonical-in-a-parameter trap: /?p=1 canonicalizing to / (homepage) while the paginated page has unique content. That pattern hides content; the pagination article is the specific fix.

Pagination and canonicals that fight

Pagination is where canonicals go wrong in a signature way. Google no longer uses rel=prev/next at all (confirmed 2019), and it relies on the URL and links. The edge cases:

• Self-canonical on every page (?page=2 canonical -> itself) is correct and common.
• All pages canonicalizing to page 1 is wrong: it tells Google pages 2+ are duplicates and suppresses them, the classic disappearing-pages bug.
• "Load more" and infinite scroll need a crawlable fallback. If the second page returns no crawlable content, canonicalizing to page 1 kills it; better to keep real <a href> links and self-canonicals. The paginated content article has the full matrix.

Hreflang interacting with canonical

When you have language or region variants, hreflang and canonical can conflict if they disagree:

• Keep the canonical and hreflang groups consistent: if page A canonicals to page B, the hreflang cluster should list B, not A alone.
• x-default, self-references and reciprocity on every variant; the hreflang basics article spells the cluster rules.
• A conflicting set (A canonical->B, but hreflang includes A/B/C piecemeal) suppresses both signals for those pages.

Diagnose, then fix

1. List identical-looking URLs from your analytics/sitemap unsorted by name, and dedupe by path+host with and without params.
2. Check which of them return HTTP 200 vs 301: if both /about/ and /about return 200 with different canonicals, that is a redirect deficiency, not a canonical one.
3. Test each page's declared canonical with curl -I and the URL inspection "test live URL", see URL inspection.
4. Audit the crawl to confirm the target of each canonical returns 200 and a self-consistent canonical itself.

The canonical maintenance and redirect map pages handle whether the right shape is a 301 or a canonical; in short, 301 for "this URL should stop existing", canonical for "this content exists once, pick the address".

Prevention

Keep the canonical decided at build/slug time, not patched after: the slug IS the canonical, the redirect masks the old, and no page carries a canonical to a URL that itself 404s. Every deployment runs a crawl-diff that flags a page whose canonical target changed, which the indexing analysis loop enforces.