Duplicate without user-selected canonical: what it means and when to fix it
What "Duplicate without user-selected canonical" and "Alternate page with proper canonical tag" mean in Search Console, and which ones need fixing.
The Page indexing report in Google Search Console lists pages that are not indexed alongside the reason. Three of those reasons are about canonicalisation, which is how Google chooses one URL to index when it finds several that show the same content. They look alarming in a report headed "Why pages aren't indexed". Usually only one of them needs action.
The short version: "Alternate page with proper canonical tag" is almost always fine. "Duplicate without user-selected canonical" means you left Google to choose, and it is worth fixing when it affects pages that matter. "Duplicate, Google chose different canonical than user" means Google disagreed with you, and that is the one to investigate first.
How Google chooses a canonical
When Google finds several URLs with the same or very similar content, it groups them and indexes one, the canonical. The others are not penalised. They are treated as alternates, and their signals, such as links, largely consolidate onto the canonical.
Your rel=canonical tag is a strong hint, not a command. Google also weighs redirects, which URLs appear in your XML sitemap, which URLs your internal links point to, HTTPS over HTTP, and cleaner URLs over ones with parameters. When those signals agree, Google almost always follows your canonical. When they conflict, for example a canonical pointing at URL A while your navigation and sitemap point at URL B, Google may pick B.
The three statuses, and what each one means
Each status describes a different relationship between what you declared and what Google decided.
| Status | What happened | Action |
|---|---|---|
| Alternate page with proper canonical tag | This URL declares another URL as canonical, and Google agreed | Usually none. This is canonicals working as intended |
| Duplicate without user-selected canonical | Google found this URL duplicates another, no canonical was declared, and Google chose a different URL | Declare canonicals on the affected templates, or make the pages genuinely distinct |
| Duplicate, Google chose different canonical than user | You declared a canonical, and Google ignored it and chose another URL | Investigate. Your signals conflict, or the pages are not the duplicates you think |
Alternate page with proper canonical tag: usually leave it
This status confirms that a page points to a canonical elsewhere and Google respected it. On most sites it is populated by exactly the URLs you would expect: tracking parameter variants, sorted and filtered listing pages, and on Shopify, the /collections/…/products/… paths that Shopify canonicalises to the plain /products/ URL.
Two situations deserve a second look. First, if a page you want in search results appears here, it has a canonical pointing elsewhere, usually from a template bug, such as paginated category pages canonicalising to page 1. Second, if the count is enormous relative to your real page count, the canonicals are working but your site is generating too many duplicate URLs, and each one still costs a crawl. The fix for that is to stop generating and linking the URLs, not to change the canonicals.
Duplicate without user-selected canonical: how to fix it
Use the URL Inspection tool on a few examples. It shows the Google-selected canonical for each, which tells you which URL Google treated as the original. The pattern is usually obvious once you look at five or six examples side by side.
Protocol and host variants
HTTP and HTTPS, or www and non-www, both serving content. Fix with a site-wide 301 redirect to one version, not with canonicals alone.
Trailing slashes and letter case
/shoes and /shoes/, or /Shoes and /shoes, both returning 200. Redirect to one form and make internal links use it consistently.
Parameters
Tracking, sorting, session and filter parameters producing copies of a page. Add a self-referencing canonical to every indexable template, so any parameterised version points back to the clean URL automatically.
Products in several categories
Ecommerce platforms that build product URLs from category paths create one URL per category. Fix it at the platform level where possible. Our Magento SEO guide covers the specific setting.
Genuinely thin, near-identical pages
Location or product pages that differ by one word. These are not a canonical problem but a content problem. Either consolidate them or make them substantively different.
Google chose different canonical than user: find the conflict
When Google overrides your canonical, some other signal disagrees with it. Check them in order of how often they are the cause. Is the declared canonical redirecting, returning an error, or marked noindex? Is it missing from your sitemap while the alternate is listed? Do your internal links point at the alternate rather than the canonical? Is the content on the two URLs actually the same, or different enough that the canonical looks like a mistake?
Fix the conflicting signal rather than repeating the canonical more forcefully. Once your canonical, redirects, sitemap and internal links all name the same URL, Google follows it in the large majority of cases.
Validating the fix
After deploying a fix, use Validate Fix on the relevant status in the Page indexing report. Google re-crawls a sample of the affected URLs and reports progress. Validation commonly takes a couple of weeks and can take longer on large sites, and the count falls gradually as pages are re-crawled rather than all at once.
Do not use the Request Indexing button on hundreds of URLs. It has a daily quota, and it does nothing that fixing the underlying signals and waiting for a re-crawl will not do.
Common questions
Does "Duplicate without user-selected canonical" hurt my rankings?
Not directly. Google is not penalising you. It found several URLs with the same content and chose one to index, which is exactly what it is supposed to do. The pages listed under this status are the ones it did not choose. The risk is indirect, and it comes in two forms. First, Google may choose the wrong URL, for example a parameterised or HTTP version rather than your clean one, and that is the version that appears in search results and accumulates signals. Second, a large number of duplicates wastes crawling that would otherwise go to your real pages, which matters on large ecommerce sites and barely at all on a site with a few hundred pages. So check which canonical Google selected. If it picked the URL you would have picked, the status is informational and low priority. If it picked something else, fix the underlying signals so it picks the right one.
Should I noindex duplicate pages instead of using canonicals?
Usually not. A canonical tells Google that two URLs are the same page and asks it to consolidate their signals onto one. A noindex tells Google to drop the page from the index entirely and, over time, to crawl it less. For true duplicates, such as tracking parameters or trailing-slash variants, the canonical is the better tool because links pointing to the duplicate still count towards the canonical. Noindex is the right tool for pages that are not duplicates of anything useful but should not be in search at all, such as internal search results, cart and account pages, and filter combinations with no search demand. Do not combine the two on the same page, because a noindexed page declaring a canonical sends contradictory instructions. And do not block duplicates in robots.txt if they are already indexed, since Google then cannot crawl them to see either instruction.
Why are pages with a correct canonical still showing as duplicates?
If a page declares a canonical and Google agrees, it should appear as "Alternate page with proper canonical tag", which is the healthy status. If it still appears as "Duplicate without user-selected canonical", Google has most likely not re-crawled it since the canonical was added, or cannot see the tag. Use the URL Inspection tool and look at the crawled page, not your browser. Canonicals injected by JavaScript after page load may not be picked up reliably, and a canonical placed in the body rather than the head is ignored. Tags added by two plugins or modules at once can also conflict, leaving Google with two different canonicals and no clear instruction. If the tag is present in the crawled HTML and the last crawl date is after your fix, the status should clear as Google re-crawls. Validate Fix in the Page indexing report speeds up that confirmation.
Services related to this guide
Tell us about your site
A written audit of crawling, indexing, rendering, Core Web Vitals, internal linking and structured data, built from a full crawl plus your Search Console data, with each fix ranked by impact and effort.