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

The short version

• It isn’t an error. Google found the same page at more than one address. None of them named an original, so Google chose one to show in search and left the others out.
• The address in the list is a copy Google left out, not the page it kept.
• To see which page Google kept, inspect the address in Search Console and read “Google-selected canonical”.
• If that’s the page you want people to find, leave it alone.
• Fix it if Google kept the wrong page (name the original yourself, with a redirect or a canonical tag), or if the page isn’t really a copy (make it clearly different).
• Don’t use noindex or robots.txt to sort it out. Google advises against both for this.

What “Duplicate without user-selected canonical” means

Google’s help page for the Page indexing report defines it in two sentences: "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."

Three words in that need translating:

• Duplicate. Google’s Duplicate URL help page says: "When Google finds multiple URLs on the same site that show essentially the same page contents, it considers these URLs to be duplicates." Essentially the same, not identical: its own example is a list of dresses grouped by size, and the same dresses grouped by colour.
• Canonical. Google’s word for the original: the one address, out of several showing the same thing, that it puts in search results.
• User-selected. The “user” is you, the site owner, not your visitors. The help page tells you to "Look at the canonical you chose under Page indexing > User-declared canonical." So “without user-selected canonical” means your page didn’t say which address is the original.

That last part is what separates it from its two look-alikes. If the copy does name the original and Google agrees, the status is “Alternate page with proper canonical tag”, which needs nothing doing; we wrote up what that status means, using our own homepage. If you named an original and Google chose a different page, it’s “Duplicate, Google chose different canonical than user”: "This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical." That one is more worth a look, because Google disagreed with you.

Is it a problem?

Usually not, as Google’s line at the top of this post says. The help page’s advice on reading the report says the same thing from the other side: "Remember that duplicate URLs shouldn't be indexed." And a duplicate is on its list of good reasons for a page to be missing from Google: "It's fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you've removed and have no replacement for."

It isn’t against Google’s rules either. Google’s guide to canonicalization says: "Some duplicate content on a site is normal and it's not a violation of Google's spam policies."

The help page names the two cases where it does matter:

• Google kept the wrong page. "However, if you think that Google has chosen the wrong URL as canonical, you can explicitly mark the canonical for this page."
• The page isn’t really a copy. "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."

How to see which page Google kept

1. In Search Console, open the Page indexing report. In the table of reasons pages aren’t indexed, click “Duplicate without user-selected canonical”. The help page: "Click a row to see a details page that shows URLs affected by this issue".
2. Pick an address from the list and inspect it with the URL Inspection tool.
3. Open the Page indexing section and read two lines. “User-declared canonical” is what your page says; Google’s help for the tool says "If your page explicitly declares a canonical URL, it will be shown here." For this status there shouldn’t be one, because that’s what “without user-selected canonical” means. “Google-selected canonical” is the page Google kept.
4. Open both addresses in your browser. Is the kept page the one you want people to find? Are the two really the same page?

Read the indexed result, not “Test live URL”. Google’s help for the tool says: "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."

Where duplicates come from

Google’s canonicalization guide lists the usual ways a site ends up with the same page at several addresses, including:

• "Protocol variants: for example, the HTTP and HTTPS versions of a site"
• "Site functions: for example, the results of sorting and filtering functions of a category page"
• "Device variants: for example, a page with both a mobile and a desktop version"
• "Accidental variants: for example, the demo version of the site is accidentally left accessible to crawlers"

Two more turned up on our own site, below: the same address with and without a slash on the end, and anything added after a question mark, such as the tracking tags that ads and newsletters put on links. Google’s canonical how-to uses one of those as its own example: a dress page reached through an address ending in ?gclid=ABCD, a tracking tag.

What we found on our own site

On 25 October 2026 we ran Google’s URL Inspection tool, through the Search Console API, over all 149 addresses in our sitemap, once in the afternoon and again at night. On 27 October 2026, the morning we published, we ran it again over all 150 (we had added a post in between). None of them has this status. Wherever Google said which page it had chosen as the original, it chose the page itself.

That isn’t because we have no copies. Our pages answer at more than one address. We fetched and inspected a few of them that night, and again the morning we published, with the same results:

Three things keep those copies out of this status.

• Every page names itself as the original. We fetched all 150, and each carries one line naming its own address, for example <link rel="canonical" href="https://www.lolasquared.com/blog-is-copilot-free">. Google recommends a canonical link "on the canonical page itself (also known as a self-referential canonical)". A copy is the same page, so it carries the same line and points back to the original.
• The no-www and http addresses redirect. They don’t show a copy at all; they send you to the original.
• Our own links only use the originals. We checked all 3,773 links from our pages to other pages of ours, and every one points at an address in our sitemap. Google’s how-to: "When linking within your site, link to the canonical URL rather than a duplicate URL."

The one copy Google has found, /index.html, went into the harmless status, “Alternative page with proper canonical tag” (the British English wording of “Alternate”). We’d expect the others to land there too if Google ever comes across them. It hasn’t, so we can’t show it.

How to fix it, when it needs fixing

Google’s canonical how-to lists the ways to name the original "in order of how strongly they can influence canonicalization": a redirect, a canonical tag, and listing the page in your sitemap. Which one fits depends on why the copy exists:

• The copy has no reason to exist (an old address, the http version, a demo site left open). Redirect it to the original. Google’s advice on redirects: "Use this only when deprecating a duplicate page."
• The copy has to stay (a sorted or filtered list, an address with a tracking tag). Add a canonical tag to it naming the original, and put the same kind of line on the original naming itself.
• It isn’t a copy at all. Make the two pages clearly different. In the help page’s words, "ensure that the content differs substantially between the two pages."

The methods add up: "Keep in mind that these methods can stack and thus become more effective when combined." On WordPress, Wix and similar systems you usually don’t write the tag yourself: "your CMS might have a search engine settings page or some other mechanism to tell search engines about the canonical URL."

Then give Google time. Its troubleshooting guide says: "Even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks." You can ask it to look again with Request Indexing in the URL Inspection tool, but "since this feature is subject to quotas, reserve it for your most important URLs." How long Google takes to come back to a page is its own question; our post on when Google looks at a page again has our measured examples.

What not to do

• Don’t noindex the copies. "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 block them in robots.txt. "Don't use the robots.txt file for canonicalization purposes." The reason Google gives: "Google may still index URLs that are disallowed in robots.txt without their content."
• Don’t use the removal tool. "Don't use the URL removal tool for canonicalization. It hides all versions of a URL from Search."

What the guides on page one say

We read the nine results we saw for this search in full. (Our search tool shows US results, so the British page one may differ.) Six have “fix” or “fixes” in the title, for a status Google says is working as intended. Two of the nine say that Google calls it not an error, and one of those links to Google’s help page.

Several also suggest a noindex tag. One guide, last updated in November 2025, has as a step "Use Noindex Robots Tag for all the duplicate web pages", and says "When you find any web page as duplicate, make sure the web page is marked ‘noindex’ in robots tag". That is the opposite of Google’s advice above.

To be fair to the guides, noindex is the right tool for a page that should never be in Google at all, such as a basket page, and Google’s help page lists "a noindex tag on the page" among the good reasons for a page not to be indexed. What Google advises against is using it to choose between copies.

What argues the other way

• A big site is different. A shop with thousands of filtered pages can have thousands of these. Each one is fine, but Google gives "To avoid spending crawling time on duplicate pages" as a reason to name the original, so a very large count is worth tidying.
• Google can overrule you. Naming the original makes Google’s choice likelier, not certain. In the canonicalization guide’s words, "indicating a canonical preference is a hint, not a rule."
• We have no example. Our site has none of these, so this post rests on Google’s own pages and on our copies staying out of the status. A site built on a different system may behave differently.
• The labels move. A page’s status in Search Console can change between checks without Google crawling it again. The crawl date is the steadier figure.
• We have an interest. We build websites for small businesses, and our own site is the example, so it suits us that it looks tidy. The statuses are as Google’s tool reported them.

Sources, and what we checked

• Google Search Console Help: Page indexing report (the definitions of the statuses), Duplicate URL and URL Inspection tool.
• Google Search Central: What is URL canonicalization (last updated 20 August 2026), How to specify a canonical URL with rel="canonical" and other methods (last updated 10 July 2026) and Fix canonicalization issues (last updated 21 August 2026).
• Our own site: Google’s URL Inspection tool, run through the Search Console API in British English over all 149 addresses in our sitemap twice on 25 October 2026, and over all 150 on 27 October 2026, the morning we published; the copies in the table fetched and inspected on both days; all 150 pages fetched that morning to check the line naming the original, and the links between them counted.
• Page one: the nine results for this search, seen through a US search tool, each read in full on 25 October 2026.
• Google’s pages above were read on 25 October 2026, and again on 27 October 2026, the morning we published. Nothing we quote had changed.
• Every quotation above was tested automatically against the text of its source before publication.