Duplicate without user-selected canonical: what it means and when to fix it

“Duplicate without user-selected canonical” is a reason Search Console gives for not indexing a URL. It means Google decided the page is a copy of another URL, saw nothing from you saying which version you prefer, picked the other one, and will not show this one in Search. Google’s own help page calls it “not an error, but working as intended”. So the job is not to make the status disappear. It is to answer two questions for each URL in the list: did Google pick the version you want, and should this URL exist at all?

This guide quotes Google’s exact wording, shows where to find Google’s choice, sorts the cases into “leave it” and “fix it”, and gives the fix for each common cause, with real URLs. To see what a page tells search engines about itself, run it through the free canonical tag checker: it reads the tag, the HTTP header and the final URL after redirects, and follows the canonical to check it answers 200.

The statuses, the validation time and the 1,000-row limit are from the Page indexing report help^[1]. The clustering time is from Google’s canonicalization troubleshooting guide^[5].

What “Duplicate without user-selected canonical” means

Three facts are packed into that paragraph:

• Google clustered this URL with another one. Canonicalization is Google picking one representative URL for a set of pages with the same content. The canonical is crawled most regularly and shown in results; the duplicates are crawled less often^[3].
• You gave no preference. “User-selected” means a canonical you declared: a rel="canonical" tag, an HTTP header, a redirect or a sitemap entry^[4]. On this URL, Google found none that applied.
• The other URL is the one in Search. Your content is not missing from Google. It is indexed under a different address.

Google is blunt about what to expect from the report as a whole: “Don’t expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information.” And: “Having a page marked duplicate or alternate is usually a good thing; it means that we’ve found the canonical page and indexed it.”^[1]

Is it a problem? Four cases

Google’s help gives two situations worth acting on: “if you think that Google has chosen the wrong URL as canonical, you can explicitly mark the canonical for this page. Alternately, if you think that this page is not a duplicate of the Google-chosen canonical, you should ensure that the content differs substantially between the two pages”^[1]. Add the case where the URL should not exist at all, and every row in the report fits one of these:

How to see which URL Google chose

The report tells you a URL was treated as a duplicate. It does not tell you of what. For that, inspect the URL. You can click a row in the report’s example list or paste the URL into the search bar at the top of Search Console.

Two details from Google’s help matter here. First, the field for your preference: “If your page is not a duplicate, None is fine here. If your page is one of a set of similar or duplicate pages, we recommend explicitly declaring the canonical URL.” Second, only the indexed result shows Google’s choice: “You can determine the canonical version only in the indexed data; the live test cannot predict whether or not the tested version will be considered canonical.”^[2] So a live test after a fix tells you the page is reachable, not that Google has changed its mind.

Then judge the choice the way Google suggests: decide whether its canonical “makes more sense” for people arriving from Search than yours^[5]. Sometimes it does. If Google picked the https URL over your http one, Google is right and your signals are stale.

Three canonical statuses, side by side

The Page indexing report has three reasons that mention a canonical, and they are easy to mix up. The difference is whether you declared a canonical, and whether Google agreed.

The middle one deserves a closer reading, because people search for it almost as often. Google’s explanation: “This error means that Google thinks that the tested page isn’t a duplicate of the user-declared canonical. Instead, Google thinks that the tested page is a duplicate of the Google-selected canonical.” And the line that settles most arguments: “If the user-declared canonical is not similar to the current page, then Google won’t ever choose that URL as canonical. A duplicate page must be similar to the canonical.”^[1] A canonical pointing from a product to its category, or from page 2 to page 1, is exactly that mismatch. The third status has its own guide: alternate page with proper canonical tag.

Fixes by cause

Google lists the inputs it weighs when it picks a canonical: whether a page is on HTTP or HTTPS, redirects, presence in a sitemap, and rel="canonical" annotations, and it calls a declared preference “a hint, not a rule”^[3]. Redirects and canonical tags are strong signals; a sitemap is a weak one^[4]. So every fix below does the same thing in a different place: it makes the signals agree. Find the pattern in your report’s example URLs, then jump to it.

1. Tracking, sorting and session parameters

The most common pattern: /shoes/trail/?utm_source=newsletter, ?sort=price, ?ref= or a session ID shows the same page as /shoes/trail/. Google’s URL guide names referral parameters, sorting parameters and session IDs as causes of “a large number of URLs”, says to avoid session IDs in URLs where possible and use cookies instead, and to trim parameters that don’t change the content^[6].

Fix: give the clean page a self-referencing canonical, built from the route rather than from the requested URL, so every variant names the clean address. Google recommends a canonical “on the canonical page itself”^[4]. Then check your own links: Google asks you to link to the canonical URL rather than a duplicate^[4], and a site whose menus link to ?ref=nav is voting for the duplicate on every page.

<!-- On https://www.example.com/shoes/trail/ and on every variant of it:
     ?utm_source=..., ?sort=price, http://, no trailing slash -->
<head>
  <link rel="canonical" href="https://www.example.com/shoes/trail/" />
</head>

2. http and https, www and non-www

Google lists protocol variants among the common sources of duplicates^[3], and it prefers HTTPS pages over equivalent HTTP ones unless there are issues or conflicting signals^[4]. If the report lists your http:// or non-www URLs, Google chose the version you wanted. If it lists your https URLs as duplicates of http ones, something still points at http: old internal links, a sitemap, or a canonical tag hard-coded with http://.

Fix: one 301 redirect from every other protocol and host to the one you want, in a single hop, plus canonicals, sitemap and internal links that all use it. A redirect is “a strong signal that the target of the redirect should become canonical”^[4]. The redirect checker shows whether a variant reaches the right URL in one hop or three, and 301 Moved Permanently covers what the status code tells crawlers.

# nginx: every protocol and host variant goes to one URL, in one hop
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request_uri;
}

server {
  listen 443 ssl;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

# Inside the https://www.example.com server block:
# add the slash to directory-style paths that lack one (skip files with an extension)
rewrite ^([^.]*[^/])$ $1/ permanent;

3. Trailing slash and letter case

/foo and /foo/ are two URLs to Google. Its 2010 post on the subject says Google “treats each URL above separately (and equally)”, and that if both answer 200 with the same content you can leave it, since “our indexing process often handles this case”, or pick one, use it in internal links and the sitemap, and 301 the other. If a redirect is not possible, “the rel="canonical" link tag is a strong option”^[7]. Case works the same way: Google’s URL handling is case sensitive, so /APPLE and /apple are distinct URLs, and if your server treats them the same, Google asks you to convert all text to the same case^[6]. Bing lists trailing slashes and upper and lower case URLs among its common causes too^[13].

4. Pagination

Two opposite mistakes show up here. The first is pointing page 2, 3 and 4 at page 1. Google says: “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL”^[8]. Google’s older post on canonical mistakes explains the cost: it “would result in the content on pages 2 and beyond not being indexed at all”^[11]. The second is pages that really are duplicates: page 9 of a category with 8 pages that still answers 200 and repeats page 8, or ?page=1 alongside the bare category URL.

Fix: each real page names itself. Make out-of-range page numbers return a 404 and link page 1 as the bare URL, so ?page=1 never gets linked. Google also says to give each page a unique URL, such as a ?page=n parameter, and not to use fragments (#page2) for page numbers^[8].

5. Faceted navigation and filters

Filters multiply URLs fast: colour times size times price band. Google’s URL guide uses hotel search results to show how additive filters make the number of URLs explode^[6]. Here Google’s own advice is not “add a canonical”. Its faceted navigation guide says that if you don’t need filtered pages indexed, blocking them in robots.txt or using URL fragments for filters works better, and that rel="canonical" and rel="nofollow" are “generally less effective in the long term”. A canonical to the unfiltered page “may, over time, decrease the crawl volume of non-canonical versions”^[9].

Fix: decide which filter pages deserve to rank (often one level, such as a category plus a colour) and make those self-canonical with their own titles. For the rest, the canonical to the parent is a reasonable hint, and robots.txt is the stronger crawl control. Keep the two goals apart: robots.txt controls crawling, it does not choose a canonical. The robots.txt generator tests a rule against your URLs before you ship it.

6. Shopify collection product paths

Shopify themes can link to a product inside a collection with the Liquid within filter, which produces URLs such as /collections/sale/products/item. Shopify’s documentation warns that “a standard product page and a product page in the context of a collection have the same content on separate URLs”, so you “should consider the SEO implications”^[10]. Those collection paths are the URLs that land in this report on Shopify stores, next to variant URLs with ?variant=.

Fix: check that the collection path names the plain /products/ URL as its canonical (run one through the checker), then stop generating the collection paths: in the theme’s product card snippet, link to product.url instead of product.url | within: collection. A Shopify store that shows the status for collection paths while Google chose /products/ URLs is in the “working as intended” row of the table above.

7. Pages that are almost the same

Location pages with one word swapped, a product in six sizes with six URLs, a tag page that lists the same three posts as a category page. Google’s test for a valid canonical is that “a large portion of the duplicate page’s content should be present on the canonical version”, and it suggests imagining you don’t understand the language: if most of the words match side by side, they are duplicates^[11].

Fix: either make them different (real local details, prices, stock, photos, reviews) or make them one page and redirect the rest. Google’s troubleshooting guide says clustered pages can stay together for “up to two weeks” after you fix the content, and split faster when the differences are “clear and significant”^[5]. Rewording a sentence is not significant.

Real examples, checked with the canonical checker

We ran five public URLs, one per cause, through the code behind the canonical checker on 11 October 2026. We can’t see these sites’ Search Console data, so this shows what each URL tells Google, not what Google decided.

The Allbirds row is the subtle one. Google says it prefers URLs that are part of hreflang clusters when it picks a canonical^[4], and here the canonical tag and the hreflang links name two different URLs for the same product. We can’t tell from outside which one Google settled on; URL Inspection on the store’s own property would. It is the kind of mixed signal that ends with a URL in one of the duplicate statuses.

Sources: Google^[1][3][4].

What not to do

Google’s canonical guide lists the moves that make things worse ^[4]:

• Don’t use the URL removal tool. It “hides all versions of a URL from Search”, the canonical included.
• Don’t declare different canonicals with different methods. A sitemap naming one URL and a tag naming another cancel each other out.
• Don’t use a fragment as the canonical. Google “generally doesn’t support URL fragments”.
• Don’t let JavaScript change the canonical. Put it in the HTML source and make sure scripts don’t rewrite it.
• Don’t write relative canonicals. Google asks for absolute URLs. A relative one resolves against whatever host served the page, staging included.

One more from experience: more than one canonical tag on a page. Google’s post on common mistakes says that with multiple declarations it “will likely ignore all the rel=canonical hints”, and that this often comes from SEO plugins adding a default tag^[11]. That leaves Google to choose, which is how a page ends up here.

After the fix: validate and wait

In the report, open the issue and click Validate fix. Google’s help says validation “typically takes up to about two weeks, but in some cases can take much longer”, and asks you not to click it again until it has passed or failed. You can also skip validation: Google updates the count whenever it recrawls an affected page anyway^[1]. For your most important URLs, use Request indexing in URL Inspection; there is a daily quota, so Google suggests reserving it for the URLs that matter most^[5].

Expect the status to stay on the variants even when everything is right. A ?utm_source= URL that Google clusters under your clean URL will keep its row in the report. That is the report describing a correct result.

Why it matters for AI answers

Google says a page must be indexed and eligible to be shown with a snippet to appear in its generative AI features, and its guide for those features repeats the duplicate advice in one line: “Reduce duplicate content”^[12]. Since a Google result usually points to the canonical page^[3], the URL Google picks is the URL an AI Overview can link to.

Bing is more specific. Its December 2025 post says “LLMs group near-duplicate URLs into a single cluster and then choose one page to represent the set”, and that when the differences are minimal “the model may select a version that is outdated”. It also says duplicate content “doesn’t trigger search penalties on its own”, and recommends 301s and canonical tags so search engines and AI systems surface the correct page^[13]. OpenAI and Perplexity publish nothing about how their crawlers treat canonicals, so anything more specific than that is a guess.

Checking canonicals across a whole site

The report shows URLs Google already crawled. To catch a template that prints the wrong canonical before Google does, check the pages yourself. CoreCited’s Site Audit crawls your site and checks that every page declares a canonical URL and answers a clean 200. The free account audits 10 pages, and every limit is on the pricing page. If the duplicates come from your sitemap listing variant URLs, the XML sitemap validator tests every URL it lists for redirects and blocks.

Questions people ask

Sources