How does Google truly select the canonical URL for your pages?

Why doesn’t Google always follow the canonical tag?

The canonical tag is often seen as an absolute directive. This is a mistake. Google treats it as a signal among others, not as a command.

If your 301 redirects point to URL A, your sitemap refers to URL B, and your internal links lead to URL C, Google has to make a decision. It will weigh these conflicting signals and choose what it believes to be the most coherent. The result: you lose control of the indexed version.

What signals truly matter in this choice?

Google evaluates the overall consistency of your signals. 301/302 redirects carry significant weight: they explicitly indicate which version to prioritize. The internal links reveal which URL you consider as primary in your architecture.

The XML sitemap also plays its part by listing the URLs you deem indexable. Less known: the HTTPS vs HTTP protocol, the presence or absence of trailing slashes, and recurring UTM parameters. Each inconsistency dilutes your signal.

What happens when the signals diverge?

Google applies its own logic, often opaque. It may favor the URL that receives the most external backlinks, or the one it discovered first. Sometimes, it indexes a version with parameters while you intended the clean version.

This decision-making autonomy generates frustrating cases: a non-HTTPS URL indexed despite an active HTTPS redirect, or a paginated page chosen as canonical while you targeted page 1. The engine prioritizes what it deems most relevant for the user, not necessarily for you.

• The canonical tag is just a signal, not an absolute directive.
• 301 redirects, internal links, and sitemaps have major weight in the final choice.
• Google may impose its own canonical URL if your signals are contradictory or absent.
• Architectural inconsistencies (HTTP/HTTPS, trailing slash, parameters) dilute your control.
• The indexed URL may differ from what you defined if Google finds another version to be more relevant.

Does this statement align with field observations?

Yes, generally speaking. SEO audits regularly reveal cases where Google ignores the declared canonical. Typically, an e-commerce site that canonicalizes to product pages without parameters, yet URLs with ?color=blue remain indexed because the sitemap lists them and internal links point to them.

What Mueller doesn’t mention: the relative weight of each signal remains unclear. Google does not publish any weighting scale. [To be verified] regarding complex cases: what priority is there between an HTML canonical and an HTTP header canonical if both exist and differ? The official documentation remains silent.

What nuances should be added?

The term "signals" is intentionally vague. Google never details how many conflicting signals it tolerates before imposing its choice. A site may have 90% of its internal links consistent and still see a minority URL become canonical if it captures the majority of external backlinks.

Another point: the freshness of the signal. A recent 301 redirect may take weeks to be fully recognized if Google has crawled the old URL thousands of times. The propagation delay varies depending on the authority of the site and crawl frequency. Mueller does not mention this latency, which is critical in site migration.

In what cases does this rule not apply?

On single-page or very small sites, Google has few signals to compare. The canonical is often followed by default. But once a site exceeds a few hundred pages with varying URLs (www/non-www, HTTPS/HTTP, trailing slash), inconsistencies explode.

Special case: international sites with hreflang. If your hreflang tags point to different URLs than your canonicals, Google may bypass the canonical to maintain linguistic consistency. This scenario creates conflicts that Mueller does not mention here but are documented elsewhere.

What should you do to control the canonical URL?

Your first reflex: audit all signals on a representative sample of URLs. Check that your XML sitemap lists only the desired canonical versions. Eliminate URLs with tracking parameters, inconsistent trailing slashes, or mixed HTTP/HTTPS protocols.

Next, scrutinize your internal linking. A crawler like Screaming Frog quickly reveals if your internal links massively point to non-canonical URLs. Correct these links: each internal link to the wrong version dilutes the signal you send to Google.

What mistakes should be absolutely avoided?

Never declare a canonical to a URL that returns a 404 or a redirect. Google will interpret this as a conflicting signal and make its own choice, often unpredictable. The same logic applies to chained canonicals (A canonizes to B, B to C): Google may stop at B or completely ignore the chain.

Another classic mistake: defining a canonical in the HTML but sending a differing HTTP canonical header. Google generally prioritizes the HTTP header but not always. This inconsistency creates a gray area you want to avoid. Choose one method and stick to it.

How can you verify that Google understood your choice?

Use Google Search Console, under the "Coverage" or "Page Indexing" section. It indicates which URL Google has retained as canonical for each indexed page. If the displayed URL differs from what you declared, your signals are contradictory.

Supplement this with a site:yourdomain.com for critical URLs. If the indexed version does not match your canonical, dig deeper: server logs to identify which version Googlebot crawls the most, backlink analysis to see which URL receives the most external juice. These diagnostics reveal where the signal diverges.

• Audit the XML sitemap: only list the desired canonical URLs, without parameters or variants.
• Correct the internal linking to exclusively point to canonical versions.
• Align 301/302 redirects, HTML canonical tags, and HTTP headers to the same target URL.
• Check in Search Console that Google is indeed indexing the declared canonical URLs.
• Eliminate chained canonicals or those pointing to error URLs (404, 301).
• Monitor external backlinks: if a non-canonical URL captures too many links, redirect it with a 301.