Search Console flags URLs in the Pages report (Indexing section) under “Duplicate, Google chose different canonical than user.” Translation: you declared a canonical, Google decided a different URL is the real master, and it ignored your declaration. That matters because:
- The URL you wanted indexed won’t be indexed.
- The URL you didn’t pick absorbs the indexing and ranking credit instead.
- The link signals you accumulated for your chosen canonical get consolidated onto Google’s pick, not yours.
rel="canonical" is a hint, not a directive. Google’s own docs say it “might choose a different canonical for various reasons, such as the quality of the content,” and it weighs your tag against many other signals (internal links, sitemaps, redirects, hreflang, and more). This status is the inverse of “Alternate page with proper canonical tag” (where Google agreed with you); here Google is telling you your proposal was rejected.
TL;DR — fastest fix
If your two URLs are true duplicates and you don’t care which one wins, 301-redirect the loser to the winner. A 301 is a directive (not a hint), and Google usually picks it up within days, versus the several weeks a rel="canonical" change can take to suppress a duplicate. If you specifically need URL A to win but it’s currently weaker, you have to make A out-signal B: move internal links to A, add A (only A) to the sitemap, and 301 B to A. Then click Validate Fix and wait 2-4 weeks.
Which bucket are you in?
| Symptom in URL Inspection | Most likely cause | Go to |
|---|---|---|
| Google-selected canonical is an older, more-linked URL | Internal/external links favor Google’s pick | Cause 1 and 2 |
Sitemap URL differs from the page’s rel="canonical" | Conflicting signals; sitemap wins the tug-of-war | Cause 3 |
Only difference is trailing slash, case, www, or http/https | URL-variant inconsistency | Cause 4 |
| Two genuinely different paths, ~80% identical content | Near-duplicate cluster | Cause 5 |
| Language/region variants pointing at each other | Missing or wrong hreflang | Cause 6 |
Run URL Inspection on the affected URL first: the User-declared canonical and Google-selected canonical fields tell you exactly which URL Google picked and which one you wanted.
Common causes
In rough frequency order.
1. Your canonical points to a weaker-signal page
Google clusters duplicates and picks one canonical per cluster from many inputs, roughly weighted:
- Internal link count (links from your own site)
- External link count and quality
- Content length, uniqueness, and quality
- URL shape (short, no params beats long, multi-param)
- HTTPS preferred over HTTP
- Indexing history (already-indexed URLs win over newly discovered ones)
- Sitemap presence
- Redirect targets
If you canonical to a cold-start new URL but Google has indexed the old URL for months and it carries 50 backlinks, Google sticks with the old one.
How to confirm: URL Inspection shows the Google-selected canonical. Compare the two URLs on internal link count (Search Console → Links → Internal links), backlinks (Search Console → Links → External links), and time since first indexing.
2. Internal links favor Google’s pick
The most common real-world case:
- You restructured the site and the old URL
/blog/post-old/still has 200 internal links, while the new URL/blog/post-new/has only its sitemap entry. Even with the new URL self-canonical, Google picks the old one. - Your nav, homepage, and category pages all link to
/page?ref=main, but the canonical says/page. Google sees/page?ref=mainas the URL people actually link to and picks it.
How to confirm: grep -r "/blog/post-old/" src/ shows how many places in code reference the old URL. Or use Search Console → Links → Internal links to compare the two URLs’ link counts side by side.
3. Sitemap says A, canonical says B
<!-- sitemap.xml -->
<url><loc>https://yourdomain.com/post/</loc></url>
<!-- but page head -->
<link rel="canonical" href="https://yourdomain.com/post?v=2" />Sitemap inclusion and rel="canonical" are both strong signals. When they conflict, Google leans toward the version that looks like the one in active use, usually the sitemap URL. Never list a non-canonical URL in your sitemap.
4. Case, slash, www., or http vs https inconsistencies
Google treats these as different URLs and standardizes to one:
https://yourdomain.com/page <- indexed
https://yourdomain.com/page/ <- your canonical, but Google picked the one aboveUsually it happens because most internal links use the unslashed version, the server 301-redirects to the slashed version, and the extra hop weakens your chosen version’s signal enough for Google to override it. Pick one form and use it everywhere: links, sitemap, and canonical.
5. Two URLs with very high content similarity
When /services/seo-consulting/ and /blog/seo-consulting-guide/ are ~80% the same, Google decides they’re two variants of one page and picks whichever has stronger signals, regardless of your canonical tags. The fix is to merge or genuinely differentiate them (see Step 1).
6. Language or region variants without correct hreflang
Google’s docs call this out directly: near-identical pages that serve different languages or regions can be clustered as duplicates if hreflang is missing or wrong, so Google folds them into one canonical. Each variant should self-canonicalize and declare reciprocal hreflang annotations (including x-default). Do not point a de page’s canonical at the en page; use hreflang to relate them instead.
Shortest path to fix
Core principle: either make your preferred URL carry the strongest signals, or surrender and adopt Google’s pick as the master. Don’t try to win with a weak canonical against a strong page.
Step 1: Decide which URL is actually the master
Open the two conflicting URLs from the report:
- User-declared canonical: A
- Google-selected canonical: B
Spend one minute on:
- Is B shorter, cleaner, more memorable? Surrender, and update A’s canonical to point to B.
- Is A genuinely the version you want (newer, more comprehensive) but currently low-signal? Boost A’s signals in Step 2.
- Are A and B true near-duplicates? Merge them: 301 one to the other.
Step 2: Move all internal links to the master version
Use ripgrep to find them:
# Find every internal link to the non-master URL
rg -l 'href="/old-url/?"' src/
# Replace (preview the matches first with the command above)
rg -l 'href="/old-url/?"' src/ | xargs sed -i '' 's|/old-url/|/new-url/|g'At minimum, fix:
- Nav, homepage, and category lists, so they all point to the master
- In-article references (“see our earlier piece X”)
- The three template links: related posts, prev/next, and breadcrumbs
Re-check Search Console → Links → Internal links: the master’s count should rise relative to the loser’s.
Step 3: 301 the loser to the master
Once you’ve confirmed A is the master, B must 301 to A. Changing the canonical alone is often not enough, because a canonical is a hint while a 301 is a directive Google almost never overrides.
// firebase.json
{
"hosting": {
"redirects": [
{
"source": "/old-url",
"destination": "/new-url",
"type": 301
}
]
}
}Or Vercel:
// next.config.js
module.exports = {
async redirects() {
return [
{ source: "/old-url", destination: "/new-url", permanent: true },
];
},
};Only redirect when B is a true duplicate you’re willing to remove from the URL space. If B must stay a distinct, live page (for example a paginated or filtered view), don’t 301 it. Differentiate the content and rely on Step 2 plus the sitemap instead.
Step 4: Sync sitemap, canonical, and internal links
// sitemap and canonical share one urlFor()
export function urlFor(slug) {
return `https://yourdomain.com/blog/${slug}/`; // note trailing slash
}The sitemap generator, the canonical renderer, and breadcrumb links should all import this one function. No hand-written URLs, so case and slash drift can’t creep back in. Confirm only the master URL appears in sitemap.xml.
Step 5: Tell Google, then wait 2-4 weeks
In Search Console:
- Run URL Inspection on the master URL and click Request Indexing.
- In the Pages report, open the “Duplicate, Google chose different canonical than user” issue and click Validate Fix. This asks Google to re-crawl every affected URL and tracks the rollout in the Validation row. (Note: if Google finds a single unfixed instance, validation stops, so fix all of them first.)
- After ~2 weeks, re-inspect the master URL and check whether the Google-selected canonical has switched to it.
- After ~4 weeks, confirm the URL shown in live search results is the master.
How to confirm it’s fixed
You’re done when all three of these line up:
- URL Inspection shows Google-selected canonical = your master URL (ideally “same as user-declared”).
- The loser returns the right status:
curl -sI https://yourdomain.com/old-urlshowsHTTP/2 301with alocation:header pointing at the master. - A live
site:yourdomain.comsearch (or the SERP for a target query) returns the master, not the loser.
If it still hasn’t switched after 4 weeks:
- Verify the 301 is actually live and not a 302 or a redirect chain:
curl -sIL https://yourdomain.com/old-urlshould land on the master in one hop with status 301. - Check that internal-link replacement didn’t miss directories, especially CMS rich-text/database fields, which
grepoversrc/won’t catch. - Last resort: temporarily add
<meta name="robots" content="noindex,follow">to the loser to force it out of the index, leaving only the master available, then remove it once the master is indexed.
FAQ
Is “Duplicate, Google chose different canonical than user” an error I must fix? Not always. In the Pages report, check the Source column: you can only act on issues sourced to “Website.” If both URLs are yours and the page Google picked is the one you actually want ranking, you can safely ignore it or just update your tag to agree. Fix it when the wrong URL is winning.
How long until Google switches the canonical after I fix it?
A 301 redirect is usually picked up within days, though the full index transfer can take longer. A rel="canonical" change with no redirect can take several weeks, because Google has to re-crawl both URLs and re-evaluate the cluster. Plan for 2-4 weeks before judging the fix, and use Validate Fix to nudge re-crawling.
Does changing only the canonical tag ever work? Sometimes, if your other signals (links, sitemap) already point the same way. But if Google ignored your tag once, it’s because competing signals disagreed with it. Align those signals or add a 301; don’t just re-save the tag and wait.
Can I noindex the duplicate instead of redirecting it?
Yes, if the duplicate must stay reachable but shouldn’t compete. Use <meta name="robots" content="noindex,follow"> (keep follow so link equity still flows). Don’t combine noindex and rel="canonical" on the same URL; they send conflicting instructions and Google may ignore both.
The two pages are genuinely different, so why does Google merge them? If they share ~80% of their content, Google clusters them regardless of intent. Either consolidate them into one URL or rewrite one so it’s substantively unique (different intent, examples, and structure), then re-request indexing.
Prevention
- The URL with the most internal links tends to become the canonical, so don’t fight Google with weak signals.
- When restructuring URLs, migrate internal links AND add 301s, not just canonical changes.
- Route sitemap, canonical, and breadcrumbs through one
urlFor()helper so case and slash never drift. - Merge near-duplicate content into one URL instead of raising two pages that compete with each other.
- Use
hreflang(not cross-language canonicals) to relate translated or regional variants.
Related
Tags: #SEO #Google #Search Console #Indexing