Search Console Page indexing: Why pages aren't indexed
Duplicate without user-selected canonical: the fix
Google found duplicates with no canonical declared and picked one itself. When to accept its choice and how to state your own with redirects and tags.
Google decided this page duplicates another URL, the page declares no canonical, so Google picked the other URL and will not show this one. Google calls that working as intended. Act only if Google picked the wrong URL: redirect or add rel="canonical" towards the one you prefer, or make the pages genuinely different.
What "Duplicate without user-selected canonical" means
Google: "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 two URLs can be http and https, www and non-www, trailing slash variants, parameter versions, or two pages with near-identical content.
Is it a problem?
Depends on the URL
Often fine. Google: "This is not an error, but is working as intended, because Google does not serve duplicate pages." It matters when the URL Google chose is not the one you would pick, or when two pages you consider different are being treated as one.
Causes, most likely first
- Host and protocol variants all serving the same page with 200: http and https, www and non-www, with and without a trailing slash.
- URL parameters for tracking, sorting or filtering that return the same content.
- No canonical tag on the template, or one removed by a theme or plugin update.
- Pages with near-identical content: location pages with one word changed, product variants, tag and category archives listing the same posts.
- A misconfigured server returning one host's content for requests to another. Google lists this among common canonicalization problems.
How to confirm it
- Inspect the URL and read "Google-selected canonical". Google notes it is shown only in the indexed result; the live test cannot predict it.
- Run the canonical checker on both URLs to see what each declares, if anything.
- Run the redirect chain checker on the http and www variants to see whether they redirect to one version or each return 200.
How to fix it
- Pick the URL you want indexed for each set of duplicates.
- Redirect host, protocol and trailing slash variants to it with a 301. Google calls redirects a strong canonical signal.
- Add rel="canonical" pointing at the preferred URL on each duplicate, and on the preferred page itself, as Google recommends. Use absolute URLs.
- List only the preferred URLs in your sitemap. Google treats sitemap inclusion as a weaker signal that adds to the others.
- Do not use robots.txt or noindex to choose a canonical. Google advises against both.
How long recovery takes
Google says that even after the issue is fixed it "might hold pages in a duplicate cluster for up to two weeks", and that pages split out faster when the difference between them is clear and significant.
After a fix, Validate fix on the issue asks Google to recheck the affected URLs. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Without it, the count still updates as Google recrawls, and an issue leaves the table once 90 days pass with no instance.
Would monitoring have caught it?
If the page used to declare a canonical and a deploy removed it, that is a canonical change on a monitored URL: a warning, confirmed on the next scheduled check. Monitoring cannot see which URL Google chose; only URL Inspection shows that.
stillindexed checks each monitored URL every 30 minutes on Starter and every 15 minutes on Agency, so the change is found on the next check and confirmed before it alerts, rather than waiting for this report to update.
A canonical tag pointing at the wrong URL, platform by platform
Further reading
Related statuses
Sources
Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-06. If Google has changed a page since, Google's page wins and we would like to know.