A canonical tag tells Google which URL you prefer when several URLs show the same or very similar content. It is a signal and not a command, and Google can overrule it. It doesn’t remove a page from search by itself, doesn’t redirect anyone, and doesn’t fix two pages that are actually different. Used for what it’s for, it consolidates duplicates so one URL gets shown and the signals aren’t split.
The tag
Place it in the <head> of the page, with an absolute URL:
<link rel="canonical" href="https://example.com/shoes/trail-runner">For non-HTML files such as PDFs, use an HTTP header. Google’s documentation supports this, and it’s the only option since a PDF has no <head>:
Link: <https://example.com/guide.pdf>; rel="canonical"Every indexable page should have one that points to itself. Google’s documentation recommends a self-referencing canonical, and it protects you when somebody links to your page with ?utm_source=newsletter on the end.
What it does and does not do
| It does | It does not |
|---|---|
| Suggest which URL should appear in search | Guarantee Google will agree |
| Help consolidate signals across duplicates | Stop Google crawling the other URLs |
| Work across a site’s parameter, protocol and tracking variants | Redirect users, who still see the page they opened |
| Work with non-HTML files through the header | Make different pages count as the same page |
Canonicalized duplicates are still crawled. Google needs to fetch them to see the tag. If you have a million parameter URLs and your concern is crawl load, a canonical alone won’t help you.
How strong each signal is
Google ranks the methods by influence in its documentation:
- Redirects are a strong signal.
rel="canonical"in HTML or a header is a strong signal.- Sitemap inclusion is a weak signal.
Google also weighs other things: which version you link to internally, HTTPS over HTTP, and whether the content really matches. If your canonical says one thing and your internal links, sitemap and hreflang all say another, don’t be surprised when Google goes with the majority. Its documentation warns specifically against naming different canonicals across methods.
When to use which
Redirect (301). Use it when the old URL shouldn’t exist any more: a moved page, HTTP to HTTPS, or www to bare domain. People and bots both end up in the right place.
Canonical. Use it when both URLs need to keep working for users. Sorting parameters, tracking codes and printer versions, for example, or a product reachable through two category paths.
Noindex. Use it when a page should stay out of search entirely, with no preferred substitute. An internal search results page is one example.
Don’t apply all three to the same thing. Pick the one that matches your intent.
How canonicals interact with redirects
A canonical pointing at a URL that redirects forces Google to reconcile two instructions. Point it directly at the final URL. The same goes for canonicals that point to a 404 or to a page that has its own canonical somewhere else, which forms a chain.
Check it with the Redirect Chain Checker: enter your canonical target and confirm it returns 200 with no redirects.
A related failure comes from HTTPS. Google’s documentation warns that broken certificates, HTTPS-to-HTTP redirects, or HTTP URLs in sitemaps and hreflang annotations can push it toward the HTTP version, regardless of your canonical tag.
How canonicals interact with noindex
These send opposing messages. A canonical says “this content matters, count it at that URL”, and noindex says “drop this page”. Google’s documentation is direct: “We don’t recommend using noindex to prevent selection of a canonical page within a single site,” since noindex removes the page from search altogether, and rel="canonical" is the preferred way.
If you put noindex on page A with a canonical to page B, you are relying on Google to prioritize one over the other in a way you can’t predict. Worse, when the two are mixed up on a template, the page you want indexed may carry the noindex. To see both signals at once, run a URL through the SEO URL Inspector.
Robots.txt is a separate trap. If a page is disallowed, Google can’t read its canonical tag at all. Its documentation says plainly: “Don’t use the robots.txt file for canonicalization purposes.” Disallowed URLs may still get indexed without their content. See robots.txt versus noindex.
Cross-domain canonicals
A canonical can point to another domain, and this works for your own properties. Two sites you control with shared content, or a site migration where a redirect isn’t possible, are the classic uses. Google’s 2009 post that introduced the idea treats it as a way of handling legitimate duplication across sites.
Syndication is the exception, and the advice has changed. If you see old guidance that says partners who republish your article should add a cross-domain canonical to you, it’s out of date. Google’s canonicalization troubleshooting page now says the canonical link element isn’t recommended for avoiding duplication by syndication partners, because the copies often differ substantially from the original. Google’s recommendation is that partners block indexing of their copies with noindex. Ask for that in your syndication agreements.
Check your own pages as well. Google lists cross-domain canonicals injected by hacking among the causes of an unexpected canonical, so a surprise here deserves a security look.
Common mistakes
Google’s 2013 post on common rel=canonical errors is still a useful list, and its current documentation adds to it.
Pointing every paginated page at page 1. Pages 2 and onward have different content. Canonicalizing them to page 1 tells Google they are duplicates, and the items listed only on those pages may never be found. Each page in the series should point to itself.
Relative paths without a protocol. example.com/page with no https:// is treated as a path relative to the current site, so it resolves to something like https://example.com/example.com/page. Use full, absolute URLs. Google’s documentation recommends this too.
More than one canonical on a page. A theme adds one, and a plugin adds another. If they conflict, search engines may ignore both. View the rendered source and count them.
Canonical in the <body>. Search engines process it only in the <head>. An unclosed tag or a stray element high up can make a browser end the head early, so a canonical that looks correct in your template can land in the body. Put it high in the <head>.
Category page pointing at a featured article. The category page may vanish from search in favour of that article. Each should have its own canonical.
Canonical to a different page because they’re “similar”. Two articles on related topics are not duplicates. Google may ignore the tag, and if it doesn’t, you lose a page.
Changing it with JavaScript. Google’s documentation says that if JavaScript adds canonicals, scripts shouldn’t change them after the HTML is served. Serve the correct tag in the initial HTML where you can.
Fragments. https://example.com/page#section isn’t a valid target. Google says not to use URL fragments as canonicals.
When Google picks a different one
The Search Console status “Duplicate, Google chose different canonical than user” means it saw your signal and disagreed. Google’s stated reasons include “the quality of the content or technical signals”. Check these in order:
- URL Inspection. See which page Google selected. Sometimes its choice is actually fine, and you should adopt it.
- Other signals. Do your internal links, sitemap and redirects agree with your tag?
- Are the pages truly duplicates? If they should rank separately, they need clearly different content. Google says significant differences help pages separate faster.
- Language variants. Near-identical regional pages with no
hreflangget clustered. Google lists this among the common technical causes. - Server problems. Google lists identical soft 404 pages returned across URLs, and servers returning content for the wrong domain.
After fixing, use Request Indexing on your important URLs. Google says pages may stay in a duplicate cluster for up to two weeks after you fix content issues. It’s worth more patience than most people give it.
Checking your own pages
Our Canonical URL Checker fetches a live page and reports the tag and common faults, including www and trailing-slash mismatches, fragments, query parameters and conflicts with og:url. It reads the served HTML, so it won’t reflect canonicals added later by script. It also can’t show what Google selected. Only the URL Inspection tool in Search Console can tell you that.