WordPress problem fix
When Google overrides your canonical, it is telling you your signals contradict each other. We unify the signals and Google falls back into line.
'Duplicate, Google chose different canonical than user' in Search Console means you declared one URL as canonical (via the link rel=canonical tag) but Google decided a different URL was the better canonical and indexed that one instead. Google ignoring your canonical is not a bug; it is the system working as designed when your signals contradict each other. The common contradictions on WordPress: (1) canonical tag points to URL A but the sitemap lists URL B, (2) canonical points to URL A but internal links across the site point to URL B, (3) canonical points to URL A but hreflang or self-referencing canonical on URL B points back to itself, (4) canonical points to a 301-redirected URL, (5) canonical points to a noindex page, or (6) the canonical and the URL being canonicalised have very different content (Google ignores canonicals that look like spam). The fix is to unify every signal — canonical, sitemap, internal links, hreflang, redirects — onto the same target URL, then let Google recrawl. This problem dominates WooCommerce sites with product variants, ecommerce filters, and printable views.
If any of these match, you are on the right page.
Search Console → Pages report shows URLs under 'Duplicate, Google chose different canonical than user'
site:yoursite.com/your-canonical-url returns no result, but site:yoursite.com/different-url returns the page
URL Inspection on your declared canonical shows 'Google-selected canonical: [different URL]'
Most common on WooCommerce product variants, paginated archives, /?s= search URLs, and printable views
Internal links on the site point to URL B even though canonical points to URL A
Because rel=canonical is a hint, not a directive. Google weighs your canonical alongside sitemap entries, internal links, redirect targets, hreflang, and content similarity. When those signals disagree, Google picks the URL with the most consistent signals — which may not be the one you declared canonical.
WooCommerce generates parameterised URLs constantly — variant selectors, sort orders, filter combinations, currency switchers, language switchers. Each variation has its own URL but the canonical usually points back to the base product. Meanwhile internal navigation and recent-product widgets often link to the parameterised URLs, contradicting the canonical. Google sees more internal links to the parameterised URL than to the canonical and decides the parameterised URL is the real one.
Because the canonical URL must itself be a live indexable 200 page. If you point canonical at URL A and URL A 301-redirects to URL B, Google follows the redirect and uses URL B as the canonical — overriding your declaration. Always canonicalise to a final live URL, never to a redirect.
The real method, in the order it works.
Run URL Inspection on the URL Google is mis-canonicalising. Note Google's declared canonical, your declared canonical, and the discrepancy.
Confirm the canonical target is live and 200 (curl -I https://...). If it is 301, 404, or noindex, that is your primary contradiction. Fix the target page first.
Audit internal links. Use Screaming Frog or wp-cli search-replace to find every internal link pointing to the URL Google picked. Update them to point to your declared canonical instead. This is the single highest-leverage fix.
Check the sitemap. Open sitemap.xml and confirm the canonical URL is listed and the wrong-canonical URL is NOT listed. Yoast and RankMath usually do this correctly when canonical is set; manual sitemaps often do not.
Check hreflang. If you have hreflang tags, every translation must point back to itself AND to the same canonical chain on the source language. A hreflang pointing to a different URL than the canonical is a contradiction.
Check parameterised URLs in WooCommerce: Search Console → Legacy URL Parameters (still works in many accounts) or set up parameter handling via the URL Parameters tool. Tell Google how each parameter affects content.
If the duplicate is a printable view, mobile view, or AMP variant: noindex the variant entirely instead of relying on canonical to consolidate. Variants are a stronger signal to Google when noindexed than when canonicalised.
Re-request indexing on the declared canonical AFTER unifying all signals. Doing it before unification just confirms the existing contradiction.
Real fix, from our work
A 1,200-product WooCommerce store had 2,800 URLs in 'Duplicate, Google chose different canonical'. The owner had spent weeks adjusting canonical tags via Yoast with no improvement. We pulled the data and split by pattern: 1,900 were /?orderby= and /?sortby= variants of category pages, 600 were /?attribute_color= filter combinations, 200 were ?currency= switcher URLs, and 100 were genuine product duplicates from a bad migration. Fix: blocked /?orderby and /?sortby in robots.txt and set them to noindex via Yoast (canonical alone was being ignored because internal sorting links contradicted it), set color and attribute filters to noindex + non-indexable, switched the currency switcher from URL-parameter to cookie-based, 301-redirected the 100 migration duplicates to their correct products. Within 5 weeks the duplicate count dropped from 2,800 to 38, and 14 product URLs that had been losing rankings to their /?orderby variants recovered top-3 positions. Canonical tags only work when every other signal agrees with them.
Written by Ali Yasin Jatoi
Founder of WebCare Studios. Ali has worked with WordPress for more than 10 years, including managing a fleet of 150+ sites with WP-CLI automation for updates, security cleanup, and malware removal. He has hands on experience across major hosts including Cloudways, A2 Hosting, Hostinger, and Bluehost.
Site down, hacked, or broken checkout gets a senior engineer within 4 hours. No ticket queues, no bots.
Flat quote up front. If we cannot get you back online, you do not pay. Risk sits with us, not you.
We work on a snapshot first and never touch your live database until the fix is verified safe.
We run a fleet of WordPress sites every day. The errors you are seeing are ones we have closed hundreds of times.
Yes — Google honours it most of the time when other signals agree. It is just not a guarantee. Treat canonical as one of about six signals that need to agree, not as an override.
Often yes, especially for parameter-based variants, sort orders, and filter combinations. Noindex is a directive, not a hint, so it removes the duplicate from competition entirely. Reserve canonical for true content duplication where both URLs need to remain accessible.
Because the homepage usually has thousands of internal links pointing to it, which align with the canonical signal. Product pages may have only a handful of internal links, and those links may point to parameterised variants. Internal-link signal dominates canonical when canonical is weak.
Typically 2-6 weeks. Re-request indexing after you have unified signals to speed it up. Do not re-request indexing before fixing the contradictions — Google will recrawl, find the same contradictions, and reconfirm its own canonical choice.
Yes. CDNs that serve different cache variants under different URLs, and A/B testing tools that swap content based on cookies, can both confuse the canonical signal. Configure both to vary content under the same canonical URL, never under different URLs.
Two fields. Email and your URL. A senior WordPress engineer reads it within minutes and replies on email and WhatsApp with what is wrong and what we will do next.
Real proof and field guides tied to "GSC: Duplicate without user-selected canonical".