Google Search Console has a report called Page Indexing. One of the rows in it reads Duplicate, Google chose different canonical than user. It is the row that stings, because you did the work and Google ignored it.
A canonical is Google’s word for the one URL it treats as the real version of a page. You picked one. You put a canonical tag on the page saying so. Google read the tag, disagreed, and indexed a different URL.
Here is what that looks like in practice. Two URLs, and Google thinks they are the same page:
https://example.com/shoes/running you declared this one
https://example.com/shoes?category=running Google indexed this oneThe instinct is to fight it. Add a stronger tag. Add a second one. Argue with the report. That is almost always the wrong move, and the rest of this post is about how to tell when it is not.
- Google read your canonical tag and overruled it. The tag is a strong signal, not a command, and other signals stack against it.
- Nothing is penalized. Signals from the duplicate consolidate onto the URL Google picked, so the content still competes.
- Inspect the URL to see both canonicals side by side. Yours and Google’s, in one screen. That comparison is the whole diagnosis. Search Console makes you do it one URL at a time; with ContextBolt SEO your agent works through a set of them without leaving the chat.
- Google is usually right. Most rows in this bucket are two URLs that really are one page, and the pick is fine.
- When it is wrong, redirect or rewrite. A louder canonical tag has never won this argument.
Where you are seeing this
If you landed here from a search and have not opened the report yet, this is the click path.
- Open Google Search Console and pick your property.
- In the left sidebar, click Indexing, then Pages.
- Scroll past the summary chart to the table headed Why pages are not indexed.
- Find the row Duplicate, Google chose different canonical than user and click it.
You get a list of URLs. The list holds the pages you declared, not the pages Google indexed instead, which is the first thing that confuses people. Google’s picks are not in this view at all. You have to inspect a URL to see them.
What the status actually means
Break the name apart and it stops being cryptic.
Duplicate: Google found two or more URLs it considers the same page.
Google chose different canonical: it selected one URL to index and represent the group.
Than user: you had declared a different one, and “user” here means you, the site owner.
So the status is a disagreement, recorded honestly. Google is not saying your page is bad. It is saying your page is a copy of another one, and that other one is the version it will show.
The page you declared still gets crawled. Its links still count. Google consolidates the ranking signals from every URL in the group onto the one it picked. Nothing is lost. Only the address changes.
That last part is why panic is the wrong first response. The cost of this status is not lost authority. It is the wrong URL appearing in search results, and whether that costs you anything depends entirely on which URL it picked.
Why your canonical tag lost
This is the part nobody says plainly. A canonical tag is a signal, not an instruction.
Google’s own documentation on specifying a canonical URL ranks the ways you can state a preference, in order of how strongly each one influences the decision. A redirect is a strong signal. A rel="canonical" link element is also a strong signal. Sitemap inclusion is a weak one. Nothing on that list is a command.
So your tag sits near the top of the list and it still lost. Google also says these signals stack, which is the part that explains the loss. One strong signal pointing your way can be outweighed by several pointing the other way.
The exception is a 301 redirect. It is the strongest option on the list, and it is the only one that does not ask Google to choose at all, because it removes one of the two URLs rather than ranking it lower.
Here are the five things that most often outweigh your tag.
One
Your internal links contradict the tag. You canonicalize to /shoes/running, then every navigation link, breadcrumb and related-product module on the site points at /shoes?category=running. Google counts links. A few hundred internal links saying one thing beats one tag saying another.
Two
Your sitemap disagrees. Sitemap inclusion is the weakest of the three signals Google names, so it will not overturn your tag on its own. It stacks, though. A sitemap listing the other URL, sitting next to internal links pointing at the same place, adds up. If the URL you declared is missing from your sitemap, you are leaving a free vote unused.
Three
Your canonical points somewhere unusable. A canonical aimed at a page that redirects, returns a 404, or carries a noindex rule gets discarded, because following it would leave nothing to index. If you are seeing this across a large group of URLs, check the target before you check anything else.
Four
The chain contradicts itself. Page A canonicalizes to B, B canonicalizes to C, and C canonicalizes back to A. Google resolves the loop by ignoring all three tags and picking on its own. Cross-domain canonicals fail the same way when the two sites do not obviously belong together.
Five
The other URL simply looks more canonical. Shorter path, HTTPS, no parameters, older, more linked to from outside your site. When your tag is the only signal pointing your way, that is one vote against many, and you lose it.
Notice what is missing from that list. Nothing here is a bug, and nothing here is Google being difficult. In four of the five cases, your own site is voting against your own tag.
Read both canonicals side by side
The Page Indexing report will never show you Google’s pick. The URL Inspection tool will, and it is the only step in this whole diagnosis that really matters.
Paste one of the listed URLs into the search bar at the top of Search Console. Open Page indexing in the result. Two fields sit next to each other:
- User-declared canonical: what your tag says.
- Google-selected canonical: what Google indexed instead.
Read them as a pair. On its own, either one tells you nothing.
For more than a handful of URLs, the URL Inspection API returns the same two fields as userCanonical and googleCanonical. It is capped at 2,000 inspections per property per day, which is plenty for one report row and not enough for a site-wide sweep on a big site.
If your Search Console is wired into an AI agent, this is one sentence instead of a morning of tabs. The one-click Search Console connection is the setup half, and it takes about twenty seconds.
Running the check across a whole site
The useful output is not a list of URLs. It is a list of pairs, sorted so the alarming ones float to the top.
Copy this prompt
Pull every URL in my Search Console Page Indexing report filed under
"Duplicate, Google chose different canonical than user".
For each one, inspect it and show me the canonical I declared next to
the canonical Google selected.
Then sort the results into two groups. Group one is where the two URLs
differ only by a query string or a trailing slash. Group two is where
they sit on genuinely different paths.
Show me group two first, with a count of both.That split is the whole triage. A pair that differs by ?sort=price is housekeeping. A pair on two different paths means Google believes two pages you wrote on purpose are the same page, and that is a content problem wearing a technical costume.
When Google picked wrong
Four cases where the pick genuinely costs you something. All four are worth acting on.
It picked a parameterized URL. Google indexed /shoes?category=running&sort=price over your clean path. Every searcher now lands on a pre-filtered view. Fix it by redirecting the parameter version, or by dropping it from the sitemap and cutting the internal links that feed it.
It picked a paginated or filtered page. Page two of a listing outranking page one is the classic version. Same fix, and check whether your pagination emits canonicals at all.
It picked an old version you replaced. You wrote a 2026 guide, Google still shows the 2024 one, and they are similar enough to be judged duplicates. Redirect the old one. Do not leave both live hoping the tag sorts it out, because you already know it did not.
It picked a different domain. A syndication partner, a staging subdomain that leaked, or a scraper with more authority than you. This is the only case on the list that is genuinely urgent, and the fix is usually a redirect on your side plus a takedown request on theirs.
The pattern across all four is the same. You win this argument by removing the other URL, not by relabeling it. A redirect works. There is no stronger tag to reach for.
When to leave it alone
Here is the opinionated part, and it is the reason this post exists.
Most of the rows in this bucket should stay exactly where they are. The urge to empty the list is the most expensive instinct in technical SEO, and it is the one every checklist encourages.
Leave it alone when the two URLs really are the same page. If /shoes/running and /shoes?category=running serve identical content, Google picking either one is a correct outcome. You may prefer the tidier URL. That is a preference, not a problem, and chasing it burns a week.
Leave it alone when the traffic is already going where you want. Check the clicks before you check the canonicals. If the URL Google picked is already earning the impressions and the clicks, the report is describing a working page in unflattering language.
And leave it alone when the honest answer is that the two pages should never have both existed. If Google says they are duplicates, and you read them and quietly agree, the canonical tag was a workaround for a decision nobody wanted to make. Merge them. That is a better afternoon than winning an argument with a crawler.
The advice I would push back on hardest is adding a canonical tag to everything as a precaution. You are not adding certainty. You are adding one more vote to a tally Google was already going to count, and creating a new report row for every time it loses.
How this differs from the other canonical status
Two rows in the Page Indexing report mention canonicals, and they get mixed up constantly. The difference is whether you said anything at all. If you declared nothing, you want duplicate without user-selected canonical instead, which is the same situation with the blame removed.
| Status | What you declared | Who decided | What actually fixes it |
|---|---|---|---|
| Duplicate, Google chose different canonical than user | A canonical, and Google read it | Google, overruling you | Redirect, or make the pages genuinely different |
| Duplicate without user-selected canonical | Nothing | Google, on your behalf | Declare a canonical, or accept the pick |
| Excluded by noindex tag | Do not index this page | You did | Remove the rule, keep the page crawlable |
| Crawled, currently not indexed | Nothing | Google, on quality | Make the page worth a slot, or accept it |
| Discovered, currently not indexed | Nothing | Google, on capacity | Server speed and internal links |
Only one row in that table is a switch you control directly, and it is excluded by noindex tag. The bottom two are a different animal again. In crawled, currently not indexed Google fetched the page and passed on it. In discovered, currently not indexed it never fetched the page at all. No amount of canonical work moves either one.
Where the data comes from
This diagnosis needs two things. The pair of canonicals, which Google gives you free through Search Console, and somewhere for the readings to pile up, because a group of 80 URLs tells you nothing until you know whether it was 12 last month.
ContextBolt SEO is the tool I build. It puts a read-only Search Console connection and a full SEO toolkit inside the agent you already work in, so comparing two hundred canonical pairs is a sentence rather than two hundred inspections by hand. The Search Console tools are free and never spend your monthly research credits. It is $35 a month with a 7-day free trial, and there is no dashboard to work in, because every lookup lands on a board that fills itself while you work somewhere else.
A second reading matters on this status specifically, because canonical decisions are slow. Google has to recrawl both URLs and run the comparison again before anything moves. One reading tells you the redirect is live. A reading three weeks later tells you Google acted on it.
What I would actually do
Open the row and read the list before touching a single tag.
Inspect ten URLs, not one, and write down the pairs. Ten is enough to see the shape. If every Google pick is a parameter version of your declared URL, you have one problem with one fix, and it probably lives in your faceted navigation rather than in your canonicals.
Then sort what is left into the two piles from the prompt above. Query-string pairs go in the leave-alone pile, and on most sites that pile is the majority. Different-path pairs get read as pages, side by side, by a human. Ask one question about each pair. Should both of these exist?
If the answer is yes, they are not duplicates, and the fix is to make them read that way. Different angle, different examples, different first paragraph. If the answer is no, redirect one to the other and stop maintaining two.
The mistake to avoid is treating the number as the target. Google overruling your canonical is a symptom, and the disease is almost always two pages that should have been one. Fix the symptom and you are left with two thin pages and a tidier report.