Duplicate content and canonical tags, how Google picks one URL
Ordinary duplicate content does not get a site penalized. Google groups URLs that show the same or nearly the same content, picks one of them as the canonical and shows that one in results, and your rel=canonical tag is one strong input to that choice alongside redirects, sitemaps, internal links and HTTPS.
When those inputs agree, your preferred URL is the one that shows up. When they disagree, Google decides for itself, which is how pages end up under the Search Console status "Duplicate, Google chose different canonical than user". Most canonical problems are consistency problems: the tag, the redirects, the sitemap and the links should all name the same URL.
What duplication costs, and what it doesn't
Some duplicate content on a site is normal and it's not a violation of Google's spam policies.
That sentence is from Google's canonicalization overview, and it covers everyday duplicates: parameter URLs, print views, HTTP and HTTPS versions, one product in two categories. Spam rules matter when duplication is the strategy. Google's spam policies treat republishing other sites' content without adding value as scraping, and they list pages aimed at specific cities or regions that funnel visitors to one destination, along with substantially similar pages, as doorway abuse. A batch of location pages that only swap the city name sits close to that line, and no canonical tag fixes it. Those pages need merging or genuinely local content.
For everyone else the cost is efficiency, in three forms:
Signals split. External and internal links spread across several URLs for one piece of content, and Google has to consolidate them onto whichever URL it picks.
Crawling goes to copies. Google says canonical pages are crawled most regularly and duplicates less often, but on a large site sorting, filtering and tracking parameters can multiply URLs faster than that saving helps.
The wrong address gets shown. Google can consolidate onto a parameter URL, an old HTTP address or a staging host nobody meant to rank.
Where duplicate URLs come from
Most duplication is infrastructure: the same page answering at several addresses because nobody decided which one was official.
| Source | Example pair | Usual fix |
|---|---|---|
| Protocol and host | http://example.com/shoes and https://www.example.com/shoes | One-hop 301 to the preferred origin |
| Trailing slash and case | /Shoes/ and /shoes | Server rule that 301s to one form |
| Sort and filter parameters | /shoes and /shoes?sort=price | Canonical to the unsorted page |
| Tracking parameters | /shoes?utm_source=newsletter | Canonical, and no tracked URLs in internal links |
| Session IDs | /shoes;jsessionid=8F2A | Keep sessions in cookies, not URLs |
| Staging or CDN host left open | staging.example.com/shoes | Password protection, canonicals to production |
| Print and legacy versions | /shoes/print and m.example.com/shoes | 301 if nobody needs them, otherwise canonical |
| One product, two categories | /men/trail-shoe and /sale/trail-shoe | One product URL that both categories link to |
| Syndicated copies | partner-site.com/your-article | Partner blocks indexing of its copy |
| Same language, different region | /en-us/pricing and /en-gb/pricing | Self-canonicals plus hreflang |
| Near-identical pages | /plumber-leeds and /plumber-york | Merge, or make each one different |
The signals Google documents
Google's guide to specifying a canonical URL ranks the explicit methods by how strongly they influence the choice. Redirects are a strong signal that the target should become canonical. A rel=canonical link element or HTTP header is also a strong signal. Listing a URL in a sitemap is a weak one. Beyond those, Google prefers HTTPS over HTTP and prefers URLs that belong to hreflang clusters.
The same guide asks you to link internally to the canonical URL, because consistent linking helps Google understand your preference, and notes that the methods stack: two or more pointing at one URL raise the chance it is the one shown. Factors that appear in SEO checklists but not in Google's documentation, such as which version other sites link to or how tidy a URL looks, are practitioner observations at best.
A hypothetical with conflicting signals
Say a shop sells a trail shoe that resolves at three addresses: /trail-shoe (A), /trail-shoe?color=red (B) and /men/trail-shoe (C). Here is how different setups are likely to play out.
| Setup | What the signals say | Likely outcome |
|---|---|---|
| Canonical A on all three, sitemap lists A, navigation links to A | Everything agrees | A is chosen |
| Canonical A on all three, sitemap lists A, every category and breadcrumb links to C | Explicit signals against the link graph | Probably A, but C may be picked or keep surfacing in reports |
| Sitemap lists A, canonical says B, navigation links to C | Three different answers | Google picks on its own, possibly none of the URLs you intended |
| Canonical A on all three, but A returns noindex or a 404 | The target can't be indexed | Expect the hint to be ignored and B or C chosen |
The fix in every row except the first is to change the disagreeing signal, not to add more canonical tags.
Redirect, canonical, noindex or nothing
These four options answer different questions, and choosing the wrong one causes most self-inflicted duplicate problems.
| Option | Use it when | One-line test | Effect on signals |
|---|---|---|---|
| 301 redirect | Nobody needs the duplicate URL (old host, HTTP, merged page) | Would a visitor lose anything if this URL stopped loading? If not, redirect | Strongest; the old URL drops out and signals move |
| rel=canonical | Visitors still need both URLs (sorted views, tracked links, product in two categories) | Must this URL keep working? If yes, canonical | Strong; both URLs work, Google consolidates onto the target |
| noindex | The page should not be in Search and has no better URL to fold into | Is there an equivalent page that should rank instead? If yes, don't noindex | Removes the page from results and consolidates nothing |
| Leave it | Google already shows the right URL and variants take little crawling | Is the wrong URL ranking, or are crawlers stuck on variants? If neither, leave it | None needed |
Two combinations cause trouble. Google says it doesn't recommend noindex for steering canonical selection within a site, because noindex blocks the page from Search entirely. Putting noindex and a canonical on the same page also contradicts itself, since one declares the page a copy of another URL and the other asks for it to be dropped. Pick the one that matches what you want.
Robots.txt is the other trap. Google's guide says not to use it for canonicalization, and the mechanics explain why: a URL blocked from crawling can't be fetched, so its canonical tag is never read and its signals can't be passed anywhere. The difference between blocking crawling and blocking indexing is covered in the post on what robots.txt controls and what it does not.
Markup that does what you intend
A canonical link element belongs in the head, with an absolute URL that includes protocol and host:
<head>
<title>Trail running shoe</title>
<link rel="canonical" href="https://www.example.com/trail-shoe">
</head>Google supports relative URLs here but recommends absolute ones, and it only accepts the element in the head. Put a self-referencing canonical on the canonical page too. One detail decides whether that helps: the template has to build the self-reference from the clean URL. A template that echoes the requested URL, parameters included, tells Google that every tracked or sorted variant is its own canonical.
For files that have no HTML head, such as PDFs, send the same signal as an HTTP response header:
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://www.example.com/guides/sizing-guide.pdf>; rel="canonical"This fits a sizing guide served at two paths, or a Word file whose canonical is the PDF version. Google supports the header for web search results.
The least visible failure is an invalid element in the head. Google's guide to valid page metadata says the head should only contain title, meta, link, script, style, base, noscript and template elements, and that when Google meets an invalid one, such as an img or iframe, it assumes the head has ended and ignores the elements after it. In this example the canonical is never read:
<head>
<title>Trail running shoe</title>
<img src="/tracking-pixel.gif" alt="">
<link rel="canonical" href="https://www.example.com/trail-shoe">
</head>Tracking pixels, consent widgets and A/B testing snippets that inject markup are the usual causes. The fix is moving the canonical (and other important meta tags) above anything a third party controls, then removing the invalid element.
Syndication and cross-domain canonicals
If partners republish your articles, Google's canonicalization troubleshooting page is direct: the canonical link element is not recommended for avoiding duplication by syndication partners, because the pages are often very different, and the most effective solution is for partners to block indexing of your content. In contract terms, the partner adds a noindex robots meta tag or X-Robots-Tag header to its copy. A visible link back to your original is a sensible attribution term that sends readers your way, but Google's guidance doesn't rely on it to keep the partner's copy out of results.
Cross-domain canonicals still work for duplicates you own and control, such as a second domain that mirrors the same catalog. Even there, a 301 is the stronger choice if visitors don't need the second copy.
Canonicals on multilingual and multi-regional pages
Google treats language versions as duplicates only when the primary content is in the same language, so a French page and its English translation should never canonicalize to each other. When you use hreflang, Google's guide asks you to specify a canonical in the same language. Same-language regional pages, such as US and UK pricing pages in English, are a different case: they can be grouped as duplicates, so each one should carry a self-referencing canonical and the set should be joined with hreflang. Pointing the UK page's canonical at the US page tells Google the UK URL is a copy to drop, which defeats the hreflang annotation on the same page. The full setup is in the guide to hreflang and international URL structure.
Bugs that break canonicals at template level
Canonical tags come from templates, so one bug repeats across thousands of URLs. Check these patterns first:
A canonical that points at a URL which itself redirects. Point straight at the final URL that returns 200.
A hardcoded protocol or host, often a template string that predates an HTTPS or www change, so every page declares a canonical the server then redirects away from.
Staging hostnames in production. A copied configuration file can make every live page declare a staging URL as its canonical.
Paginated series canonicalized to page one. Google's pagination guidance says not to use the first page as the canonical and to give each page its own. Otherwise the deeper pages, and the items only they link to, can drop out of discovery.
Two canonical tags in one head, typically a theme and a plugin both writing one. With two conflicting hints you lose control over which one, if either, Google uses.
A canonical that JavaScript rewrites after load, so the raw HTML and the rendered page name different URLs. Make them agree, and see the post on JavaScript SEO for comparing raw and rendered output.
A canonical target that is noindexed, blocked or returns an error, which makes the tag useless.
Reading what Google chose
Search Console reports duplicates under three statuses in the Page indexing report, and they call for different responses.
| Status | What it means | What to do |
|---|---|---|
| Alternate page with proper canonical tag | The page points to a canonical that is indexed | Nothing, if that canonical is the URL you want |
| Duplicate without user-selected canonical | Google sees a duplicate and the page declares no canonical | Add a canonical, or a redirect if the URL isn't needed |
| Duplicate, Google chose different canonical than user | You declared one URL and Google picked another | Work through the checks below |
For the third status, work in this order, since each step rules out a whole class of causes:
Run a few affected URLs through URL Inspection and compare the user-declared canonical with the Google-selected one. If they share a template, suspect the template.
Ask whether the pages are really duplicates. If Google grouped two pages you consider different, such as two products sharing one manufacturer description, the fix is making the content different, not editing tags.
Confirm the declared canonical returns 200, is indexable and doesn't redirect.
Compare the other signals: whether the sitemap lists the declared URL, where navigation, breadcrumbs and in-body links point, whether any redirect or hreflang annotation names the other URL.
Read the raw head with curl or view-source, not the browser's element inspector, which shows the rendered page. Look for invalid elements above the canonical, duplicate tags and JavaScript changes.
Consider whether Google's pick is better. Its troubleshooting page suggests asking whether the selected canonical makes more sense for searchers than yours. If it does, align your signals with it.
Once the cause is fixed, change the surrounding signals too: internal links to the canonical, only canonical URLs in your XML sitemaps, and no redirects that contradict the tag. Google needs to recrawl the affected URLs before the status changes, so judge the fix over weeks, not days.
Duplication you can leave alone
Not every duplicate deserves a ticket. Two questions decide it: is the wrong URL showing for queries that matter, and are crawlers spending a meaningful share of their visits on variants? Server logs answer the second one directly, as the log file analysis primer explains. If the answer to both is no, the duplication is costing you little.
Several patterns look alarming in a crawl report and are expected: a handful of parameter variants already reported as "Alternate page with proper canonical tag", regional pages joined by hreflang with self-canonicals, shared headers and footers, and paginated series where each page has its own canonical.
A good first step is to open the Page indexing report, filter to "Duplicate, Google chose different canonical than user", group the examples by template and run the six checks on the largest group. A fix at template level clears every URL built from it.