This is the Search Console status people most often try to fix when nothing is broken, and most often ignore when something is.
Google’s own wording is unusually direct about it. “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.” Then the sentence that decides what you should do next: “This is not an error, but is working as intended, because Google does not serve duplicate pages.”
So the status is describing two facts at once, and only one of them is Google’s opinion:
- You did not declare a canonical. That is a fact about your HTML, and it is entirely yours.
- Google clustered this page with another one and picked the other. That is a judgment, and judgments can be wrong.
Everything useful follows from separating those.
The one check that tells you which case you are in
Inspect the URL. Under Page indexing, read Google-selected canonical, then open that URL in a browser next to the page you inspected.
You are looking at one question and it is not a technical one: are these two pages the same page? Not similar in topic. The same primary content, the thing Google’s documentation calls the centrepiece.
If they are the same page, the report is right and you have nothing to fix. Google does not serve duplicates, and one of the two was always going to lose. The only thing worth doing is declaring the canonical yourself, so that the choice is yours rather than a signal-weighted guess that can flip later. The exception is a page that should not exist at all, and on WordPress that usually means attachment pages: a canonical tag on one of those is tidying a page you could redirect away instead.
If they are genuinely different pages, then the status is telling you something you would not have found otherwise: to Google’s indexing, your two pages read as one. That is a content problem wearing the costume of a canonical problem, and Google says so in the same paragraph: “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.”
Why adding rel=“canonical” often changes nothing
The line to internalise is from Google’s canonicalization documentation: “indicating a canonical preference is a hint, not a rule.”
That is not a hedge. Google lists exactly which factors feed the decision: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations. The documentation ranks them by strength as well: redirects are a strong signal, rel="canonical" is a strong signal, sitemap inclusion is a weak one. It also says they stack, so combining them raises the odds.
None of that stack overrides the clustering step, which happens first. Google decides two pages are the same page, and only then asks which one to keep. A canonical tag participates in the second question. It has no vote in the first.
Which is why the most common intervention I see on this status, add a self-referencing canonical to every page and wait, does nothing at all when the pages are true duplicates and nothing at all when they are near duplicates Google is not convinced by. It is the right hygiene and the wrong fix.
The two shapes this takes on real sites
The pattern I see most is parameters and paths that produce the same page twice: a filtered URL (on a store, the whole filter set is its own subject, covered in faceted navigation SEO), a session or tracking parameter, a page reachable at both /product and /product/, an HTTP copy still resolving alongside HTTPS. Here the status is doing its job. The pages really are one page. The work is picking a form, redirecting the rest, and keeping the sitemap in agreement with the choice. The slash pair specifically has its own writeup in do trailing slashes matter for SEO, because it is the variant people argue about most and act on least.
The pattern that costs money is thin variants that were meant to be distinct pages. Location pages that differ only in the town name. Product pages whose body copy is the manufacturer’s paragraph with a different SKU above it. Service pages spun per city from one template. These come back as duplicate without user-selected canonical in bulk, and every one of them is a page you paid to produce that Google will not serve. I have written up what actually makes those pages survive in location pages that index, and the store version of the same failure in seven empty indexes at the same store.
The tell between the two is volume. A handful of URLs in this status on a site with clean URLs is housekeeping. Hundreds of URLs in it, all of them pages a human wrote on purpose, is a content architecture problem that no tag will fix.
What this status is not
It is not crawled, currently not indexed, which means Google fetched the page and declined to store it on its own merits, with no duplicate involved. It is not “Duplicate, Google chose different canonical than user”, which is the stricter sibling: there you did declare a canonical and Google overruled it, which means Google thinks your page is not even a duplicate of the URL you nominated. And it is not a penalty, a manual action, or anything that spreads.
If you are working through several of these statuses at once, the full map is in every Search Console indexing status, and the four that most often get misread as Google ignoring a site are in 4 GSC statuses that look like Google is ignoring you. Its two nearest neighbours have their own write-ups: alternate page with proper canonical tag, where you did declare a canonical and Google agreed, and page with redirect, where the URL serves no content at all.
What I do with it on client accounts
I sort the URLs in this status into the two buckets above before I touch anything, because the fixes are opposites. Bucket one gets redirects and a sitemap that agrees with them. Bucket two gets rewritten or merged, and usually fewer pages come out than went in.
The part clients push back on is the second bucket, because the recommendation is often to delete pages. It helps to name the trade honestly: those pages are already not in Search. Merging four near-identical town pages into one real page does not lose you four indexed pages. It converts zero indexed pages into one.
And the request I decline is the one to submit them all for indexing. Requesting indexing on a URL Google has clustered as a duplicate does not change the cluster. I wrote up the wider version of that in does request indexing actually work. The queue is not the constraint here. The judgment is.
Sources
- Google Search Console Help, Page indexing report, duplicate without user-selected canonical, checked 25 August 2026
- Google Search Central, What is canonicalization, checked 25 August 2026
- Google Search Central, How to specify a canonical URL with rel=“canonical” and other methods, checked 25 August 2026