Canonical URLs for AI crawlers on Shopify

Canonical URLs have always mattered for SEO, but their weight in AI retrieval is meaningfully higher because of how AI retrievers index and cite. A classic search engine sees three near-duplicate URLs for the same product, figures out through its link graph and on-page signals which is the 'real' one, and consolidates ranking credit to it. An AI retriever sees three URLs, has no link graph advantage, and often treats them as three separate documents — splitting any citation authority the product has earned across three URLs and leaving all three with less than they should have individually.

The net effect on your AI citation share is worse than a simple three-way split. Because retrievers often prefer the 'cleanest-looking' URL, duplicates can lead a retriever to cite the URL you least wanted cited — a collection-nested URL that strips your pretty breadcrumb, or a locale-prefixed URL that routes international shoppers to the wrong currency. A correct canonical is not just an SEO hygiene item; it is an explicit instruction to retrievers about which URL represents the product's identity.

Shopify's URL structure is powerful and flexible, and that flexibility is exactly what creates the duplication problem. A product named 'classic-tee' in a shop called example.com is reachable at every one of these URLs out of the box — each serving essentially the same content, each crawlable, each potentially indexable.

Root product URL

https://example.com/products/classic-tee — the canonical default, what every store links to. Simplest and shortest.

Collection-nested URL

https://example.com/collections/shirts/products/classic-tee — generated automatically when a user browses via a collection. Shopify links to this form in collection templates unless you explicitly override.

Locale subpath URL

https://example.com/en-us/products/classic-tee or /a/locale/en-uk/... — generated by Shopify's Markets feature for multi-region stores. Different content for currency/language but the same underlying product.

Filtered / sorted URL

https://example.com/products/classic-tee?variant=12345&utm_source=newsletter — every tracked link, every variant selection, every filter state creates a distinct crawlable URL unless normalised.

AMP / legacy URLs

Some older themes ship AMP versions at /products/classic-tee.amp. Fewer stores have these in 2026 but they do exist.

Shopify's default canonical implementation handles the basic root vs collection-nested case — the theme's canonical_url helper resolves to the root URL in most cases. It does NOT consistently handle locale subpaths, custom parameter stripping, or pagination. Those are the gaps where most merchant stores leak citation authority.

Below is a pattern we ship on every Shopify store we audit. It works with Online Store 2.0 themes (Dawn and derivatives) and with older Vintage themes with minor adjustments. Drop it into the head section of theme.liquid, replacing the default canonical line. It handles all four duplicate cases in six lines of Liquid.

{%- if template contains "product" -%}
  <link rel="canonical" href="{{ shop.url }}{{ product.url }}">
{%- elsif template contains "collection" and paginate.current_page > 1 -%}
  <link rel="canonical" href="{{ shop.url }}{{ collection.url }}?page={{ paginate.current_page }}">
{%- elsif template contains "collection" -%}
  <link rel="canonical" href="{{ shop.url }}{{ collection.url }}">
{%- else -%}
  <link rel="canonical" href="{{ canonical_url }}">
{%- endif -%}

What each branch does

• Product pages — always canonicalise to the root /products/<handle> path, ignoring any /collections/<slug>/ prefix. This is the single biggest fix.
• Collection pages on page 1 — canonicalise to the bare collection URL, not to any ?page=1 variant that might appear via navigation.
• Collection pages on later pagination — canonicalise to the paginated URL itself (page > 1 pages are NOT duplicates of page 1 and should be self-canonical).
• All other pages — fall back to Shopify's built-in canonical_url helper, which handles blog posts, articles, and static pages correctly.

A canonical tag in the page head is one signal. The url field inside Product JSON-LD is another. When they disagree, retrievers treat it as an internal inconsistency and commonly downweight the page in citation candidacy. Our audit data across several hundred Shopify stores shows a clear pattern: stores with coherent canonical + schema url earn meaningfully more AI citations than otherwise-matched stores with inconsistent declarations.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | json }},
  "url": "{{ shop.url }}{{ product.url }}",
  "image": {{ product.featured_image | image_url: width: 1200 | prepend: "https:" | json }},
  "brand": {
    "@type": "Brand",
    "name": {{ product.vendor | json }}
  }
}
</script>

Canonical in head

Absolute URL, matches shop.url + product.url exactly. No trailing slash differences. No query parameters unless intentional.

url field in JSON-LD

Exactly the same string as the canonical. Same protocol, same host, same path, same trailing slash state.

og:url in Open Graph

Should also match. Facebook, LinkedIn, and social preview cards treat disagreements the same way retrievers do — as low-trust.

Sitemap XML entry

The <loc> tag for this product in sitemap.xml must match too. Shopify generates this automatically from product.url; if your canonical overrides differ from the default, verify the sitemap still agrees.

Shopify Markets is the most common place we see canonical hygiene go wrong. A merchant selling in the US, UK, and Canada ends up with /products/classic-tee (US default), /en-gb/products/classic-tee (UK), and /en-ca/products/classic-tee (Canada) — each with different pricing and currency, but otherwise the same content. These are not duplicates in the SEO sense; they are language / region variants. The canonical rule here is the opposite of the collection-nested rule: each locale variant is self-canonical, and hreflang links them together.

<link rel="canonical" href="{{ shop.url }}{{ request.path }}">
{%- for locale in shop.published_locales -%}
  <link rel="alternate" hreflang="{{ locale.iso_code }}" href="{{ shop.url }}/{{ locale.iso_code }}{{ request.path }}">
{%- endfor -%}
<link rel="alternate" hreflang="x-default" href="{{ shop.url }}{{ request.path }}">

• Each locale variant is self-canonical — /en-gb/products/x canonicalises to itself, not to the US default.
• hreflang links declare the relationship between variants so retrievers serve the right locale to the right audience.
• x-default points at the US or primary-market URL so retrievers in untargeted locales fall back correctly.
• Match each hreflang link with a reciprocal in the corresponding locale variant — they must be bidirectional.

1. 1Stale canonical to an old domain after a migration — canonical still points at the legacy host long after the new domain is live. Fingerprint: canonical host does not match current hostname.
2. 2Trailing slash inconsistency — canonical says /products/x and sitemap says /products/x/ (or vice versa). Retrievers treat these as distinct URLs. Pick one, use it everywhere.
3. 3Canonical includes query parameters from the request URL — utm_source, fbclid, or variant IDs leak into the canonical. Strip all non-identifying query parameters.
4. 4Collection-nested canonical pointing back to the collection URL itself — the canonical on /collections/shirts/products/tee points at /collections/shirts, which is a broken non-sequitur retrievers will ignore.
5. 5Self-redirecting canonical loops — canonical URL 301s back to the same page, or A canonicalises to B which canonicalises to A. Fingerprint: URL Inspection shows 'Canonical: declared inconsistently'.
6. 6Missing canonical on paginated collection / filter pages — pages 2+ have no canonical at all, so retrievers treat every page as a standalone document with no parent.