What Does "Duplicate Without User-Selected Canonical" Mean?

What "Duplicate without user-selected canonical" means

The status sits in the "Not indexed" section of the Page indexing report. Google describes it in one sentence: the page is a duplicate of another page, and it does not indicate a preferred canonical page. ^{[1]Google Search Console Help. Page indexing report} Because of that, Google has chosen the other page as the canonical and will not serve this page in Search. ^{[1]Google Search Console Help. Page indexing report} Google adds that this is not an error but is working as intended, because it does not serve duplicate pages. ^{[1]Google Search Console Help. Page indexing report}

Three facts are packed into that label, and each one matters for what you do next:

Canonicalization is Google's process of selecting the representative URL for a piece of content: it groups pages whose primary content is the same or very similar into a cluster, then picks the one its signals suggest is the most complete and useful for search users. ^{[2]Google Search Central. What is URL canonicalization} The non-canonical members of the cluster are not simply ignored; they are crawled less often to reduce the load on your site, and a search result usually points to the canonical page. ^{[2]Google Search Central. What is URL canonicalization}

The signals Google weighs include whether the page is served over HTTP or HTTPS, redirects, whether the URL is in a sitemap, and rel="canonical" annotations. ^{[2]Google Search Central. What is URL canonicalization} With this status, the page itself contributed none of the strong ones, so Google decided from the rest.

When to fix it and when to leave it

Google's own guidance gives two conditions for acting: if you think Google picked the wrong canonical, mark the canonical explicitly; if you think the page is not really a duplicate, make its content differ substantially from the other page. ^{[1]Google Search Console Help. Page indexing report} Outside those two cases, there is nothing to fix.

The last two rows are the same decision described in merge or redirect competing pages. Google ranks the methods by strength: a redirect is a strong signal that its target should become canonical, a rel="canonical" annotation is a strong signal that the specified URL should become canonical, and inclusion in a sitemap is only a weak one. ^{[3]Google Search Central. How to specify a canonical with rel="canonical" and other methods} Any preference you state is a hint, not a rule. ^{[2]Google Search Central. What is URL canonicalization}

This status is the quiet cousin of keyword cannibalization. When two URLs are near-duplicates, Google folds one into the other and you see this label. When they are similar but not similar enough to fold, both stay indexed and compete for the same queries, which is the internal cannibalization pattern the Performance report shows as two pages trading positions. A site with many "Duplicate without user-selected canonical" URLs usually has the second problem too; the Keyword Cannibalization Checker reads Search Console data to list the page pairs that compete on the same queries, with a merge, canonical, de-optimize or differentiate recommendation for each.

Example: one category page, three URLs

The table below is constructed to illustrate the pattern. Each row is a URL as it appears in the Page indexing report and URL Inspection, with 28 days of clicks from the Performance report.

Rows two and three are the status working as intended: the sort and tracking variants duplicate the clean category URL, Google chose the clean URL, and nothing needs doing beyond adding a self-referencing canonical on row one so the choice is explicit. Their zero clicks are not a loss. Click, impression and position data for all variations of a page are assigned to the canonical URL Google selects, so the 1,240 clicks on row one already include any visits that arrived on the variants. ^{[5]Google Search Console Help. What are impressions, position, and clicks?}

Row four is the one to look at. It shares most of its text with row one, but Google did not fold it, so both URLs are indexed and both can appear for "running shoes". That is not a Page indexing problem; it is a cannibalization problem, and it shows up in the Performance report as two pages splitting impressions for one query. The cannibalization examples post walks through this exact category-versus-guide case.

How to check it and fix it

1. Open the Page indexing report, click "Duplicate without user-selected canonical" under "Why pages aren't indexed", and export the example URLs.
2. Inspect each URL with the URL Inspection tool. The "Google-selected canonical" field shows the page Google chose as authoritative when it found similar pages on your site; "User-declared canonical" shows what the page itself declares, and "None" is expected here. ^{[4]Google Search Console Help. URL Inspection Tool} The Google-selected value can lag the index by a few hours. ^{[4]Google Search Console Help. URL Inspection Tool}
3. Compare the two in your browser. If Google's choice is the URL you want, stop.
4. If not, add <link rel="canonical"> on the duplicate pointing to the preferred URL, using an absolute URL, and keep a self-referencing canonical on the preferred page. ^{[3]Google Search Central. How to specify a canonical with rel="canonical" and other methods} Use a 301 redirect instead when the duplicate has no reason to exist. Do not use robots.txt for canonicalization, and do not rely on noindex to steer Google's choice within one site. ^{[3]Google Search Central. How to specify a canonical with rel="canonical" and other methods}
5. Request indexing of the preferred URL if it is new. A request does not guarantee the page will be indexed, and the live test cannot predict whether a URL will be treated as canonical. ^{[4]Google Search Console Help. URL Inspection Tool}
6. Re-inspect after the next crawl. The full decision path, with the five possible fixes, is in how to fix keyword cannibalization.

The thing people get wrong

"Not indexed" is read as "broken", and every URL under this status gets a redirect or a noindex. Google says the opposite: non-indexed URLs can be fine, and this status is Google serving the version it judged most useful instead of a copy. ^{[1]Google Search Console Help. Page indexing report} The only question is whether its choice is yours. Fixing a correct choice can demote the page that was earning the traffic.

The mirror mistake is treating a self-referencing canonical as unnecessary. Google asks for one on the canonical page itself, and without it the preferred URL is competing on the same weak footing as its variants. ^{[3]Google Search Central. How to specify a canonical with rel="canonical" and other methods}

Duplicate without user-selected canonical vs the other duplicate statuses

The second row is the stricter signal. Google's note on it is that if the user-declared canonical is not similar to the current page, Google will never choose that URL as canonical, which is why a canonical only works between true duplicates. ^{[1]Google Search Console Help. Page indexing report} A keyword map that assigns one URL per query is the simplest way to keep near-duplicates from reaching either row.

Where the report can mislead

The report shows example URLs, not necessarily every affected URL, so a count that drops after a fix is a trend, not a proof. Validation of a fix typically takes up to about two weeks. ^{[1]Google Search Console Help. Page indexing report} Because Google prefers HTTPS pages over equivalent HTTP pages and prefers URLs that are part of hreflang clusters, a protocol or language variant can land in this status without any content change on your side. ^{[3]Google Search Central. How to specify a canonical with rel="canonical" and other methods} And since all performance data goes to the canonical, a duplicate's average position and CTR are not merely low; they do not exist as separate rows, so a zero here is not evidence of anything. ^{[5]Google Search Console Help. What are impressions, position, and clicks?} Read the status next to URL Inspection, never on its own.