Product Variant Data for AI Search: Size, Color, and the Right SKU

The Recommendation Is a SKU, Not a Product

When a shopper asks an AI assistant for "a waterproof shell jacket in men's large, under $250," the useful answer is not a product page. It is a specific variant that exists, is in stock, is the right size, and costs what the assistant says it costs.

This is where a lot of otherwise well-optimized catalogs fall apart. Stores invest in product schema and clean descriptions at the parent-product level, then leave variant data implicit — buried in a dropdown that only renders after a shopper clicks. A model reading that page sees one product with one price and no reliable way to know that the large is sold out and the XL costs $30 more.

As AI shopping moves from suggestion to transaction, variant-level accuracy stops being a nice-to-have. An agent that adds the wrong SKU to a cart creates a return, a refund, or a failed checkout — and the store that caused it becomes a less reliable source.

What Breaks at the Variant Level

Four failure patterns account for most variant confusion:

1. Options exist only in JavaScript. The size and color selectors populate client-side. AI crawlers that do not execute JavaScript see a single price and one availability state.
2. Every variant is a separate, ungrouped product. The catalog exports twelve near-identical items with no signal that they are one garment in four colors and three sizes. Models treat them as competing products and often pick arbitrarily.
3. Variant-specific price and stock are not exposed. The page shows a "from" price. The model quotes the lowest number regardless of which variant the shopper actually wants.
4. Variant URLs contradict the canonical. Query-string variant URLs are crawled, indexed inconsistently, or canonicalized in a way that strips the very detail the shopper asked for.

The fix is the same in each case: make variant relationships and variant-level facts explicit in machine-readable form, not just in the interactive UI.

Use ProductGroup and hasVariant

Google added structured data support for product variants in February 2024, introducing the ProductGroup type alongside Product. The pattern is straightforward:

• ProductGroup represents the parent — the jacket itself. It holds properties shared across variants: brand, description, aggregate review data, and productGroupID (your parent SKU).
• variesBy declares which properties differentiate the variants. Google supports specific schema.org URIs here, including https://schema.org/color, https://schema.org/size, https://schema.org/material, https://schema.org/pattern, https://schema.org/suggestedAge, and https://schema.org/suggestedGender.
• hasVariant nests each child Product, carrying its own SKU, GTIN, price, availability, and the variant-defining values.
• isVariantOf does the inverse on a child Product, pointing back to its group. This is the property to use when each variant has its own distinct URL.

Two practical rules follow from this. First, do not duplicate shared data on every child — put brand and reviews on the group and let the variants inherit. Second, every child variant needs its own identifier and its own offer. A variant without a distinct price and availability is not really marked up as a variant.

If your platform generates a single flat Product block per page, this is the highest-value schema upgrade available to a catalog with options. On Shopify, variant attributes that do not map to a native field belong in metafields so they can be templated into JSON-LD consistently.

Group Variants Correctly in Your Feed

Structured data covers the crawl path. Feeds cover the ingestion path — Google Merchant Center, and increasingly the same catalog format used by AI shopping surfaces.

The core attribute is item_group_id. Every variant of the same product must share the same value. Google's documentation is explicit that variants are products differing only by details like color and size for apparel, or memory, display size, processor, and graphics options for electronics — and that each variant is submitted as its own item with the shared group ID.

Beyond grouping, get the differentiating attributes right:

• Submit size for any product that varies by size, and color for any product that varies by color, on every variant in the group.
• As of May 2026, Google supports a variant_option attribute that explicitly identifies which properties are variant-determining. Google recommends providing color through both variant_option and the color attribute when color is what distinguishes the variants.
• Keep gtin and mpn variant-specific. A shared identifier across sizes tells downstream systems these are the same physical item, which they are not.
• Use item_group_title where supported so the family has a clean name independent of any single variant's title.

Because several AI shopping surfaces accept the same structured catalog format retailers already send to Google, a well-grouped Merchant Center feed is usually the fastest path to variant-accurate representation elsewhere. That overlap is covered in more depth in The OpenAI Product Feed.

Fix Variant URLs and Canonicals

The URL layer is where variant intent gets lost. A workable pattern for most stores:

• Keep one canonical for the parent product page — normally the URL with no variant preselected.
• Make every variant preselectable via a distinct URL, typically a query parameter. Loading that URL must render the correct price, availability, image, and identifier server-side.
• Do not let the variant URL render parent-level defaults. If ?variant= changes nothing in the initial HTML, the URL is decorative and provides no signal.
• Never canonicalize a variant URL to an unrelated product or to a collection page. That is a stronger negative signal than having no variant URLs at all.

Test this the way a crawler experiences it: fetch a variant URL with JavaScript disabled and confirm the price, stock status, and SKU in the raw HTML match what a shopper would see.

Write Variant Attributes for Humans Too

Models reason over text as well as markup. A size chart rendered as an image gives a language model nothing. The same chart as an HTML table with explicit measurements — chest, sleeve, inseam, in both centimeters and inches — is directly quotable.

The same applies to the vocabulary you use. "Forest," "moss," and "olive" are fine as merchandising names, but pair each with a plain color value a model can match to a shopper asking for green. Fit language deserves the same treatment: state whether an item runs true to size, and say what body measurements a size corresponds to rather than only what size label it carries.

For apparel and footwear especially, fit and sizing questions are among the most common things shoppers ask assistants. Answering them in structured FAQ content on the product page turns a common objection into citable material.

A Practical Audit

Pick your ten highest-revenue products with options and check each:

• Parent page emits ProductGroup with productGroupID and a correct variesBy
• Every variant appears as a child Product with its own SKU, GTIN, price, and availability
• Feed items share one item_group_id per family, with variant-specific size, color, and identifiers
• Variant URLs render correct server-side price and stock with JavaScript disabled
• Size charts and fit guidance exist as text, not images
• Out-of-stock variants report OutOfStock rather than silently disappearing

Variant data is unglamorous work, and it is exactly the kind of detail that separates a catalog an agent can transact against from one it has to guess about. If you want a structured read on where your catalog stands, that is what an AI visibility audit is for, and product optimization is where the fixes get implemented.