"Duplicate Without User-Selected Canonical": Why Google Chose a Different URL and How to Fix It

“Duplicate without user-selected canonical” is a Page Indexing status in Search Console that means Google found a URL it considers a duplicate of another page, saw no canonical declared on it, and picked the canonical itself. The URL you are looking at is the one Google decided not to serve.

This article is part of a series on Search Console statuses, alongside alternate page with proper canonical tag. It covers what the status means, how to confirm it in URL Inspection, a diagnosis tree for the four causes that produce almost every row (no canonical set, conflicting signals, parameter duplicates, and protocol or host duplicates), and the fix for each one. The protocol example uses this site’s own redirects, pulled from a real crawl.

Key takeaways

• The status is not an error. Google’s Page Indexing documentation calls it “working as intended, because Google does not serve duplicate pages”. It only matters when the URL Google dropped is the one you wanted.
• “User-selected” means you. The page carried no canonical preference Google could use, so Google chose between the duplicates on its own signals.
• Diagnose from the indexed data, not the live test. Google says duplicate or canonical conditions are not tested in the live test.
• Four causes cover almost every case: no canonical at all, canonical signals that contradict each other, parameter URLs, and http/https or www/non-www duplicates. Each has a different fix.
• Fix the rule that generates the duplicates, not the row. A redirect rule or template change clears hundreds of URLs at once.

What “duplicate without user-selected canonical” means

Google’s definition is short: “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.”

Two facts sit inside that sentence. First, Google has clustered this URL with at least one other URL it thinks carries the same content. Second, nothing on this URL told Google which member of the cluster you prefer, so Google made the call.

That call follows a process Google documents in what is canonicalization. It clusters pages whose primary content looks the same, then chooses the one that is “objectively the most complete and useful for search users” based on signals such as HTTPS versus HTTP, redirects, sitemap inclusion and rel="canonical" annotations. The page is reported as duplicate because it lost that choice.

Where it sits in the Page Indexing report

The status is listed under “Why pages aren’t indexed”. Google files those reasons as not indexed “but not necessarily because of an error”, and for this one it spells out the reassurance: the status is not an error. Google also says that if you think it chose the wrong URL, you can explicitly mark the canonical, and if you think the page is not a duplicate at all, you “should ensure that the content differs substantially between the two pages.”

That gives you the only two questions that matter. Did Google pick the right URL? And is this page really a duplicate?

How it differs from the other canonical statuses

Four statuses in the report describe canonical outcomes. They are easy to mix up, and each has a different fix.

Status	What happened	Usual action
Duplicate without user-selected canonical	Duplicate found, no canonical declared, Google chose one	Check Google’s choice; declare or enforce a canonical if it is wrong
Duplicate, Google chose different canonical than user	You declared a canonical, Google picked another URL	Find out why your declared canonical lost
Alternate page with proper canonical tag	You declared a canonical, Google agreed	Usually nothing
Page with redirect	The URL redirects, so it is not indexed	Nothing, if the redirect is intended

The definitions come from Google’s Page Indexing report help. The sibling status alternate page with proper canonical tag is the healthy version of this one: the same duplication, but with a canonical you set and Google accepted.

The practical difference: this status points at a missing instruction, not a rejected one, so the first fix is usually to give Google an instruction it can use.

Step one: confirm the status in URL Inspection

Before changing anything, read what Google decided for one affected URL.

1. Open the status and inspect a sample URL. In Page indexing, open “Duplicate without user-selected canonical” and click the inspect icon next to one row.
2. Read “User-declared canonical”. On a URL in this status it is normally empty or None. Google’s URL Inspection help says None is fine when a page is not a duplicate, and that if the page is one of a set of similar or duplicate pages, “we recommend explicitly declaring the canonical URL.”
3. Read “Google-selected canonical”. This is the URL Google indexed in place of the one you inspected. Google notes that “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.”
4. Open both URLs in a browser. Compare them. If the Google-selected URL is the one you would have chosen, the status is correct and the only remaining question is whether to tidy up the duplicate.

Do not use “Test live URL” to judge this status. The Page Indexing help says the live test does not test all the issues in the report, and “most notably, duplicate or canonical conditions are not tested in the live test.”

The diagnosis tree

Once you have one inspected URL and its Google-selected canonical, the cause is almost always visible from the difference between the two URLs and from the page source. Work down this tree.

Duplicate without user-selected canonical
│
├─ Is the Google-selected canonical the URL you want indexed?
│   ├─ Yes → Status is correct. Optional tidy-up: redirect or canonicalise the duplicate.
│   └─ No  → continue
│
├─ Do the two URLs differ only in protocol or host?
│   (http vs https, www vs non-www)
│   └─ Yes → Cause 4: protocol/host duplicates. Fix with one 301 rule per host.
│
├─ Do they differ only in a query string?
│   (?utm_, ?gclid=, ?sort=, ?ref=, session IDs)
│   └─ Yes → Cause 3: parameter duplicates. Canonical on the template, clean internal links.
│
├─ View source on the inspected URL: is there a rel="canonical" in the <head>?
│   ├─ No  → Cause 1: no canonical set. Add an absolute self-referencing canonical.
│   └─ Yes → Cause 2: conflicting signals. Canonical, sitemap, links and redirects disagree.
│
└─ None of the above, and the content really is near-identical?
    └─ Differentiate the pages, or consolidate them with a 301.

Protocol and parameter duplicates come first because they are recognisable from the URL alone, and one rule produced every row that shares the pattern.

Cause 1: no canonical set

The plainest version of the status is exactly what its name says: the page has no rel="canonical", so there is no user-selected canonical. Google treats declaring one as optional. Its canonical documentation says that without one, Google “will identify which version of the URL is objectively the best version to show to users in Search”, and your site “will likely do just fine without specifying a canonical preference.”

It stops being fine when Google’s pick is not yours.

The fix is a self-referencing canonical on every indexable page, emitted by the template rather than typed per page. Google says to include a rel="canonical" link on the canonical page itself, to use absolute URLs rather than relative paths, and that the element is only accepted in the <head>.

<!-- On https://example.com/guides/duplicate-content/ -->
<head>
  <link rel="canonical" href="https://example.com/guides/duplicate-content/" />
</head>

On this site, the layout builds the canonical from the site’s configured origin and the page path, so every page emits an absolute HTTPS canonical on the apex host whatever URL variant was requested. That one line in the layout is why a stray http:// or www. request can never declare itself canonical. For the full mechanics of the element, including cross-domain and HTTP header canonicals, see the canonical tags guide.

For PDFs and other non-HTML files, which often land in this status as duplicates of an HTML page, Google supports a rel="canonical" HTTP header instead:

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

Cause 2: conflicting canonical signals

The second cause is a canonical that exists but is drowned out, or several signals that point at different URLs. Google ranks the methods by strength: redirects and rel="canonical" are strong signals, sitemap inclusion is a weak one, and the methods stack when they agree.

When they disagree, Google has no clear preference to follow. The usual conflicts are:

• Sitemap versus tag. Google’s best practices say not to specify different URLs as canonical for the same page through different techniques, for example one URL in the sitemap and another in rel="canonical".
• Internal links to the duplicate. Google asks you to link to the canonical URL rather than a duplicate, because consistent linking “helps Google understand your preference.” A navigation that links to /Products/ while the canonical says /products/ is arguing with itself.
• JavaScript rewriting the canonical. Google’s advice is to set the canonical in the HTML source and make sure JavaScript does not change it. If you cannot set it in the source, leave it out and set it only with JavaScript. The rendering side of this is covered in JavaScript SEO.
• Two emitters. Two SEO plugins, or a plugin plus a theme, each writing a canonical. Google also warns that sending a canonical both as an HTTP header and as a link element is “more error prone”, because the two can name different URLs.
• A canonical outside the <head>. A page builder that injects the element into the body produces a tag Google does not accept, which from Google’s side looks like no canonical at all.

The fix is to make every signal name the same URL: one canonical element in the <head>, the same URL in the sitemap, the same URL in internal links, and redirects that land on it. Check the rendered HTML, not the template, and count the canonical elements. There should be exactly one.

Cause 3: parameter duplicates

Query strings are the most common generator of this status at scale, because every parameter value creates a new URL with the same content. Google’s URL structure guidance lists referral parameters, sorting parameters and session IDs as irrelevant parameters that “can cause a large number of URLs”, and recommends trimming parameters that do not change the content.

Google’s own canonical documentation uses an ad-click parameter as its example: you might prefer people reach https://www.example.com/dresses/green/green-dress.html rather than https://example.com/dresses/cocktail?gclid=ABCD. When the parameter URL has no canonical, it is exactly the kind of row this status fills with.

The version that catches teams out is self-inflicted: a UTM tag on an internal link in a header, footer or banner. Your own template is then minting the duplicate on every page view that follows the link.

The fix has three parts:

1. Canonical on the template. The page template emits a canonical to the parameter-free URL, whatever query string arrives. Because the canonical is built from the path rather than the full request URL, every ?utm_source=, ?gclid= and ?sort= variant points at the clean URL.
2. Clean internal links. Remove tracking parameters from internal links. Campaign tagging belongs on links from other sites and emails, not on links between your own pages.
3. Faceted navigation. If the parameters come from filters that combine, the count can grow faster than any canonical tidies it. Google has separate guidance on managing crawling of faceted navigation URLs, and the crawl cost is covered in crawl budget.

Do not block parameter URLs in robots.txt as a canonicalisation method. Google’s best practices say not to use robots.txt for canonicalisation, because it may still index URLs that are disallowed without their content. A blocked URL also cannot show Google its canonical tag.

Cause 4: http/https and www duplicates

Protocol and host variants are the oldest cause and the easiest to fix for good. Google names protocol variants, “the HTTP and HTTPS versions of a site”, as one of the standard reasons a site has duplicate content. If http://example.com/page/, https://example.com/page/ and https://www.example.com/page/ all return 200 with the same content and no canonical, you have three members of one cluster and Google will choose.

Google prefers HTTPS over HTTP by default, unless the HTTPS page has an invalid certificate, insecure dependencies, redirects through HTTP, or a canonical pointing at the HTTP page. So when the HTTP version wins, look for one of those conflicts first.

What the fix looks like: this site’s own crawl

Here is the redirect layer for nadiamohamed.me as recorded by an Ahrefs Site Audit crawl on 18 September 2026. The crawl covered both protocols and all subdomains, and these were the only URLs it recorded with a 3xx status:

Requested URL	Status	Redirects to	Target status
http://nadiamohamed.me/	301	https://nadiamohamed.me/	200
https://www.nadiamohamed.me/	301	https://nadiamohamed.me/	200
http://www.nadiamohamed.me/	301	https://www.nadiamohamed.me/	301

The final URL, https://nadiamohamed.me/, returned 200 in the same crawl with a canonical of https://nadiamohamed.me/.

Three things are worth reading from that table.

• Every variant is a permanent redirect. Google’s redirects documentation says the indexing pipeline uses a permanent redirect “as a signal that the redirect target should be canonical”, while a temporary redirect is not used that way. A 302 here would leave the choice open.
• The variants never return content. Because each one redirects, Search Console files them, if at all, as “Page with redirect” rather than as duplicates. There is no cluster for Google to choose from.
• One path takes two hops. http://www. goes to https://www. first, then to the apex. It still ends at the right URL with 301s all the way, so it consolidates correctly. It is still one more request than needed, and the tidier rule sends every variant to the final URL in one hop.

Two-hop chains like this usually appear when the HTTPS upgrade and the domain redirect are applied by separate layers. The fix is a single rule per host that names the final URL.

One-hop rules for nginx and Apache

For nginx, send every non-canonical protocol and host combination straight to the final origin:

# http on either host → https apex, one hop
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# https www → https apex
server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate and ssl_certificate_key for www.example.com go here
    return 301 https://example.com$request_uri;
}

For Apache with mod_rewrite:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Both preserve the path and query string, so deep links keep working. Then add HSTS once you are sure HTTPS is permanent, which Google lists alongside redirects as a way to ensure HTTPS is preferred. Check the certificate covers every host you redirect from, because Google warns against certificates issued for the wrong host variant.

The wider redirect decisions, including when a 301 is the wrong tool, are in the SEO redirects guide.

When the pages really are duplicates

Sometimes none of the four causes applies. The URLs differ in their path, both carry a self-canonical, and Google still folds one into the other because the primary content is near-identical: two location pages from the same template, a tag archive that repeats a category, or a print version.

Google’s own advice for this case is in the status definition: if the page is not a duplicate, ensure the content differs substantially. If it is a duplicate, pick the better page and 301 the other into it. Its troubleshooting guide adds that fixing canonicalisation issues “technically boils down to ensuring that the pages that are clustered together are sufficiently different.”

The same guide lists rarer causes worth ruling out when the Google-selected canonical is on another domain: a misconfigured server returning one site’s content for another host, identical soft 404 pages on unrelated servers, syndicated copies, copycat sites and hacked sites inserting cross-domain canonicals. If the chosen URL is on a domain you do not recognise, treat it as a security check before an SEO one. Error pages that return 200 are covered in the soft 404 guide.

Do not reach for noindex to force a choice between duplicates. Google says it does not recommend noindex to prevent selection of a canonical within a site, because it completely blocks the page from Search. The trade-off between the two directives is set out in canonical vs noindex.

The fix for each cause

Cause	How to recognise it	Fix
No canonical set	No rel="canonical" in the rendered <head>	Absolute self-referencing canonical from the template
Conflicting signals	Canonical exists, but sitemap, links, redirects or a second tag name another URL	Make every signal name one URL; one canonical element
Parameter duplicates	URLs differ only by query string	Canonical to the parameter-free URL; strip parameters from internal links
Protocol or host duplicates	URLs differ only by http/https or www	One-hop 301 per variant to the final origin; HSTS
Real near-duplicates	Different paths, near-identical content	Differentiate the pages, or 301 the weaker into the stronger

Checking canonicals and redirects on a schedule, rather than after a report grows, is one line in the technical SEO audit checklist.

After the fix: validation and timing

Once the rule is live, tell Google and then wait.

• Validate the fix. Use “Validate fix” on the status in the Page Indexing report. Google says the process can take several days or even longer and sends progress by email.
• Expect the cluster to hold for a while. Google’s troubleshooting guide says it may keep pages in a duplicate cluster for up to two weeks, and that pages split out faster when the difference from the rest of the cluster is “clear and significant.”
• Request indexing sparingly. Request Indexing is subject to quotas, so save it for your most important URLs. For many updated pages, Google’s URL Inspection help points to a sitemap with updated <lastmod> values instead.

Verify the result the way you diagnosed it: inspect the URL again and confirm the Google-selected canonical is now the URL you intended. Recheck after any site migration, because new URL rules are the usual way this status comes back.

If you would rather have the canonical and redirect layer audited and monitored than fixed one status at a time, that is part of technical SEO consulting.

Frequently asked questions

Is “duplicate without user-selected canonical” bad for SEO?

Not by itself. Google describes it as working as intended, because Google does not serve duplicate pages. It only costs you something when the URL Google dropped is the one you wanted to rank, which you can check in URL Inspection under “Google-selected canonical”.

How do I fix “duplicate without user-selected canonical”?

Inspect one affected URL, compare it with the Google-selected canonical, and identify which of the four causes applies: no canonical, conflicting signals, parameter URLs, or http/https and www variants. Then fix the rule behind it: add a template-level self-canonical, align your sitemap and internal links, strip internal tracking parameters, or add one-hop 301 redirects to your final origin.

Should I add a canonical tag to every page?

Yes, on every indexable page. Google recommends a self-referential canonical on the canonical page itself, with an absolute URL in the <head>. Emit it from the template so every URL variant, including parameter and protocol variants, points at the same clean URL.

Why did Google choose the http version or a parameter URL as canonical?

Usually because signals point there. Google prefers HTTPS by default, but conflicting signals such as an HTTPS page redirecting through HTTP, an HTTP URL in the sitemap, or a canonical pointing at HTTP can reverse that. For parameter URLs, check whether your own internal links carry the parameter.

How long does it take for the status to clear?

Expect days to weeks. Google says validation can take several days or even longer, and that pages may stay in a duplicate cluster for up to two weeks after the fix. Confirm with URL Inspection that the Google-selected canonical has changed before you edit anything else.

Can I use noindex or robots.txt instead of a canonical?

Neither is a canonicalisation tool. Google advises against using robots.txt for canonicalisation because disallowed URLs can still be indexed without their content, and does not recommend noindex for choosing between duplicates because it removes the page from Search entirely. Use rel="canonical" or a 301 redirect instead.