Quick answer: A canonical tag tells Google which URL is the real one when the same content is reachable at several addresses. Shopify creates duplicates by design — every product is reachable at /products/x and /collections/y/products/x — and its default canonical handles that case correctly. The problems are the ones Shopify does not handle: tag filters, sort parameters, and internationalised duplicates.

Most Shopify stores do not need to touch canonical tags at all. The ones that do usually have a specific symptom: Search Console reporting "Duplicate, Google chose different canonical than user", or a collection page indexed dozens of times with different query strings.

What Shopify already gets right

Every Shopify theme emits <link rel="canonical"> in theme.liquid pointing at canonical_url. For products, that resolves to /products/handle regardless of which collection path the shopper arrived through. This is correct and you should not change it.

That single default handles the most common duplication in Shopify, which is why canonical tags are far less of a problem here than on custom platforms.

Where it breaks

Tag-filtered collections. /collections/shirts/blue is a distinct URL with its own canonical pointing at itself. On a store with many tags this generates hundreds of thin near-duplicate pages, all self-canonical, all competing. This is the single most common canonical problem on Shopify.

Sort and pagination parameters. ?sort_by=price-ascending produces the same products in a different order. Shopify's canonical usually strips these, but themes that build their own canonical from request.url do not.

Search result pages. /search?q=… pages are self-canonical and, if linked from anywhere crawlable, get indexed. They should be noindexed rather than canonicalised.

Markets and locale duplicates. A store selling in three regions can serve the same product at three URLs. This needs hreflang, not canonicals — canonicalising them to one locale removes the others from their local results entirely, which is nearly always the wrong outcome.

Fixing the tag-filter case

Two defensible approaches, and the choice depends on whether the filtered pages have search demand.

If nobody searches for "blue shirts" as a phrase, canonicalise the filtered views to the parent collection. Consolidates signals, removes the thin pages, costs nothing.

If they do — "womens waterproof walking boots" is a real query — the filtered page is your best landing page for it, and canonicalising it away throws that away. Leave it self-canonical, give it a unique H1 and intro, and treat it as a page rather than a filter.

The wrong answer is to do neither and let hundreds of self-canonical filter URLs accumulate.

Situation Canonical Tag Setup Outcome
No search demand for filtered view (e.g., “blue shirts” not searched) Canonicalise filtered URL to parent collection Consolidates ranking signals, removes thin pages
Filtered view targets a real search query (e.g., “womens waterproof walking boots”) Leave filtered URL self-canonical; add unique H1 and intro Preserves landing page, captures search traffic
No action taken (none) Hundreds of self-canonical filter URLs accumulate, competing against each other

Verifying rather than assuming

Canonical tags are advisory. Google treats them as a hint and regularly ignores them, which is exactly what the "Google chose different canonical" report is telling you: your tag said one thing and Google disagreed.

When that happens the cause is almost always a conflicting signal — internal links pointing at the non-canonical URL, a sitemap listing it, or a redirect chain. Fix the signal, not the tag.

Check with the URL Inspection tool in Search Console, which shows both the canonical you declared and the one Google selected. If they differ, that is the whole diagnosis.

Related