Your rel="canonical" tag is a hint. Google picks the canonical, and when you fight that you tend to lose for reasons that have nothing to do with the canonical tag itself.
This is the single most-misunderstood piece of technical SEO we encounter on client audits. A site has 12 versions of the same product page, each with a rel="canonical" pointing to the "real" URL, and somehow Google keeps indexing the wrong one. The team blames the algorithm. The actual cause is almost always conflicting signals the team did not realize they were sending.
Here is what the Google docs actually say, and how to use it.
The canonical tag is a hint
Per Google's canonicalization documentation: "indicating a canonical preference is a hint, not a rule." Google selects the canonical based on a basket of signals it collects during indexing. rel="canonical" is one input, weighted heavily but never as a hard rule.
> Google's canonical selector chooses the URL it considers most representative of a piece of content from a set of duplicates. Your canonical tag is one of several signals; Google can and does override it when other signals point elsewhere.
The signals Google uses, per the consolidate-duplicate-urls doc, in rough order of weight:
- Redirects: a 301 from URL A to URL B is the strongest possible canonical signal
rel="canonical"link annotations: strong, but not binding- Sitemap inclusion: a weak signal
- HTTPS over HTTP: a default preference, almost always picked
hreflangcluster membership: URLs in a reciprocal hreflang cluster are preferred over URLs outside it- Internal linking consistency: which URL you link to from your own pages
- URL simplicity: given two otherwise equal URLs, the shorter/cleaner one wins
- Popularity: links and search signals from elsewhere
When Google picks a canonical different from yours, one of those signals is overriding your tag. Often it is something silly: you 301 the canonical to a different URL, then rel="canonical" back to the original. Or your sitemap includes the version you said wasn't canonical. Or every internal link points to the duplicate.
The three signals that actually move the picker
For a small business site, you control three signals reliably. Get these three aligned and Google almost always picks the URL you want.
One. The canonical tag itself. Use an absolute URL (https://www.example.com/page, not /page). Put it in the , not the body. Only one canonical per page. Match the protocol, subdomain, and trailing-slash convention exactly to the URL you want indexed.
Two. 301 redirects from every duplicate to the canonical. This is the strongest signal Google accepts. If you can redirect, redirect. Use it for HTTP-to-HTTPS, www-to-non-www, trailing-slash normalization, and old URL retirement.
Three. Internal linking. Every link inside your site that points to the duplicate URL is a vote for the duplicate. Per Google's documentation: "When linking within your site, link to the canonical URL rather than a duplicate URL." Run a crawl of your own site and check. We see this miss constantly: a site canonicals the clean URL but every menu link, footer link, and breadcrumb points to a tracking-parameter version.
When Google picks something different
Even with all three signals lined up, Google sometimes picks a different canonical. Per the troubleshooting doc, use Search Console's URL Inspection tool to see which URL Google considers canonical for a given page. Before you fight it: think about whether Google's choice is actually fine.
If Google canonicaled to the HTTP version of a page where you wanted HTTPS, the cause is almost always one of these:
- The HTTPS page has an invalid or mismatched SSL certificate
- The HTTPS page loads insecure dependencies (HTTP scripts, HTTP iframes)
- The HTTPS page redirects through HTTP somewhere in the chain
- The HTTPS page has a canonical pointing to the HTTP page (this happens; it is usually a CMS bug)
If Google canonicaled to a different language variant: your hreflang cluster is incomplete. The de-DE page reciprocally points to de-CH; both prefer themselves over de-AT, which sits outside the cluster.
If Google canonicaled across domains to a copycat: someone is scraping you and Google's freshness signals favored the scraper, so file a DMCA. The troubleshooting doc covers this case directly.
If Google canonicaled to a hacked URL: you have been hacked. A common attack injects a cross-domain rel="canonical" into the head, redirecting your authority elsewhere. Check your server-rendered HTML for unexpected canonical tags and audit recent file changes.
Canonical vs noindex vs robots.txt
These are not interchangeable. We see them confused on almost every audit.
rel="canonical": "this is a duplicate; consolidate signals to the canonical." Google still crawls; the duplicate stays out of the index but does not block other Google systems.noindex: "do not show this in Search at all." Google still crawls (to see the noindex), then drops the page from the index entirely. Use this for pages users need but Search does not (thank-you pages, internal search results).- robots.txt disallow: "do not crawl this." Google cannot read the page or follow links from it. The URL may still appear in Search results (without a snippet) if other sites link to it.
The decision tree we walk clients through:
- Page is a near-duplicate of another canonical URL →
rel="canonical" - Page has unique content but should not appear in Search →
noindex - Page should not be crawled at all (faceted nav with millions of combinations, admin pages, internal tools) → robots.txt disallow
Per Google's docs, do not use noindex for canonicalization. It removes the page entirely; it does not consolidate signals to another URL.
Per Google's docs, do not use robots.txt for canonicalization. Google may still index the blocked URL (without content) if other signals point to it.
The bugs that quietly destroy canonicals
A short list from real audits:
The protocol mismatch. Your canonical reads http://www.example.com/page but the page lives at https://www.example.com/page. Google now has to pick. Often picks the HTTP version, then your HTTPS page disappears from Search.
The paginated canonical. Page 2 of a listing canonicals to page 1. Google indexes page 1, but cannot find the items that only appeared on page 2. Per Google guidance, each paginated chunk should self-canonical and link sequentially.
The CMS-injected duplicate canonical. Two rel="canonical" tags on the same page, pointing to different URLs. Common with WordPress + an SEO plugin that does not respect a theme's existing canonical. Google picks one, but which one depends on parse order and is not your problem to control.
The JavaScript-injected canonical that conflicts with the server HTML. Per Martin Splitt on Search Off the Record episode 105: Google advises against this directly. Either render the canonical from the server, or render it only in JavaScript, never both.
The noindex, follow page with a canonical. When Google sees noindex, it may stop rendering and stop processing meta tags. Your canonical may not be read at all. If you noindex a page, do not bother canonicalizing it.
The fragment canonical. https://example.com/page#section. Google does not support URL fragments as canonicals, so the page will be canonicaled to https://example.com/page regardless of the fragment you specify.
When site moves and canonicals collide
Per Lizzi Sassman, John Mueller, and Gary Illyes on Search Off the Record episode 56: most "lost traffic after a site move" cases trace back to redirect misconfigurations that conflict with canonical signals. The pattern Gary called out: redirects that fire for users but not for Googlebot. The user sees the new site; Googlebot sees the old one. Canonical signals on the new site point to URLs that, from Googlebot's perspective, do not redirect properly. The whole signal map breaks.
If you are moving a site: keep a URL map. Test redirects from a Googlebot user-agent (or use Search Console's URL Inspection on representative URLs). Wait roughly a year before concluding the move failed. Google's recovery timeline is real and you cannot rush it.
The short version
rel="canonical" is a hint. Three signals do most of the work: the canonical tag itself, 301 redirects, and consistent internal linking. Google will sometimes overrule you, and when it does, the cause is almost always findable in the troubleshooting guide. Pick one signal type per case, and don't mix canonicals with noindex, block with robots.txt and canonicalize, or inject conflicting tags from JavaScript.
Once every signal you control points at the same URL, Google usually follows.
Sources
- What is URL Canonicalization (Google Search Central, December 2025)
- How to specify a canonical URL (Google Search Central, March 2026)
- Fix canonicalization issues (Google Search Central, December 2025)
- Site moves: Are they getting any easier?, Search Off the Record episode 56 (Gary Illyes, John Mueller, Lizzi Sassman)
- How Browsers Really Parse HTML, Search Off the Record episode 105 (Gary Illyes and Martin Splitt)