Google states plainly, in its own canonicalization documentation, that rel=canonical is a hint, not a directive. The canonicalization system doesn’t execute your canonical tag as a command; it feeds the tag into a duplicate-clustering process alongside several other observed signals, most importantly actual content similarity across the URLs in question, the pattern of internal links (which URL the site itself links to most and treats as primary through navigation, footer, and contextual links), whether the URL is present in an XML sitemap, redirect chains pointing at or away from the URL, and hreflang cluster consistency. When these signals disagree with the declared rel=canonical, Google can and does select a different URL as canonical, one it judges more consistent with the overall pattern of signals rather than the single tag you set.
Why rel=canonical alone doesn’t decide it
Google’s “Consolidate duplicate URLs” and canonicalization help documentation both describe rel=canonical as one of several signals combined during the deduplication process, explicitly cautioning that Google may choose a different canonical URL than the one specified if other signals point elsewhere. This isn’t a bug tolerance or an edge case; it’s how the system is designed, because rel=canonical is trivially manipulable and often set incorrectly (copy-pasted templates pointing to the wrong URL, staging environments, or paginated series all misconfigured are extremely common in the wild). Google needs an error-correction layer, and that layer is built from signals that are harder to fake or that reflect actual site structure rather than a single declared preference.
The clustering process works roughly like this: Google first groups URLs it considers duplicates or near-duplicates based on content similarity (not identical byte-for-byte content, but substantially the same content once boilerplate, navigation, and parameter noise are stripped out). Within that cluster, it then looks for the URL that best represents the group, using the declared canonical as a strong signal but weighing it against:
Internal linking patterns. If the majority of internal links across the site, including navigation, breadcrumbs, and contextual body links, point to a URL other than the one marked as canonical, that’s read as the site’s own structure disagreeing with its own tag. Google’s documentation on canonicalization explicitly lists consistent internal linking as one of the best ways to reinforce a canonical choice, which implies the inverse: inconsistent internal linking undermines it.
Sitemap inclusion. Google has stated in various Search Central guidance and in John Mueller’s public comments that submitting a URL in an XML sitemap is treated as a signal that the site considers that URL to be the canonical, indexable version. If your sitemap lists URL A but your rel=canonical tags on a set of near-duplicates point to URL B, you’ve created a direct contradiction, and Google resolves it by weighing which signal is more consistent with everything else it observes (internal links, redirects, actual traffic and linking patterns from external sources).
Redirect chains. A URL that other pages 301 redirect toward is a strong signal of intended canonical status, since redirects represent an explicit site-owner decision about which URL should persist. If page A canonicalizes to page B, but a redirect elsewhere on the site sends traffic from B to a third URL C, that’s a structural contradiction the algorithm has to reconcile, and it will tend to favor the URL that redirect chains and links converge on.
Hreflang cluster consistency. Hreflang doesn’t declare canonical status between language/region variants; it’s a separate annotation system telling Google which URL to serve to which locale. But when a set of hreflang-annotated alternates also carry canonical tags that don’t align with the hreflang cluster (for instance, several regional URLs all self-canonicalizing correctly, but one incorrectly canonicalizing to a different region’s URL), that inconsistency signals a technical error and can cause Google to either ignore the errant canonical or exclude that URL from the hreflang cluster, since Google’s hreflang documentation notes that conflicting or unclear canonical signals interfere with correct hreflang processing.
What this means practically
The practical implication is that rel=canonical works best, and is followed most reliably, when it’s the summary of a decision your other signals already agree with, rather than a fix applied against contradicting structure. If you set a canonical tag but internal links, sitemap entries, and redirects all point elsewhere, you’re not giving Google a clear instruction, you’re giving it a dispute to resolve, and it resolves disputes by pattern-matching across the stronger, harder-to-fake signals.
This is diagnostically useful when you see “Google chose different canonical” in Search Console’s Page Indexing report. Rather than assuming the tag itself is broken, check for contradiction across the other four signals: does the sitemap list this URL or a different one; do internal links from category and navigation pages point to this URL consistently; are there redirects anywhere in the chain that point away from your declared canonical; and, for internationalized sites, does the hreflang cluster agree with the canonical choice across every regional variant, not just the one you’re investigating.
Fixing canonical mismatches, then, is rarely a matter of just correcting the tag. It typically requires auditing whether internal linking, sitemap generation, and redirect logic all agree with the tag before assuming Google will honor it, since Google’s own documentation frames rel=canonical as advisory input into a broader signal-weighing process rather than a standalone directive it’s obligated to follow.
