How to use canonical tags: three signals, ranked by how strongly Google reads them
A canonical tag names the URL you want kept when several serve the same content. Google ranks it against redirects and your sitemap, so the tag only wins when the other signals agree — here is the paste-able block, the self-check command, and the four ways it silently fails.
A canonical tag tells Google which URL you want kept when several URLs serve the same content. It is a signal, not an instruction: Google weighs it against redirects, your sitemap and your internal links, and can still pick a different URL. Your job is to make all of those agree, then check that the page you want kept points at itself.
Before you start
You need to be able to edit the <head> of a page, or to set a response header. You also need to know which URL you actually want in search results, which is a content decision, not a technical one. If two pages are genuinely different, you do not have a canonical problem — you have two pages competing for one search term, which is a content decision as well.
Why a canonical tag is only one of several signals
Google's canonicalization documentation, read on 2026-08-24, opens by ranking the methods rather than describing them. That ordering is the part worth memorising, because it explains every case where a canonical tag appears to be ignored.
| Method | Strength | Works on |
|---|---|---|
| Permanent redirect | Strong | Any URL, but the old one is gone |
rel="canonical" link element | Strong | HTML pages only |
rel="canonical" HTTP header | Strong | Any file, including PDFs |
| Sitemap inclusion | Weak | Any URL you list |
The documentation describes redirects as "a strong signal that the target of the redirect should become canonical" and the link annotation as "a strong signal that the specified URL should become canonical", while sitemap inclusion is "a weak signal that helps the URLs that are included in a sitemap become canonical". It also notes that "these methods can stack and thus become more effective when combined".
Two consequences follow. If you redirect A to B and then put a canonical on B pointing back to A, you have sent two strong signals in opposite directions, and you should not be surprised by the outcome. And if your sitemap lists A while your canonical names B, you have not made a mistake so much as weakened your own case.
A redirect removes a URL. A canonical tag keeps it and asks for the credit to go elsewhere. Choose based on whether anyone still needs to reach the page.
How to set a canonical tag in four steps
This takes about ten minutes for one page and is the same for every page after that.
- Decide the URL you want kept. Write it out in full, with the protocol, the host you actually serve, and the trailing slash you actually use.
- Put a self-referential canonical on that URL. Google's guidance is explicit: "Do include a
rel="canonical"link on the canonical page itself (also known as a self-referential canonical)." - Point every duplicate at it, using one method only. The docs recommend choosing between the link element and the HTTP header, because "while supported, using both methods at the same time is more error prone".
- Make your internal links agree. "When linking within your site, link to the canonical URL rather than a duplicate URL."
Step 2 is the one people skip, because a page pointing at itself feels redundant. It is not: it is what stops a scraper's copy, a tracking parameter or a print view from becoming the version Google settles on.
The deliverable: two blocks and one check
The link element form, in the <head> of both the canonical page and each duplicate:
<link rel="canonical" href="https://example.com/dresses/green-dresses" />The HTTP header form, which is the only option for a PDF or an image, since the link element "only works for HTML pages, not for files such as PDF":
Link: <https://example.com/white-paper.pdf>; rel="canonical"And the check, which reads what a page declares and what URL it actually settles on, so you can compare the two:
# What does the page declare?
curl -sL https://example.com/page \
| grep -o '<link[^>]*rel="canonical"[^>]*>'
# Is there also one in the headers? (There should not be both.)
curl -sIL https://example.com/page | grep -i '^link:'
# Where does the URL actually end up?
curl -s -o /dev/null -w '%{url_effective}\n' -L https://example.com/pageIf the third command prints a different URL from the first, that is not automatically wrong — a redirect chain ending at the canonical is consistent. It is wrong when the canonical names a URL that itself redirects, because you are then asking Google to keep a page that does not exist at that address.
What goes wrong, and how to recognise it
The canonical is fighting a redirect
Symptom: Search Console reports the page as "Duplicate, Google chose different canonical than user". Cause: the URL you named is not the URL the server settles on. Check the third command above before blaming the tag.
robots.txt is being used to hide a duplicate
Symptom: the duplicate still shows up in search, with no description. The documentation is blunt about why: "Don't use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content." Blocking the crawl removes the evidence, not the URL.
noindex is being used to pick a winner
Symptom: the page disappears entirely rather than merging. Google recommends against it in the same list: using noindex to prevent selection of a canonical page within a single site "will completely block the page from Search. rel="canonical" link annotations are the preferred solution." Read when to noindex a page for the cases where that outcome is what you want.
The canonical points at a fragment
Symptom: nothing happens at all. "Don't specify a URL fragment as canonical, as Google generally doesn't support URL fragments." A canonical ending in #section is not a weaker signal — it is not a signal.
Where a canonical tag stops working
It is worth knowing the boundary before you spend a week on this. None of these methods are required — the documentation says so directly: "your site will likely do just fine without specifying a canonical preference", because without one, Google will pick "the version of the URL that is objectively the best version to show to users in Search".
A canonical also does not survive being contradicted. Annotations carrying hreflang, lang, media or type attributes "are not used for canonicalization" at all. And a canonical across two different sites is a request, weighed against everything else Google knows; it is not a transfer you can execute.
Stop when Search Console agrees with you and your internal links agree with your tag. There is no further state to reach. If the pages you are canonicalising cannot be fetched in the first place, none of this applies — check whether crawlers can read the page first.
Common questions
What is a canonical tag used for?
Consolidating duplicate or near-duplicate URLs onto one address, so that links and other signals count towards a single page instead of being split. Google lists a second reason worth remembering on a large site: "to avoid spending crawling time on duplicate pages".
Does every page need one?
No page needs one. Every page benefits from a self-referential one, and it costs a single line in a template. Our own measurement found 23 of 28 homepages declare a canonical, which is roughly the rate you would expect from a setting most content systems now ship by default.
Canonical or 301 redirect?
Redirect when nobody needs the old URL to render. Use a canonical when both URLs have to keep working — a filtered listing, a print view, a syndicated copy. If you are about to change a URL, the redirect is only one of the things you have to keep in step; see what a URL change affects.
Is the canonical tag part of the HTML standard?
It is defined in RFC 6596, and Google's documentation names that document as what it supports. It is a web standard rather than a Google invention, which is why other search and answer engines read it too.
Part of the QueryWin handbook · Level 2
