Product and Variant Schema for Shopping Surfaces

Q: Can I add review or rating markup if I don't have real reviews?

No. AggregateRating and Review markup must reflect genuine, verifiable reviews visible on the page and comply with the applicable provider policy. If there are no qualifying reviews, omit those properties. Valid Product and Offer data can stand without a rating, but no markup proves that an external engine will use or surface it.

Q: How should product variants be modeled?

Model the family as ProductGroup, identify its variant dimensions with variesBy, and connect variant Product nodes with hasVariant or isVariantOf. Choose a single-page or multi-page architecture from the site's real selector and URL behavior, then bind each variant's identifier, canonical URL, image, price, availability, and Offer to that exact variant.

Q: Do I need a GTIN, or is a SKU enough?

Use every identifier that truthfully applies. SKU is the merchant's internal identifier; a genuine GTIN is a global trade identifier, and brand plus MPN can identify manufactured goods when no GTIN exists. Never invent an identifier, and do not treat identifier markup as proof that an external consumer matched or selected the product.

Published April 23, 2026 · ClickRadius Institute

Product structured data can label a product family, its exact variants, offers, identifiers, shipping terms, return terms, and genuine reviews. Google documents provider-specific product snippet and merchant-listing features, but valid markup is not a universal admission ticket to an AI answer and does not prove that any external engine crawled, selected, compared, recommended, or cited the item. This guide covers the vocabulary, the single-page and multi-page variant architectures, and the evidence boundaries that keep implementation claims honest.

What product markup can establish

Structured data is a publisher-supplied declaration about the visible page. It can make facts less ambiguous to consumers that support the vocabulary, while each provider still controls crawling, indexing, feature eligibility, retrieval, ranking, recommendation, and citation.

According to Google's Product structured data documentation, supported product markup helps Google understand product information and can make a page eligible for product snippets or merchant-listing experiences. Eligibility is provider- and feature-specific; it is not evidence of inclusion in an AI shopping candidate set or of any later recommendation.

Product markup can label the merchant's claims. Validation can test syntax and provider rules. Only later observation can show what an external surface actually displayed, and that observation still does not prove causation.— ClickRadius Institute analysis

The anatomy: ProductGroup, Product, Offer, and rating

ProductGroup describes a family that varies by properties such as size or color. Each Product describes an exact product or variant. Offer, connected through offers, describes commercial terms. AggregateRating and Review describe qualifying customer feedback. Required and recommended properties depend on the provider feature being targeted, so consult that feature's current documentation rather than treating one example as universal.

Here is a single-variant Product example for a physical retail good:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "TrailGrip Waterproof Hiking Boot",
  "image": [
    "https://example.com/img/trailgrip-1x1.jpg",
    "https://example.com/img/trailgrip-4x3.jpg"
  ],
  "description": "Full-grain leather waterproof hiking boot with a Vibram outsole and gusseted tongue.",
  "brand": { "@type": "Brand", "name": "Summit Outfitters" },
  "sku": "SO-TG-450",
  "gtin13": "0192837465012",
  "mpn": "TG-450",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/boots/trailgrip",
    "priceCurrency": "USD",
    "price": "174.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@type": "Organization", "name": "Summit Outfitters" }
  }
}

Notice what this block does not contain: any rating. That is deliberate, and we return to it below. Everything present is a fact the merchant can stand behind — the price is the price, the GTIN is the manufacturer's, the availability reflects real stock.

Variants require a product-family model

When a product has variants, model the family as a ProductGroup, name the variant dimensions with variesBy, and connect variant Product nodes with hasVariant or isVariantOf. Choose a single-page or multi-page variant architecture from the site's real selector and URL behavior. Bind each variant's SKU or GTIN, canonical URL, image, and Offer — including its price and availability — to that exact variant.

In a single-page architecture, one canonical page can describe the group and the variants available through its selector. In a multi-page architecture, each directly selectable variant has its own canonical URL and variant-specific facts; follow the target provider's current rules for whether and how the complete ProductGroup is repeated on those pages. Do not collapse different prices, images, availability states, or identifiers into an unspecified family-level offer.

Price and availability: the properties that decay fastest

Price and availability are time-sensitive facts, so markup can silently fall out of sync with the page and checkout. Google's documentation requires structured-data price and availability to match what the user sees. Generate these properties from the applicable current inventory and pricing source rather than a stale template value. Use the Schema.org availability enumeration that actually applies, such as InStock, OutOfStock, PreOrder, BackOrder, or Discontinued, and verify the public output after updates.

Identifiers: SKU, GTIN, MPN, and brand

Identifiers can help a supporting consumer distinguish an exact item from a family or another variant. They have different issuers and scopes, and their presence does not prove that an external engine matched records across sources:

sku — the merchant's stock-keeping identifier, whose primary scope is that merchant's catalog.
gtin (and its length-specific forms gtin8/gtin12/gtin13/gtin14) — a global trade item number such as a UPC or EAN. Provide the genuine assigned value whenever one exists.
mpn — manufacturer part number, the honest fallback when no GTIN exists.
brand — a Brand or Organization node. Brand plus MPN is a valid identity pair when a GTIN is genuinely unavailable.

Schema.org's Product vocabulary defines these properties. Supply only identifiers that truthfully belong to the exact product or variant. For a unique or handmade item with no assigned GTIN, omit the GTIN; use other applicable genuine identifiers rather than inventing one to fill the field.

Shipping and returns in supported merchant listings

Shipping cost, delivery time, and return terms can affect a purchase. Two structured-data relationships can state those terms for consumers and provider features that support them.

shippingDetails (an OfferShippingDetails node) lets you declare shipping cost and delivery time by destination. hasMerchantReturnPolicy (a MerchantReturnPolicy node) declares your return window and terms. Google's merchant listing documentation describes how these fields feed shipping and return annotations. Here is the Offer extended with both:

"offers": {
  "@type": "Offer",
  "priceCurrency": "USD",
  "price": "174.00",
  "availability": "https://schema.org/InStock",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": {
      "@type": "MonetaryAmount",
      "value": "0",
      "currency": "USD"
    },
    "shippingDestination": {
      "@type": "DefinedRegion",
      "addressCountry": "US"
    },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 5, "unitCode": "DAY" }
    }
  },
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "applicableCountry": "US",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn"
  }
}

These fields can label facts such as free shipping or a 30-day return window. They must match the exact offer and published policy; for example, do not declare FreeReturn when a restocking fee applies. A complete declaration does not establish that an assistant retrieved, used, or preferred it.

Ratings and reviews: the one hard rule

AggregateRating and Review make claims about other people's experiences and carry strict factual and provider-policy boundaries. A strong number is not permission to mark it up on every page or for every subject.

Publish rating markup only when the exact reviews, subject, visible presentation, aggregation method, and target provider rules support it. If any required evidence is missing, omit the rating properties.— ClickRadius Institute analysis

Google's review snippet guidelines define eligible subjects and quality rules, while its general structured-data policies prohibit fake or misleading markup. A structured-data manual action affects rich-result eligibility; it is not proof of a broader ranking effect. ClickRadius records observable rating evidence and provider applicability separately rather than treating the presence or absence of stars as proof of AI-shopping use.

When genuine, qualifying reviews are visible and the target feature permits them, the markup may include an aggregate and individual reviews:

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.6",
  "reviewCount": "218",
  "bestRating": "5"
},
"review": [{
  "@type": "Review",
  "reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
  "author": { "@type": "Person", "name": "D. Alvarez" },
  "datePublished": "2026-03-30",
  "reviewBody": "Kept my feet dry through two river crossings. True to size."
}]

The reviewCount and ratingValue must equal what a human sees on the page. If you display 218 reviews at 4.6 stars, the markup says 218 and 4.6 — no rounding up, no counting deleted reviews. This is the same honesty-of-numbers discipline that governs every credible signal.

Do not invent the external engine's pipeline

Identifiers, offers, and variant relationships give a structured-data consumer labeled facts it may use. They do not reveal whether a particular shopping assistant fetched the page, preferred JSON-LD over another source, matched the product across sites, placed it in a candidate set, or used any field when ranking an answer. Those are external-engine decisions. Treat the markup as a precise declaration, then measure public outcomes separately.

Off-site retailer, marketplace, and review records are independent evidence only after their subject, controller, facts, and time are verified. They should not be converted into a fixed causal share or described as proof that on-page markup drove a recommendation. We treat that boundary in Entity Authority vs Keywords in AI Search.

Merchant listing eligibility, briefly

Google distinguishes product-snippet experiences from merchant-listing experiences and publishes different required and recommended properties for them. Use the property list for the exact Google feature you are targeting, and separately evaluate Merchant Center feeds where applicable. Passing either set of rules does not establish eligibility for, or use by, a different provider or an AI answer.

Implementation checklist

Choose the real single-page or multi-page variant architecture before generating markup.
Use ProductGroup, variesBy, and hasVariant/isVariantOf when the catalog exposes variants.
name mirrors the visible product title; image supplies multiple aspect ratios.
A stable identifier: gtin when it exists, else brand + mpn; include your sku alongside.
A complete Offer: price, priceCurrency, availability, wired to live pricing and inventory so it always matches the page.
shippingDetails and hasMerchantReturnPolicy reflecting your real, published terms.
Ratings and reviews only if genuine and visible on the page; otherwise omit them entirely.
Validate every template with the Schema.org validator and Google's Rich Results Test after each change.

Frequently asked questions

Can I add review or rating markup if I don't have real reviews?

No. AggregateRating and Review markup must reflect genuine, verifiable reviews visible on the page and comply with the applicable provider policy. If there are no qualifying reviews, omit those properties. Valid Product and Offer data can stand without a rating, but no markup proves that an external engine will use or surface it.

How should product variants be modeled?

Use ProductGroup for the family, variesBy for its variant dimensions, and hasVariant or isVariantOf to connect the exact products. Select a single-page or multi-page architecture from the real site behavior, and attach each variant's identifier, canonical URL, image, price, availability, and Offer to that variant rather than to an ambiguous family.

Do I need a GTIN, or is a SKU enough?

Use every identifier that truthfully applies. A SKU is the merchant's internal identifier; a genuine GTIN is a global trade identifier, and brand plus MPN can identify manufactured goods when no GTIN exists. Never invent an identifier, and do not treat identifier markup as proof that an external consumer matched or selected the product.

ClickRadius measures observable product-site evidence within five weighted AI Readiness families and can prepare eligible corrections. Applying an approved exact revision requires current authorization and a publishing connection proven capable of the required effect; provider receipt and independent public-origin reread remain separate evidence. Neither state proves external-engine use. Get your free AI Readiness Score, or see plans on the pricing page.