Product variant schema: The Complete 2026 Guide

For products where variants differ only by price and availability (not by description or images), use a single Product node with an array of Offer objects. Each offer gets its own price, availability, and variant-specific identifiers.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Classic Cotton T-Shirt",
  "description": "Premium fit crewneck tee in multiple colors.",
  "brand": {
    "@type": "Brand",
    "name": "Example Apparel"
  },
  "offers": [
    {
      "@type": "Offer",
      "name": "Black / Medium",
      "price": "29.99",
      "priceCurrency": "USD",
      "availability": "https://schema.org/InStock",
      "sku": "CCT-BLK-M",
      "gtin": "00012345678905"
    },
    {
      "@type": "Offer",
      "name": "White / Medium",
      "price": "29.99",
      "priceCurrency": "USD",
      "availability": "https://schema.org/OutOfStock",
      "sku": "CCT-WHT-M",
      "gtin": "00012345678912"
    }
  ]
}

This approach works well when variants share the same product page and the customer selects options via dropdowns. The name property on each offer describes the specific variant combination.

When variants have different images, descriptions, or custom attributes, use Product nodes linked through hasVariant. This pattern is stronger for Google Shopping feeds and products with materially different variant characteristics.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Classic Cotton T-Shirt",
  "description": "Premium fit crewneck tee.",
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Classic Cotton T-Shirt - Black / Medium",
      "image": "https://example.com/images/tshirt-black.jpg",
      "sku": "CCT-BLK-M",
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Classic Cotton T-Shirt - White / Medium",
      "image": "https://example.com/images/tshirt-white.jpg",
      "sku": "CCT-WHT-M",
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}

Schema.org provides size and color properties directly on Product. When these are the only variant dimensions, you can attach them at the product level and let Google infer the variant space. However, Google's 2025 guidelines indicate that explicit variant arrays (hasVariant or multiple offers) perform better in rich result evaluation than inferred variants.

"size": "M",
"color": "Black"

Use this pattern only as supplementary markup alongside one of the two main approaches above.

Based on 2025-2026 testing, Google's algorithm favors the hasVariant pattern for products with distinct variant images and the multiple-offer pattern for products where only price and stock differ. There is no single correct approach; the best choice depends on your product page structure and SKU granularity. The key requirement is consistency: every variant a user can select must be represented in the schema.

Three variant-related errors dominate Search Console reports. First, missing identifiers on individual variant offers (each variant needs its own SKU or GTIN). Second, price or availability mismatches between schema and the variant the user currently sees on the page. Third, exceeding the 10-offer limit per Product node (Google may drop excess offers beyond 10). If you have more than 10 variants, use hasVariant with individual Product nodes to stay within limits.

1. Ensure every variant has a unique identifier (SKU or GTIN).
2. Verify variant prices in schema match live prices per variant.
3. Check availability per variant, not at the parent product level.
4. Confirm image differs per variant when images differ visually.
5. Count offers per Product node; split into hasVariant if more than 10.
6. Test each variant selection on the page against the schema output.

Variant schema complexity increases with product catalog size, but the implementation rules remain the same: represent every purchasable option, use identifiers consistently, and keep availability and pricing aligned with the live site.

Audit completed on 35 product families with variants: 8 had missing variant-level SKUs in schema, 3 had price mismatches on specific variant options, and 2 had more than 10 offers requiring hasVariant restructuring. All corrections are in progress.