A canonical tag is a preference, not a command. Google's documentation on consolidating duplicate URLs lists three signals in order of strength: a redirect is strong, a rel="canonical" link annotation is strong, and listing a URL in a sitemap is weak. Publishers still treat the tag as a switch that forces one URL into the index. It does not. It tells Google which URL you would like to represent a set of duplicates, and Google may choose another URL when the rest of the site disagrees.
That gap is where crawl attention leaks. Two URLs with the same article split links, confuse reporting, and give Googlebot a second copy to fetch. On a small site you may never notice. On a site that publishes every day, the extra copies add up: tracking parameters, print views, AMP or mobile hosts, HTTP leftovers, and syndication feeds that republish the same story. The fix is a consistent canonical story, not a one-off tag on a single template.
What the tag actually does
Place one link element in the head of the HTML:
<link rel="canonical" href="https://example.com/news/city-council-vote" />
Google supports this annotation as described in RFC 6596. The element is only accepted in head, so a tag injected into the body, or a head that is broken by an unclosed element above it, does not count. Google also ignores a rel="canonical" annotation that carries hreflang, lang, media, or type. Those attributes belong on rel="alternate" links, not on the canonical.
Use an absolute URL. Relative canonicals are supported, and Google's own guide still advises against them because a testing host, a CDN hostname, or a misplaced base URL can turn a relative path into the wrong absolute address.
The same preference can be sent as an HTTP header, which is the practical option for PDFs and other non-HTML files:
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"
Pick one method. Sending both a header and an HTML element is allowed, and it is also how teams accidentally declare two different URLs.
Google recommends a self-referential canonical on the preferred URL itself. The preferred page points at itself. Every duplicate points at that same preferred URL. A page that points at a different page, while that other page points somewhere else, is a chain. Chains are harder to trust than a single, repeated target.
Where publisher duplicates come from
Most duplicate sets on a publishing site are created by the platform, not by a writer pasting the same story twice.
Tracking parameters. Email, ads, and social tools append utm_source, utm_medium, fbclid, or a similar query. The article is the same. If the template prints a canonical that includes the query string, every campaign creates a new preferred URL. Strip known tracking parameters before you write the canonical, and do not let analytics tags rewrite the tag.
Protocol and host variants. http and https, www and the apex host, and a trailing slash versus no trailing slash are four URLs until redirects and canonicals agree. Google prefers HTTPS over HTTP unless the HTTPS URL has a bad certificate, insecure dependencies other than images, a redirect back through HTTP, or a canonical that points at the HTTP URL. A certificate for the wrong host is enough to push Google back toward HTTP. HSTS does not override that preference.
Print, amp, and comment pages. A /print/ view, an old AMP URL, and a reply permalink that repeats the full article are duplicates if the main text is the same. Point them at the article URL. If the print view exists only for humans, a canonical is the right signal. If nobody needs that URL at all, a redirect is stronger and also stops people from sharing the print link.
Syndication. A partner site republishes your story. Their copy is a separate host, so your canonical tag cannot control their site. You can ask the partner to canonical back to you, or you can accept that Google will choose. What you can control is your own copies: do not publish the syndicated version again on a subdomain with a second canonical.
Faceted and paginated archives. Category pages with ?sort=date and ?sort=title are near-duplicates. Google's canonical guide uses a similar example: you would rather people land on the clean product URL than on a URL that carries a click identifier. For archives, decide which URL is the real section page, canonical the sorted variants to it, and keep the sorted URLs out of the sitemap. Pagination is different. Page 2 is not a duplicate of page 1. Do not canonical every paginated URL back to page 1 if those pages contain unique item links you want discovered. That pattern hides the rest of the list.
International editions. If you use hreflang, the canonical should stay in the same language, or the closest substitute when a same-language canonical does not exist. Google's guide also notes that URLs inside a reciprocal hreflang cluster are preferred over a near-duplicate that is left out of the cluster. A German page that canonicals to the English page, while hreflang says the German page is the German version, is a contradiction. Pick the language URL as canonical for that language and use hreflang for the alternates.
Signals that outvote the tag
The tag loses when stronger signals point elsewhere. Work through them in the same order Google describes.
Redirects win. If the URL you put in the canonical itself redirects, Google follows the redirect. A canonical to a redirected URL wastes the hint. Point the tag at the final URL, and point internal links there too.
Internal links are a standing vote. If the home page, the category template, and the related-stories module all link to the parameter URL, you are telling Google that the parameter URL is the real one. Linking consistently to the URL you consider canonical is called out in Google's guide for that reason. Audit the templates, not a single article. A related-stories widget that builds links from the raw request URL will reintroduce the duplicate on every page.
Sitemaps are a weak canonical signal, and they still matter because they are easy to get wrong. Every URL in a sitemap is suggested as a canonical. If the sitemap lists the tracking URL and the HTML canonical lists the clean URL, you have declared two preferences. List only the clean URL. The sitemap guide covers which URLs belong in that file.
robots.txt is not a canonical tool. Google says not to use it for canonicalization, because a disallowed URL can still be indexed from links without its content being read. Blocking the duplicate and canonicalising it are different jobs. If you need the duplicate out of the index, let Google crawl it, see the canonical, and consolidate. The robots.txt mistakes guide walks through what a disallow actually does.
noindex is the wrong tool for choosing a preferred URL inside one site. Google's guide says it will block the page from Search entirely. Use it when the URL should not be indexed at all, such as an internal search results page, not when the URL is a duplicate of a page you do want indexed.
The URL removal tool is also the wrong tool. It hides versions of a URL from Search for a while. It does not consolidate them.
How to audit a template
Do this on the template that renders articles, then on the template that renders section pages. One sample URL is not enough if the bug depends on the query string.
- Fetch the HTML and confirm there is exactly one
rel="canonical"inhead, with an absolute HTTPS URL and no tracking parameters. - Open the same article with a
utm_sourceparameter and with a trailing-slash variant. The canonical target should stay identical. - Compare that target with the URL in your XML sitemap and with the URL your home page actually links to.
- In Search Console, inspect the URL. Read the user-declared canonical and the Google-selected canonical. If they differ, the selected URL is the one Google believes is the better representative. The URL Inspection guide shows where those two fields sit.
- In the Page indexing report, open "Duplicate, Google chose different canonical than user" and "Duplicate without user-selected canonical". Export a sample. Group the samples by template. A hundred URLs with the same pattern means one fix, not a hundred.
When Google selects a different canonical, look for a reason you can see: the other URL has more internal links, the preferred URL redirects, the preferred URL is slower or thinner, or the two pages are not actually duplicates and Google is confused because the canonical claims they are. A canonical from a short stub to a long article is reasonable. A canonical between two articles that only share a topic is not. Google can ignore that hint, and the report is how you find out.
A worked pass on one article URL
Take a story that exists at all of these addresses:
https://www.example.com/news/city-council-votehttps://example.com/news/city-council-vote/https://www.example.com/news/city-council-vote?utm_source=newsletterhttps://www.example.com/print/city-council-vote
Choose the first URL. Redirect the apex host and the trailing-slash form to it with a permanent redirect. Those are the strong signal. On the www URL, emit a self-referential canonical that ignores the query string, so the newsletter variant canonicals to the clean URL. On the print view, canonical to the same clean URL, or redirect the print view if you do not need it. Put only the clean URL in the sitemap. Change the "latest stories" module so it links to the clean URL even when the current request has parameters.
Then wait. Canonical selection is not instant, and requesting indexing for every variant does not make the consolidation faster. Inspect the clean URL and one variant after Google recrawls. You want the variant to show the clean URL as the selected canonical, and the clean URL to be the one that is indexed.
Mistakes that keep the wrong URL in Search
Canonical to the home page on every article. Google will often ignore it, and when it does not, you have asked for your archive to collapse into one URL.
Different canonicals on mobile and desktop HTML when they are the same URL. If you have a separate mobile host, the desktop page can point at the mobile page with rel="alternate" and a media query, and both should still agree on one canonical.
A canonical that includes a fragment (#comments). Google generally does not support URL fragments as canonicals.
A JavaScript app that ships one canonical in the raw HTML and then replaces it after hydration. Google's guide says the clearest setup is a canonical in the HTML source that JavaScript does not change. If you cannot put it in the source, set it only with JavaScript. Do not do both with different values.
Leaving the staging hostname in the canonical after launch. Every production page then declares a host that may be blocked or noindexed. View source on a production URL before you celebrate a deploy.
What to do this week
Pick the article template. Write down the one URL shape you want: host, protocol, trailing slash, and which parameters are allowed to survive. Make the redirect rules, the canonical element, the internal links, and the sitemap all emit that shape. Then sample the Page indexing duplicate groups and confirm the samples belong to that template.
Canonical tags do not add ranking magic. They stop the same story from competing with itself. If the Google-selected canonical on your latest feature is still a parameter URL, the next place to look is the internal links, not another plugin setting. The indexing diagnostic is the right follow-up when the preferred URL itself is the one missing from the index.
CrawlFaster can watch indexing status across a set of URLs, which is useful after a canonical change because you want to see whether the preferred URLs stay indexed while the variants drop out. The decision of which URL is preferred is still yours to make in the template.
