Product Variant Schema Guide (Size, Color, SKU)
Last Updated: March 28, 2026 · 10 min read
Variant pages are one of the biggest rich result failure points in e-commerce. The correct approach depends on whether each variant has its own URL and whether pricing differs by option.
When to Use Offer vs AggregateOffer
- Offer: one sellable SKU at one price on one page.
- AggregateOffer: a parent product page with multiple variant prices.
- Offer array: when listing multiple variants on the same canonical page.
Variant Checklist
- Unique SKU per variant if variant has dedicated purchase option.
- Correct availability per variant (in stock/out of stock).
- Currency and price match visible page values.
- Avoid duplicate product entities across parent and child pages.
- Use canonical strategy for variant URLs consistently.
Parent Page vs Variant URL Strategy
| Architecture | Recommended schema | Notes |
|---|---|---|
| Single parent URL, options in selector | Product + AggregateOffer | Use low/high price and offerCount |
| Each variant has own URL | Product + Offer per URL | Each URL gets its own SKU/price/availability |
| Hybrid (parent + variant URLs) | Parent summary + child specific entities | Avoid duplicated full entities across URLs |
Common Variant Markup Errors
- Using one global price while the selected variant price differs.
- Declaring multiple SKUs but exposing one Offer only.
- Missing brand/GTIN on high-volume commerce templates.
- Showing in-stock UI while schema says OutOfStock.
- Publishing stale sale prices after promotion ends.
India and US Commerce Notes
For India marketplaces and D2C stores, include INR pricing, delivery timelines, and seller clarity where relevant. For US catalogs, ensure return policy and shipping fields align with checkout messaging.
In both regions, the most important trust signal is consistency between schema, rendered UI, and final checkout values.
Validate Before Launch
Test variant templates in Product Schema Validator, then verify price grouping behavior with AggregateOffer Validator.
Implementation Pattern (Template + Data Layer)
For most modern stacks, keep a single schema renderer and map variant data from the product data layer. Avoid hardcoding schema in templates because price, availability, and selected options change frequently.
- Generate schema server-side from catalog API where possible.
- If client-side variation selection updates price, update visible and schema values together.
- Validate one example per template variant (single-SKU, multi-SKU, discounted, out-of-stock).
- Use monitoring checks to catch stale prices after promotions end.
Error-to-Fix Quick Table
| Error | Root cause | Fix |
|---|---|---|
| Invalid priceCurrency | Currency not mapped by market | Use ISO currency code per storefront |
| Offer price mismatch | Schema reads old cache value | Bind schema to same source as UI |
| Missing availability | Variant state not propagated | Map stock state per variant |
| Duplicate Product entities | Parent + child both output full product | Keep one canonical product entity strategy |
FAQ
Should each color have a separate Product entity?
Only if each color has its own crawlable URL and purchasable state. Otherwise use aggregate structures.
Can I include both Offer and AggregateOffer?
Yes, if one represents a selected SKU and one represents price range, but keep semantics clear and non-duplicative.
Do variants affect rich snippets?
Yes. Incorrect variant data is a frequent reason for price mismatches and rich result suppression.