Surfacing Shopify variants to AI engines

Shopify handles product variants well in its admin and storefront UI — the variant picker on a modern Dawn theme is a clean dropdown experience for shoppers. The problem is that the clean shopper experience often comes at the expense of machine-readable variant data. Three structural patterns cause AI retrievers to miss, misread, or invent variant information on Shopify products.

1. 1JavaScript-only variant pickers. Some themes build the variant dropdown client-side from a JSON blob. Retrievers that do not execute JavaScript (which is most of them) see only the first variant's content in the HTML, and have no visibility into the other variants at all.
2. 2Product schema emits only the selected variant. Default Shopify Product schema often represents only the currently-selected variant's offer, omitting the full variant matrix. Retrievers have no way to know that the product comes in six sizes and four colours.
3. 3Feeds collapse variants into a parent product. Some merchant-feed integrations export only the parent product record, not the variants, which means ChatGPT Shopping, Google AI Shopping, and Bing Shopping cannot show variant-specific availability or pricing.

The consequence is that retrievers sometimes 'hallucinate' variants — inferring that a men's shirt probably comes in S, M, L, XL when the actual catalog only stocks M, L, XL, XXL. Hallucinations usually align with common category expectations, so customers get mildly wrong answers that look reasonable but erode trust when they try to buy.

Schema.org's ProductGroup type is designed specifically for the case Shopify variants represent — a single product style that comes in multiple purchasable variants. ProductGroup describes what varies (size, colour, spec) via the variesBy property, and the individual variants are separate Product nodes linked via hasVariant. This is the structure Google Shopping, Bing Shopping, ChatGPT Shopping, and Perplexity all understand and consume.

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Carter Chelsea Boot",
  "productGroupID": "chelsea-boot-carter",
  "description": "Handmade leather Chelsea boot in three colours and seven sizes.",
  "variesBy": ["https://schema.org/color", "https://schema.org/size"],
  "brand": {
    "@type": "Brand",
    "name": "Example Footwear"
  },
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "CHL-CARTER-BLACK-42",
      "name": "Carter Chelsea Boot - Black, 42",
      "color": "Black",
      "size": "42",
      "offers": {
        "@type": "Offer",
        "price": "240.00",
        "priceCurrency": "GBP",
        "availability": "https://schema.org/InStock",
        "url": "https://example.com/products/carter-chelsea-boot?variant=12345"
      }
    },
    {
      "@type": "Product",
      "sku": "CHL-CARTER-BROWN-42",
      "name": "Carter Chelsea Boot - Brown, 42",
      "color": "Brown",
      "size": "42",
      "offers": {
        "@type": "Offer",
        "price": "240.00",
        "priceCurrency": "GBP",
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}

variesBy

Array of schema.org properties the variants differ on — typically size, color, material, pattern. Tells retrievers which dimensions matter for this product.

hasVariant

Array of Product nodes, one per variant. Each carries its own sku, the variesBy values (color, size), and its own Offer with price and availability.

Offer.url per variant

Each variant's offer can include a variant-specific URL (/products/slug?variant=12345). Retrievers use this for deep-linking to the exact variant the shopper wants.

productGroupID

Stable identifier for the style as a whole. Useful for retrievers to group variants across feed and schema contexts.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": {{ product.title | json }},
  "productGroupID": {{ product.handle | json }},
  "description": {{ product.description | strip_html | truncate: 300 | json }},
  "url": "{{ shop.url }}{{ product.url }}",
  "variesBy": [
    {%- for option in product.options -%}
      "https://schema.org/{{ option | downcase }}"{%- unless forloop.last -%},{%- endunless -%}
    {%- endfor -%}
  ],
  "brand": {
    "@type": "Brand",
    "name": {{ product.vendor | json }}
  },
  "hasVariant": [
    {%- for v in product.variants -%}
    {
      "@type": "Product",
      "sku": {{ v.sku | json }},
      "name": {{ v.title | json }},
      {%- for opt_name in product.options -%}
        {%- assign idx = forloop.index0 -%}
        {%- assign opt_value = v.options[idx] -%}
        "{{ opt_name | downcase }}": {{ opt_value | json }},
      {%- endfor -%}
      "offers": {
        "@type": "Offer",
        "price": {{ v.price | money_without_currency | json }},
        "priceCurrency": {{ cart.currency.iso_code | json }},
        "availability": {%- if v.available -%}"https://schema.org/InStock"{%- else -%}"https://schema.org/OutOfStock"{%- endif -%},
        "url": "{{ shop.url }}{{ product.url }}?variant={{ v.id }}"
      }
    }{%- unless forloop.last -%},{%- endunless -%}
    {%- endfor -%}
  ]
}
</script>

• Iterate product.variants — every purchasable variant gets its own Product node.
• Map product.options to the variesBy array — whatever the merchant named (Size, Color, Material) becomes a schema property.
• Per-variant name combines product title with variant title for disambiguation.
• Per-variant URL uses the ?variant={{ v.id }} parameter so deep links resolve to the correct selection.
• Availability is per-variant — reflects actual stock status per SKU, which retrievers use to filter for in-stock options.

Correctly-emitted ProductGroup schema handles the majority of AI retrievers, but the simplest and most robust signal is a visible HTML variant table on the page — server-rendered, not JavaScript-injected. This has the double benefit of being crawlable by every retriever regardless of its schema parsing sophistication, and of satisfying the schema-mirror rule (schema content should be visible on the page in some form).

{%- if product.variants.size > 1 -%}
  <section class="product-variants" aria-label="Available variants">
    <h3>Available variants</h3>
    <table>
      <thead>
        <tr>
          {%- for option in product.options -%}
            <th>{{ option }}</th>
          {%- endfor -%}
          <th>Price</th>
          <th>Availability</th>
        </tr>
      </thead>
      <tbody>
        {%- for v in product.variants -%}
        <tr>
          {%- for opt_value in v.options -%}
            <td>{{ opt_value }}</td>
          {%- endfor -%}
          <td>{{ v.price | money }}</td>
          <td>{%- if v.available -%}In stock{%- else -%}Out of stock{%- endif -%}</td>
        </tr>
        {%- endfor -%}
      </tbody>
    </table>
  </section>
{%- endif -%}

• Rendered server-side in Liquid, visible without JavaScript.
• Mirrors the data the schema emits — same variants, same prices, same stock.
• Accessible by default (proper table markup, header rows, aria-label).
• Visually unobtrusive with light styling — most merchants collapse it into an expandable section for users while keeping it always-rendered for retrievers.
• Hidden via CSS (display:none) is a bad idea — retrievers and Google both downweight hidden content. Use aria-expanded accordion patterns that are accessible and indexable.

Merchant feeds (Google Merchant Center, Bing Merchant Center, the Agentic Commerce Protocol feed) are another surface where variant data reaches retrievers — and another place where default Shopify settings sometimes get it wrong. The feed specification for all three requires one row per variant (identified by unique SKU or GTIN), with the parent product linked via item_group_id. Some feed integrations collapse all variants into a single parent row, which means retrievers see only the default variant and miss the rest.

One row per variant

Every purchasable SKU gets its own feed row with its own id, price, availability, and variant-identifying attributes (size, color).

item_group_id

Links all variant rows of a single product together. Usually the product's handle or a stable product ID.

Variant-identifying attributes

size, color, material, pattern. One column per variant dimension, populated on every row even if the dimension doesn't vary for a given product.

Variant-specific URL

The link column should point to the variant-specific URL (?variant=12345) so clicks land on the exact variant the shopper selected.

Variant-specific GTIN

If you have GTINs per variant (most apparel brands do), each row carries the correct GTIN for that variant. Reusing a single parent GTIN across variants causes feed disapprovals.

1. 1JavaScript-only variant picker — load page with JS disabled, check whether variants are visible. Fix: server-render a variant table as fallback.
2. 2Product schema with a single variant's offer — check JSON-LD with Rich Results Test; look for hasVariant array. Fix: switch to ProductGroup with hasVariant.
3. 3Parent GTIN reused on all variants — each variant should have its own GTIN if you have them. Fix: set GTIN per variant in admin, render per-variant.
4. 4Availability set on the product, not per variant — retrievers then assume all variants are in stock. Fix: set availability per variant in schema and feed.
5. 5Feed collapses variants — feed has one row per product, not per variant. Fix: set feed integration to variant-level.
6. 6Variant URLs that don't deep-link — all variants share the same URL with no ?variant= parameter. Retrievers can't surface the specific variant. Fix: use product.url with variant.id in schema and feed.