Must every product variant page have self-contained structured data?

The Citead team, updated

In short. On multi-page product sites, each page needs full markup for its own entities and a direct URL for its selected variant.

Definition: Self-contained structured data is markup on a page that contains enough information to understand the entities defined on that page without requiring an off-page entity. For a multi-page product variant setup, Google requires each page to carry full, self-contained markup for its on-page entities.

Key facts

  • Google describes a multi-page site as one where variants of the same product are accessible on different pages, alongside a single-page design where variants are selected without page reloads, in its product variant structured data documentation.
  • For a multi-page site, each page must have full and self-contained markup for the entities defined on that page. Off-page entities should not be needed to understand that page's markup.
  • Google's example repeats the full ProductGroup definition on each variant page because the group contains common attributes such as brand, material, and age group.
  • Each variant needs a unique ID in its corresponding markup, such as an sku or gtin value.
  • A distinct URL must preselect each variant, including its image, price, availability, and add-to-cart state.

What does “self-contained” mean here?

Google's multi-page example places a full ProductGroup on each page. That group carries shared information and the variants represented on the current page. A page therefore describes its own product entities in the markup it publishes, rather than depending on a group definition stored on a different URL.

The same documentation says that a ProductGroup has no single canonical URL in this design because the variants are distributed across pages of equal importance. The page-specific markup still identifies the group and connects the pages through variant URLs. The distinction is between where a group is represented and whether the current page can be understood from its own entities.

How should the entities be distributed?

Schema.org defines a ProductGroup as a group of products that vary in well-described ways, such as size, color, or material. Its description treats the group as a template for shared characteristics, while Product carries the individual variant. Google's product variant documentation applies that model to two multi-page patterns: variants nested under hasVariant, or variants separate from the group and connected with isVariantOf.

The nested example has this shape, with a full current-page variant and a URL-only entry for a variant on another page:

{
  "@type": "ProductGroup",
  "name": "Wool winter coat",
  "productGroupID": "44E01",
  "variesBy": [
    "https://schema.org/size",
    "https://schema.org/color"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Small light blue coat",
      "size": "small",
      "color": "light blue",
      "offers": {
        "url": "https://www.example.com/coat/lightblue?size=small"
      }
    },
    { "url": "https://www.example.com/coat/green?size=small" }
  ]
}

The URL-only object is a cross-page link shown in Google's example. It does not replace the full markup for the variant that the current page represents. The group identifier, variant properties, and product details remain part of the page that defines that entity.

What must the site make available?

Each variant URL must select the corresponding variant directly. Google's documentation connects that URL requirement with crawling and says that preselection includes the right image, price, availability, and ability to add the variant to the cart. A page that changes those details only after an interaction lacks the direct URL behavior described in the multi-page guidance.

The variant markup also needs the regular Product structured data that applies to the chosen Google product feature. Google's Product structured data documentation separates Product snippets for pages where a product cannot be bought directly from Merchant listings for pages where customers can purchase products. It says the page can provide Product structured data, a Merchant Center feed, or both, while the Search Central guidance focuses on markup in web pages.

For identity, Google's variant guidance requires a unique ID for every variant and a unique ID for each product group. The group ID can use productGroupID, while a variant can use inProductGroupWithID. Schema.org describes productGroupID as a textual identifier for a ProductGroup, and variesBy records the property or properties by which its variants differ.

FAQ

Do you need to repeat every variant in full on every page?

Google's example fully defines the variants represented on the current page and uses URL-only objects for variants on other pages. You still repeat the full ProductGroup definition on each variant page.

Can you use one canonical group page for all variants?

That pattern belongs to Google's single-page design. For multi-page sites, the documentation says the ProductGroup has no single canonical URL because the variants are distributed across equally important pages.

Does a URL parameter satisfy the direct-selection requirement?

Yes, Google's example uses a distinct URL with query parameters to preselect a variant. You need the selected page to expose the matching image, price, availability, and add-to-cart state.

Sources

  1. Google Search Central, "Product variant structured data (ProductGroup, Product)", 8 September 2026
  2. Google Search Central, "Introduction to Product structured data", 10 December 2025
  3. Schema.org, "ProductGroup", undated

Check how a page reads to answer engines. Open the GEO score analyzer

Test a page and see what to fix first

The analysis usually takes less than 10 seconds and needs no account.

400,000+ pages scored in the public benchmark