Google indexed your collection URL instead of your Shopify product page

Short answer. In Search Console, the user-declared canonical is the URL your page declares for itself; the Google-selected canonical is the one Google actually indexed. On Shopify they diverge because every product lives at two URLs, /products/handle and /collections/name/products/handle, and a theme that builds its product links in collection context points the whole site at one version while the canonical tag declares the other.

Nothing broke. The product is active, priced, in stock and crawlable. But in Search Console's Page indexing report a growing pile of your product URLs sits under a status you did not ask for, and the Google-selected canonical is not the URL you have been optimising, submitting and paying for clicks on.

What the two canonical fields in URL Inspection mean

Run any product URL through Search Console's URL Inspection tool and the Indexing section shows both fields. Google's own documentation defines them in one line each: the user-declared canonical is shown "if your page explicitly declares a canonical URL", and the Google-selected canonical is "the page that Google selected as the canonical (authoritative) URL when it found similar pages on your site".

The important part is what sits between them. Your declaration is an input, not a decision: Google states that it "might select the user-declared canonical, but sometimes Google might choose another URL that it considers a better canonical example", and that "there is no guarantee that Google will choose your preferred canonical, but we will take this into consideration".

So when the two fields disagree, the question is never "why was my tag ignored". It is which other signal outvoted it. Google's canonicalization documentation grades them. A redirect is "a strong signal that the target of the redirect should become canonical"; a rel="canonical" annotation is "a strong signal that the specified URL should become canonical"; and sitemap inclusion is "a weak signal that helps the URLs that are included in a sitemap become canonical" (wording checked on that page on 21 September 2026). Two consequences follow on a Shopify store. A redirect carries the same documented weight as your tag and resolves to a different URL, so a product URL quietly redirected by an app or a handle change competes with whatever the tag says. And sitemap inclusion is the one signal Google calls weak, so listing the clean URL in sitemap_products_1.xml does not rescue a product whose links and tags disagree.

What Search Console is actually telling you

Two statuses describe this, and they are not the same. Google's page indexing report documentation defines "Duplicate, Google chose different canonical than user" as a page that "is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical", and has indexed that other URL instead of yours. "Duplicate without user-selected canonical" is the version where your page declared nothing at all, so Google picked for you.

A third status, "Alternate page with proper canonical tag", is worth reading carefully rather than assuming. Google defines it as a page "marked as an alternate of another page (that is, an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical)", which "correctly points to the canonical page, which is indexed, so there is nothing you need to do". The examples the definition gives are all AMP and mobile/desktop pairs, not a duplicate of the kind a collection URL creates, so if your collection-scoped URLs are landing there, that is worth confirming against the sample URLs in the report rather than reading the label as a clean bill of health.

How to confirm it on your own store in five minutes

1. Open Search Console → Indexing → Pages and look for "Duplicate, Google chose different canonical than user". Open it and read the sample URLs: if they are /products/…, your clean URLs are the ones losing.
2. Run one of those URLs through URL Inspection and compare User-declared canonical with Google-selected canonical. Google states plainly that it "might select the user-declared canonical, but sometimes Google might choose another URL that it considers a better canonical example", and that there is no guarantee it will choose yours.
3. Search site:yourstore.com inurl:/collections/ inurl:/products/ in Google. Every result is a collection-scoped product URL that Google has kept in its index.
4. Open a collection page, click a product, and read the address bar. If it says /collections/…/products/…, that is the URL your whole site is voting for.
5. Check the canonical on that collection-scoped URL, but check it in URL Inspection's rendered view, not in "view source". A raw page source is not proof either way: a tag an app injects after load is absent from the source and present in what Google renders, and a tag in the source can be rewritten before Google reads it, the same gap that decides which structured-data warnings you actually have. The rendered view is the only one of the two that shows what Google actually had. Whichever you use, the href should point at the clean /products/handle URL and carry no query string.

What the canonical tag on those URLs actually says

This is worth establishing before you go looking for a fix, because the tag is the first thing the status appears to implicate. On 21 September 2026 we built eight collection-scoped product URLs on eight live Shopify storefronts, taking a real collection handle and a real product handle from each store's own public endpoints, and fetched each one with a Googlebot user agent. Six answered HTTP 200. The other two returned 404, which is what happens when you pair a product with a collection it does not belong to; that is a limitation of building URLs rather than following links, not a fault on those stores.

On all six that served a page, the result was the same: exactly one rel="canonical" tag in the HTML the server returned, and every one of them pointed at the clean /products/handle URL with no query string. Six stores is a small sample and not a rate, we are not claiming a percentage of Shopify stores here. But six of six is enough to say that a correct, server-rendered declaration is a normal thing to find on exactly the URL that is losing, and worth ruling out before you go hunting for a malformed tag.

That matters for what you do next. If the tag is already right, then a page sitting under "Duplicate, Google chose different canonical than user" is not a page whose declaration is missing or malformed: it is a page whose correct declaration was outweighed by something else. Adding a stronger tag to a tag that is already correct changes nothing. The signals that outweigh it are below.

Where the contradiction comes from

Your theme links to the collection version of every product. This is the first thing to rule out, and it is not a bug: it is a documented Liquid feature. Shopify's own reference for the within filter shows it turning /products/draught-of-immortality into /collections/sale-potions/products/draught-of-immortality, and warns on the same page that "a standard product page and a product page in the context of a collection have the same content on separate URLs". A theme that calls it in the product card snippet links away from the URL you declared on every collection page and in every "related products" block: once in the code, everywhere on the site.

And internal links are a signal Google weighs. Its canonicalization documentation tells you plainly to "link to the canonical URL rather than a duplicate URL", because "linking consistently to the URL that you consider to be canonical helps Google understand your preference". A store that declares one URL and links to another from a thousand places has cast a thousand votes against its own declaration.

A canonical carrying a query parameter. If the tag on a product page resolves to something like /products/handle?variant=123, each variant is declaring itself the canonical version of the product, which is the opposite of consolidating them.

A canonical pointing somewhere it should not. Apps and theme edits that inject their own head markup can leave a product declaring a different product, or the .myshopify.com domain instead of your live one. Two canonical tags on one page is the worst case: contradictory declarations Google can discard entirely, leaving it to choose alone. Across our full-catalog scans of more than 90,000 Shopify product pages, we read the canonical target of every product page, precisely because nothing in the admin displays it.

The fix

The goal is not to add a stronger tag. It is to stop the site contradicting itself, so all four things say the same URL:

• The internal links. In the theme's product card and related-product snippets, use {{ product.url }} rather than {{ product.url | within: collection }}. This is the change that moves the needle, because it is the signal you were losing on volume.
• The canonical tag. One tag per page, resolving to the clean /products/handle URL, with no query string and no second tag added by an app.
• The sitemap. Open /sitemap_products_1.xml and confirm the form of the URL listed there matches what the canonical declares.
• The feed. Google's specification for the link attribute tells you to "use your verified domain name" for the URL you submit. Submitting the collection-scoped URL while canonicalising to the clean one hands Google one more contradiction to resolve, on the one URL Merchant Center will try to fetch.

Then re-inspect one affected URL and request indexing. Google's documentation sets no timeframe for a canonical choice to be revisited, so treat the status as something to re-check on a schedule of your own rather than something to sit and watch.

Why this one comes back

The edit is small. Keeping it is not. Product cards are theme code, so a theme update or a new theme can reintroduce within: collection without anyone deciding to; any app with theme access can add a second canonical tag to your head; and every new collection mints a fresh set of duplicate URLs for products that were previously fine. And because the choice rests on signals across your whole site rather than on the tag alone, a change you make somewhere else (a new navigation, a new app, a bulk import) can move it back without anyone touching the product.

It is the same shape as the phantom noindex and the product that quietly leaves the sitemap: the admin shows a healthy product while the disagreement lives between your theme, your feed and Google's index. Something has to read the live pages and compare.

Is this happening on your store right now?

Search Console will not page you when this happens. The product page loads fine in a browser, the sitemap looks clean, and Google quietly stops crawling or indexing it anyway. The only way to know is to check the pages the way Google sees them.

• 90+ checks, the way Google crawls and indexes your store. Noindex tags, canonicals, redirects, robots.txt, sitemap coverage.
• Read-only. No app to install, no admin access, nothing changes on your store.
• The exact fix for each page, in plain English, so you or your developer can act the same day.

Across full-catalog scans of more than 90,000 Shopify product pages, about 1 in 4 stores had at least one critical Google visibility issue.

Scan my store for free

Free scan: issue types, counts and first fixes. Full report on every product page, not a sample: $49 once, no subscription.