Canonical Tags and Canonicalisation
Last updated
A canonical tag tells search engines which URL is the preferred version when multiple URLs serve substantially the same content. It goes in the <head> of every page and looks like this:
<link rel="canonical" href="https://example.com/preferred-url/" />Every indexable page on a site should have one. Most will be self-referential, pointing back to themselves. A smaller number will be cross-referential, pointing to a different URL that should receive the ranking signals.
For non-HTML files such as PDFs, where a <head> is not available, the same signal can be sent via an HTTP Link response header:
Link: <https://example.com/preferred-url/>; rel="canonical"Self-referential canonicals
A self-referential canonical points back to the page it sits on. This is the correct default for every indexable page on a site, including those with no known duplicates.
The reason: URLs are rarely as stable as they appear. Tracking parameters, session IDs, print variants, and CDN variations can all cause the same page to be served at multiple URLs without any deliberate duplication. A self-referential canonical on every page removes that ambiguity before Google has to guess.
<!-- On https://example.com/about/ -->
<link rel="canonical" href="https://example.com/about/" />Cross-referential canonicals
A cross-referential canonical points to a different URL, consolidating signals on that URL instead. Use this when:
- Parameter-based duplicates exist. Faceted navigation, sorting, and filtering often generate URLs that serve the same or near-identical content. Canonicalise the parameter variants to the clean base URL.
- Print or alternative format versions exist. If a print-friendly version lives at a separate URL, canonicalise it to the standard version.
<!-- On https://example.com/product/?colour=blue&sort=price -->
<link rel="canonical" href="https://example.com/product/" />When NOT to use canonicals
To merge pages with different content. Canonicals are for URL variants of the same content. Using one to merge two genuinely different pages is likely to be ignored or to produce unpredictable results.
As a substitute for noindex. If you want a page excluded from search results, use noindex. A canonical pointing to a different page does not guarantee the source page will be excluded.
To fix thin content. A canonical on a thin page hides the symptom; it does not address the content problem. If a page is thin, the right fix is to improve or consolidate it, not canonicalise it away.
For robots.txt or URL removal purposes. These tools serve different functions. Robots.txt controls crawling; URL removal tools handle emergency deindexation. Neither is a canonicalisation method.
For syndicated content. Cross-domain canonicals are not Google’s recommended approach when your content is republished on other sites. The preferred approach is for syndication partners to block indexing of the republished version rather than set a cross-domain canonical pointing to your original.1
How does Google select the canonical?
Google treats rel="canonical" as a strong hint, not a directive. It weighs multiple signals when choosing which URL to treat as canonical:2
| Signal | Weight |
|---|---|
| 301 redirect | Strongest |
rel="canonical" tag or HTTP Link header | Strong |
| XML sitemap inclusion | Weaker |
| Internal linking patterns | Considered |
| HTTPS over HTTP | Preference |
| Shorter, cleaner URLs | Preference |
When these signals align, Google almost always honours the declared canonical. When they conflict, Google makes its own choice, which may differ from yours. The URL Inspection tool in Search Console shows both the user-declared canonical (your tag) and the Google-selected canonical (what Google actually chose). A mismatch there is the diagnostic signal to look for.
Canonical failure scenarios
The following patterns are where canonicals most commonly break down in practice.
Canonical contradicts the redirect
The most common failure. A canonical tag declares www.example.com as the preferred URL, but the server issues a 301 redirect to example.com (non-www). Google receives two conflicting signals: the redirect says “this URL is the correct destination,” the canonical says “www is the canonical.”
The redirect wins. Google follows it and treats example.com as the canonical regardless of what the tag says. The canonical tag is effectively ignored.
Fix: align the canonical to whichever domain the redirect points to. If you redirect to non-www, the canonical must declare the non-www URL.
Canonical on a redirect source
When a URL issues a 301 redirect, Google does not process the canonical tag on that URL. It follows the redirect to the destination and processes the destination page’s canonical instead. Setting a canonical on a page that immediately redirects is wasted configuration.
Fix: ensure canonical tags are set on the final destination URL, not on redirecting URLs.
Canonical chains
Page A has a canonical pointing to page B. Page B has a canonical pointing to page C. Google should resolve this to C, but it is not guaranteed to do so, and the additional hop reduces signal confidence.
Fix: collapse chains so every page canonicals directly to the final intended URL.
Canonical contradicts internal linking
The canonical declares /product/ as the preferred URL, but the site’s navigation links to /product (without trailing slash). Internal link patterns are a canonicalisation signal. If internal links consistently point to a different form of the URL than the canonical tag, Google may override the tag in favour of the linked version.
Fix: standardise the URL form used in internal links to match the canonical declaration exactly.
noindex on the canonical target
A canonical tag points to a URL that has a noindex directive. This creates a contradiction: the canonical says “this is the real version,” noindex says “do not index this page.” The noindex wins; the canonical signal now points at an excluded page, and nothing gets indexed.
Fix: ensure the canonical target is indexable. Never point a canonical at a noindex page.
Cross-domain canonicals
Cross-domain canonicals are treated as a weaker signal than same-domain canonicals. For syndicated content specifically, Google does not recommend the canonical approach at all: the preferred fix is for syndication partners to block indexing of republished versions.1 If a cross-domain canonical is already in place and Google is ignoring it, that is consistent with how Google treats these signals rather than a configuration error to solve.
Cross-domain canonicals may still be processed by other search engines, so they are not without value across platforms. However, they should not be treated as the primary solution for syndication scenarios where Google is the main concern.
Malicious injection
Attackers may inject rel="canonical" tags or 301 redirects pointing to URLs on domains they control, causing Google to select a compromised URL as canonical. If the Google-selected canonical points to a domain you do not recognise, treat it as a security incident rather than a canonicalisation configuration problem.1
Fix: audit canonical tags for unexpected cross-domain values and check server configuration and CMS plugins for injected redirects or link elements.
HTTP/HTTPS mismatch
A canonical on the HTTP version of a page points to the HTTP URL, while the page also 301 redirects to HTTPS. The redirect will win. Beyond the signal conflict, HTTPS is preferred by Google for canonical selection: even if no tag is set, it will typically select the HTTPS version.
Fix: ensure canonicals always reference the HTTPS URL.
Relative URLs in canonical
The canonical href value uses a relative path (/about/) rather than an absolute URL (https://example.com/about/). Google supports relative paths but notes they can cause problems in the long run, particularly if the page is served from a subdomain or CDN path where the base URL is ambiguous.3
Fix: always use absolute URLs with protocol and trailing slash in canonical tags.
Missing canonical
When no canonical is declared, Google selects one based on the signals available. It may choose a parameter-heavy URL, a session-tagged variant, or the HTTP version over HTTPS. The selection is often not the URL you would choose.
Fix: set a self-referential canonical on every indexable page. No page should be without one.
Case sensitivity
/Product/ and /product/ are treated as distinct URLs by case-sensitive servers. If the site serves both, a canonical on one version must exactly match the case of the preferred URL.
Fix: standardise URL casing site-wide and ensure canonical tags match exactly.
Canonicals and hreflang
For international sites using hreflang, the canonical on each page should point to the same-locale version of that page, not to a different language or region equivalent. A French-language page should canonical to itself (or to the correct French URL), not to the English equivalent.
Pointing cross-locale canonicals at a single URL while using hreflang creates a contradiction: hreflang tells Google to serve different users different URLs, while the canonical says there is only one preferred version. Google will typically resolve this in favour of one signal or the other, but the result is unpredictable.
How do you audit canonical tags?
Before treating every canonical mismatch as something to fix, evaluate whether Google’s selected canonical might be more appropriate for users arriving from search. If Google is consistently choosing a different URL and that URL serves users well, updating your declared canonical to match may be the correct response rather than fighting the signal.1
For genuine mismatches, two tools cover canonical auditing at different levels of detail:
URL Inspection in Search Console. For individual URLs, this shows the user-declared canonical (your tag) and the Google-selected canonical (what Google chose). If they differ, that URL has a signal conflict worth investigating.
Site crawl tools. Screaming Frog and Sitebulb can audit canonicals site-wide: surfacing missing canonicals, cross-referential chains, canonical tags pointing to redirects or noindex pages, and mismatches between internal linking and canonical declarations.
For a full canonical audit checklist, see the Technical SEO Audit Checklist.
Frequently asked questions
Can a page have multiple canonical tags?
No. Multiple rel="canonical" tags on the same page produce unpredictable results. Google picks one arbitrarily. Every page should have exactly one.
Should I use a canonical or a 301 redirect?
If the duplicate URL has no reason to remain accessible, use a 301 redirect. It is the stronger signal and eliminates the duplicate entirely. Use a canonical when the URL must remain accessible for functional reasons (filtering, pagination, session management) but should not be independently indexed.
How do I confirm which canonical Google chose?
Open the URL Inspection tool in Google Search Console and look under “Indexing.” It shows both the user-declared canonical and the Google-selected canonical. If they differ, the “Google-selected” value is what Google is actually using.