Treat every purchasable option as its own offer, then show how those offers belong to one parent product.

A product page may say a shoe comes in five sizes and three colours. The product file still needs to identify each real combination that can be priced, stocked, selected, and purchased. If every option collapses into the parent, a shopping system can lose the context needed to compare or select the right item.

Good variant data is not about creating more rows for its own sake. It is about keeping identity, grouping, option details, price, availability, image, and page address connected.

Separate the item ID from the group ID

A variant ID identifies one purchasable option, such as a medium olive jacket. A group ID connects that jacket to the small, large, black, and navy versions of the same core product. Reusing one ID for every option erases the distinction. Giving every option a separate ID without a group makes the family harder to reconstruct.

Use stable values from the commerce system when possible. Do not replace a child option's own ID with the parent ID during export.

  • One unique item ID per purchasable option
  • One shared group ID for true variants of the same product
  • Clear option attributes such as size, colour, material, or capacity
  • A parent title that stays consistent across the group

Make each option tell one complete story

The selected option should carry the price, currency, stock, image, product code, and other facts that apply to it. If the red version is out of stock, the blue version should not inherit that state. If the large size costs more, the large variant record and page state should show that price.

Use customer-readable option names. Internal abbreviations can be useful in an operations system, but a shopping system needs enough context to interpret whether BK means black, a style code, or something else.

Visible product pageSame product facts
Structured dataSame product facts
Source catalogSame product facts

Use stable links for addressable variants

Where the platform supports it, a variant link should open the correct option with the matching image, price, and stock state selected. This gives crawlers and product-data validators a stable state to compare.

A temporary selection in a browser that leaves the page address unchanged can still help a shopper, but it is weaker evidence for systems trying to identify one variant directly. Do not call the page contradictory until the same addressable option and market have been compared.

Compare the same option

A default offer and a shopper-selected offer can legitimately differ. Confirm the option and page state before classifying a mismatch.

Know what should not be grouped as a variant

Related products, accessories, bundles, different garment types, subscriptions, and quantity breaks are not automatically variants. The test is whether the options are versions of the same core product and whether the shopper selects among them as that product.

Incorrect grouping can merge distinct products. Missing grouping can scatter one product family. A catalog scan should flag the observed relationship problem without inventing a relationship the merchant did not supply.

Validate the page and the product file together

Start with one product that has a manageable option set. Compare its source records, normalized variants, exported rows, visible selectors, direct option links, structured product information, and stock states. Then repeat with a product that uses different option logic.

Fix the earliest confirmed break. If the source export loses child IDs, repair the export before adjusting the page. If the file is correct but the page never selects the submitted option, the storefront may own the fix.

Sources Checked