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

Google serves only the canonical URL, in search and in the AI features built on its index, so a wrong pick sends visitors and links to a version you didn't choose. This guide quotes Google's definition, shows when to leave the status alone, covers the usual causes, and walks through confirming, fixing and validating it.

What does "Duplicate without user-selected canonical" mean?

"Duplicate without user-selected canonical" means Google found two or more URLs with the same main content, none of them said which one is preferred, and Google chose one itself. As of October 2026, Google's help page defines it this way: "This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search." (Page indexing report help).

The listed URL is the one Google set aside, not the one it kept. Google clusters pages whose primary content is very similar, then chooses the page that is "objectively the most complete and useful for search users, and marks it as the canonical" (Google Search Central: canonicalization).

Three Search Console statuses involve canonicals, and they're easy to mix up:

If your URL points to another page and Google accepted it, that's the second row: see what "Alternate page with proper canonical tag" means. The third status is the one where you did declare a canonical and Google overruled it; Google's help page says it means "Google thinks another URL makes a better canonical."

Is "Duplicate without user-selected canonical" a problem?

"Duplicate without user-selected canonical" is usually not a problem, because the content is still indexed under the URL Google chose. Google's report guide says "Having a page marked duplicate or alternate is usually a good thing; it means that we've found the canonical page and indexed it" (Search Console Help).

Leave it alone when the listed URLs are:

• http:// or non-www copies of pages whose https:// or www version is indexed
• Sort, filter or tracking-parameter URLs of a page whose clean URL is indexed
• Print or other alternate views of an indexed article

Treat it as a problem when:

• The Google-selected canonical is a URL you don't want people to land on, such as a parameter URL or an old path.
• The listed URL is a page you meant to rank on its own, such as a location or product page, and Google folded it into another one.
• The Google-selected canonical sits on another domain you don't control.
• The count jumps after a release, which usually means a template or server change started creating new URL variants.

If you have dozens of client sites and want to know which preferred URLs Google has actually indexed before you dig in, check your URLs free.

What causes "Duplicate without user-selected canonical"?

The cause is always the same in principle: identical or near-identical content is reachable at more than one URL, and nothing on your site says which one counts. Google's canonicalization guide lists region variants, device variants, protocol variants, site functions such as sorting and filtering, and accidental variants such as a demo site left open to crawlers (Google Search Central).

Protocol, host and case variants

Protocol and host variants put the same page at several addresses. Google prefers https:// as canonical by default, and redirects from HTTP to HTTPS make that explicit (Google Search Central). Case matters too: Google says it "treats both /APPLE and /apple as distinct URLs with their own content" (URL structure best practices), so a server that answers both creates two URLs for one page.

Parameter, filter and tracking URLs

Parameter URLs create duplicates at scale. Google's help page names the pattern directly: sites that "use parameters to filter or sort a common collection (for example: type=dress or color=green or sort=price)" produce pages that "will be labeled as "duplicate" or "alternate" in the Page indexing report." Ad and campaign tags such as ?gclid= do the same; Google's own example is https://example.com/dresses/cocktail?gclid=ABCD (Google Search Central). Thousands of these also waste crawling, which can leave real pages stuck as discovered - currently not indexed.

Device and region copies

Separate mobile URLs (m-dot sites) and same-language regional pages are duplicates unless you connect them. For regional variants in one language, Google says to "use both canonicalization and hreflang" (Google Search Central). Translated pages count as duplicates only if the main content stays untranslated.

Near-identical templates

Near-identical templates matter most, because these are pages you wanted to rank. City or product pages that differ by a word or two can be clustered, and Google keeps one. Its advice for pages that shouldn't be clustered is that "you should ensure that the content differs substantially between the two pages" (Search Console Help). Thin near-duplicates that aren't clustered often end up as crawled - currently not indexed instead.

How do you confirm it with URL Inspection?

Confirm this status by opening an example URL from the report in Search Console's URL Inspection tool and reading the canonical fields in the indexed result.

1. Read "User-declared canonical". For this status it's normally empty or "None", which is why Google had to choose.
2. Read "Google-selected canonical". Google's help says "If you find an unexpected page here, consider explicitly declaring a canonical version" (URL Inspection tool help).
3. Inspect the Google-selected canonical itself and check it shows "URL is on Google".
4. Open both URLs in your browser and compare the main content. If they really are the same page, the status is correct.

Don't rely on Test live URL here. Google's help is explicit: "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." The Page indexing help adds that "duplicate or canonical conditions are not tested in the live test."

URL Inspection shows canonical details only "if the canonical version is in a property that you own". If the Google-selected canonical is on another site, Google's guide to fixing canonicalization issues lists the usual reasons: a misconfigured server, a hacked page inserting a cross-domain canonical, syndication, or a copycat site.

How do you fix "Duplicate without user-selected canonical"?

Fix this status by choosing one preferred URL per duplicate set and pointing every signal at it. Google ranks its methods by strength: redirects are "A strong signal", rel="canonical" link annotations are "A strong signal", and sitemap inclusion is "A weak signal" (Google Search Central). None of them is binding: "indicating a canonical preference is a hint, not a rule."

1. Pick the preferred URL for each duplicate set: HTTPS, one host, one case, one trailing-slash style, no parameters.
2. Redirect variants you want gone. Use server-side permanent redirects for http://, the other host, and old paths. Google says to use redirects "only when deprecating a duplicate page" and that "For the quickest effect, use HTTP (also known as server-side) redirects."
3. Declare a canonical on variants that must stay reachable, such as filter, sort and tracking URLs. Put an absolute URL in the <head>, and add the same tag to the preferred page itself:

<!-- On https://example.com/dresses/green-dresses?sort=price -->
<link rel="canonical" href="https://example.com/dresses/green-dresses" />

For PDFs and other non-HTML files, send the canonical as an HTTP header instead:

Link: <https://example.com/downloads/white-paper.pdf>; rel="canonical"

4. Make the other signals agree. List only preferred URLs in your sitemap and link to them internally. Google warns: "Don't specify different URLs as canonical for the same page using different canonicalization techniques."
5. Don't use robots.txt or the removal tool to canonicalize. Google says "Google may still index URLs that are disallowed in robots.txt without their content" and that the removal tool "hides all versions of a URL from Search." It also doesn't recommend noindex for choosing a canonical within one site; rel="canonical" is the preferred route.
6. Give paginated pages their own canonical. Google's ecommerce guidance says "Don't use the first page of a paginated sequence as the canonical page" (Pagination and Search).
7. If the pages aren't duplicates, make them different. Add the content that makes each page useful on its own, or merge them into one stronger page and redirect the rest.

How do you validate the fix?

Validate the fix by clicking Validate fix on the reason in the Page indexing report once every affected URL is fixed, then spot-check key URLs in URL Inspection. Google asks you not to click it again "until validation has succeeded or failed" and says validation "typically takes up to about two weeks, but in some cases can take much longer" (Search Console Help).

• Expect status moves, not "Indexed". A redirected variant should become "Page with redirect"; one whose canonical Google accepts, "Alternate page with proper canonical tag". Both mean the duplicate is handled.
• Allow for re-clustering. Google says that even after content fixes it "might hold pages in a duplicate cluster for up to two weeks" (Fix canonicalization issues).
• Validate a priority subset first. Google's tip is to submit a sitemap of your most important pages and filter the report by it before validating, because a smaller request "can complete faster."

When should you push the URL for a recrawl?

Push for a recrawl only for the preferred URL, only after the fix is live, and only if Google doesn't have it indexed yet. Pushing the duplicate itself does nothing useful, because Google "does not serve duplicate pages."

• A few important URLs: use Request indexing in URL Inspection. You must be an owner or full user, "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster" (Ask Google to recrawl). Google suggests reserving it "for your most important URLs."
• Many URLs: resubmit a sitemap of preferred URLs with accurate <lastmod> dates.
• Then wait and re-check. Google says crawling "can take anywhere from a few days to a few weeks."

Our guide to the ways to submit a URL to Google compares these routes, and how Google crawls and indexes pages covers the bigger picture. Across many sites, you can check which preferred URLs Google has indexed in one list, then push only the canonical URLs Google still can't see; FreshlyCited re-checks them on day 1, 3 and 7, and an index credit is used only if the link gets indexed. Google still decides what it indexes. For other ways to run the same check, see our overview of index-checking methods.

Fixed your canonicals? Check your own pages free to see which preferred URLs are seen by Google, push only the invisible ones, and get them re-checked.