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

Updated 26 October 2026

Search Console lists a URL as Duplicate without user-selected canonical when Google found the same content at another URL and neither page says which one should be indexed. Google's help page: "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."

The same page adds: "This is not an error, but is working as intended, because Google does not serve duplicate pages." The listed URL is left out and the one Google chose is indexed. Often that is the URL you would have picked anyway.

Step 1: decide whether it is a problem

Run URL Inspection on a URL from the report. Under Page indexing, compare User-declared canonical (empty for this status) with Google-selected canonical, the URL Google indexes instead.

• Google's pick is the URL you want in search, for example the https version or the URL without a tracking parameter: leave it. Duplicates are not a penalty. Google's canonicalization docs say "Some duplicate content on a site is normal and it's not a violation of Google's spam policies."
• Google picked a URL you don't want: an http URL, a parameter or print version, the product under a sale category instead of its main path. Fix the signals below.
• The listed page is not really a duplicate: two location pages or product variants with the same text and a different name. Google's advice is to "ensure that the content differs substantially between the two pages."

A handful of parameter URLs in this report is normal on most sites. Look for patterns, not single URLs: hundreds of ?sort= URLs, or every page doubled with and without www.

Step 2: find out why the duplicate exists

Step 3: fix it, strongest signal first

Google's page on consolidating duplicate URLs lists the methods "in order of how strongly they can influence canonicalization":

1. Redirects: "A strong signal that the target of the redirect should become canonical." Use a 301 for URLs nobody needs: the http, www and slash variants. After the fix those URLs move to Page with redirect, which is fine.
2. rel="canonical": "A strong signal that the specified URL should become canonical." Use it for URLs that must keep working, such as parameters and extra category paths. Put a self-referencing canonical on the page you want indexed too; Google's docs recommend it.
3. Sitemap: "A weak signal", but Google says the methods "can stack and thus become more effective when combined." List only the URL you want indexed, and point internal links at it as well.

Three things not to do, all from the same Google page:

• "Don't use the robots.txt file for canonicalization purposes." A blocked URL can't be crawled, so Google never sees its canonical.
• "We don't recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search."
• "Don't specify different URLs as canonical for the same page using different canonicalization techniques." A sitemap that lists /a/ while the tag says /a is a mixed signal.

WordPress: archives have no canonical without a plugin

WordPress core writes a canonical only on single posts, pages, attachments and custom post type entries. Its developer reference for rel_canonical() says it "Outputs rel=canonical for singular queries." The blog home, category, tag, author and date archives and search results get none from core; SEO plugins usually add them.

So when the report lists archive URLs, check one with the canonical checker. If it says "No canonical found", the site has no plugin that writes canonicals for archives, or the setting is off. Posts opened with a tracking parameter are a different case: core builds the canonical from the permalink, so /post/?utm_source=x points to /post/ and shows up as Alternate page with proper canonical tag. Google says of that status: "there is nothing you need to do."

Next.js: no canonical unless you set one

Next.js adds only the charset and viewport meta tags to a route that defines no metadata. A canonical comes from alternates.canonical in metadata or generateMetadata. Two consequences:

• Routes without it have no canonical, so every parameter variant can end up in this report.
• Child routes inherit metadata fields they don't set. An alternates.canonical: '/' in the root layout gives every page without its own alternates a canonical to the home page. Those pages then fall out of the index or show as Google chose different canonical than user.

Set the canonical per route, with metadataBase in the root layout so relative paths become absolute URLs:

Trailing slashes are handled separately: by default Next.js redirects /about/ to /about, so slash variants show as Page with redirect, not as duplicates.

Step 4: check the fix and validate

Run the canonical checker on the URL Google listed and on the one you want indexed. The duplicate should redirect or point to the keeper; the keeper should point to itself. Then click Validate Fix in the Page indexing report. Google says validation "typically takes up to about two weeks, but in some cases can take much longer".

Sources: Google Search Console Help, Page indexing report; Google Search Central documentation on consolidating duplicate URLs and on canonicalization; WordPress developer reference, rel_canonical(); Next.js documentation, generateMetadata and trailingSlash. Related: Google chose different canonical than user · Page with redirect.