WooCommerce Variable-Product Schema: Check Every Represented Variation

For a WooCommerce variable product, the structured data should describe one product group and the variations a shopper can actually buy, each with its own identifier, price, and availability. Check it in three passes: list the purchasable variations in WooCommerce, compare them with the variants in the markup, and test a few specific combinations against the page. Expect gaps; different plugins represent variations differently, and none should be assumed to cover a whole catalog.

Learn how Google models variants

Google’s product variant documentation, checked September 27, 2026, uses a ProductGroup as the parent and nests each variation as a Product under hasVariant. The key properties:

Google lists color, size, suggestedAge, suggestedGender, material, and pattern as the supported variesBy values. It says variant names should be more specific than the group, giving “Wool winter coat - green, size small” as an example. Its technical guidelines also say each variant must be selectable at a distinct URL: “The site must have the ability to preselect each variant directly with a distinct URL (using URL query parameters).” Preselecting a variant, it adds, “includes showing the right image, price, and availability, as well as allowing the user to add the variant to the cart.” Google’s merchant listing documentation, checked the same day, describes offers.url as a URL that “may be the preferred URL for the current page with all variant options appropriately selected.”

Inventory the parent and purchasable variants

Start in WooCommerce, because the markup should follow the store and not the reverse. WooCommerce’s variable product documentation, checked September 27, 2026, notes that each variation can have its own SKU, price, sale price, stock, image, weight, dimensions, and description, and that a variation with a blank SKU falls back to the parent’s SKU.

For one product, write down:

1. The attributes used for variations (for example, color and size).
2. Every variation, with its SKU, barcode, regular and sale price, stock status, and whether it has its own image.
3. Variations using “Any” for an attribute. WooCommerce “highly recommend[s]” defining all attributes of all variations, and warns that “Any” choices can make variations effective duplicates of each other, which “can lead to confusing behaviors.”
4. Variations with no price. WooCommerce says they “don’t show in your store,” and markup may skip them.
5. Duplicate SKUs. A variation that inherits the parent SKU does not have a unique identifier of its own.

For a larger catalog, WooCommerce’s product CSV export (the Export button on Products > All Products, with variations included; checked September 27, 2026) gives you one row per variation, with a Parent column naming its product. Filter it to one parent product at a time.

An illustrative example from the fictional garden.example:

Two of these rows already flag problems before you open the markup: neither blue variation has an image of its own, and one has no unique SKU.

Compare URLs, attributes, and offers

Capture the product page’s server HTML and extract the ProductGroup, as described in the product schema check. Then compare the markup with your inventory:

Then test the URL requirement. Open the product and select a variation. Check whether the address bar changes. Then try opening the product with the variation’s attributes in the query string, for example ?attribute_pa_color=green&attribute_pa_size=small (attribute slugs are illustrative; use your own), and see whether the theme preselects that variation. Record whether each variation has a URL that loads it selected. If none does, markup cannot supply one truthfully.

Know what WP Visibility 2.10.3 prints for variations

With WP Visibility’s Schema and WooCommerce modules on (the defaults when WooCommerce is active), checked against the 2.10.3 release, a variable product gets:

• A ProductGroup with the product name; the description, image, and brand when available (the brand is read from a global pa_brand attribute); and a productGroupID set to the parent SKU, or the product ID when there is no SKU.
• variesBy built from the variation attributes. Color (or an attribute named colour), size, material, and pattern become schema.org URLs. Any other attribute is published as its store label, such as “Length”, which is not one of the values Google lists as supported.
• Up to 30 hasVariant entries, drawn from the first 30 variations in the order WooCommerce returns them, disabled variations included. Each carries the variation’s sku when WooCommerce returns one (it supplies the parent SKU when the variation’s own is blank) and, when the price is numeric, an offer with price, priceCurrency, and availability. A variation with neither a SKU nor a numeric price is left out, but it still counts toward the 30.
• No price range or single offer on the group itself, and the aggregate rating on the group when reviews are enabled and present.

It does not add variant names, images, URLs, GTINs, or attribute values such as color: Green to each variant. On a product with more than 30 variations, variations beyond the thirtieth are not represented. Treat these as fixed limits of that release when you compare against Google’s guidance, not as settings you can change. Variant offer prices follow the same stored-price rule as simple products; the price mismatch guide explains how that interacts with tax display.

Validate representative combinations

You do not need to test every variation of every product, but you do need to test the risky ones.

1. Pick samples. For each variable product type in your store, pick one variation that is in stock, one out of stock, one on sale, and one without its own SKU or image.
2. Check each against the page. Select the variation on the product page and compare the shown price and stock message with that variant’s offer.
3. Run the Rich Results Test on the product URL. Note detected items, errors, and warnings. Google’s variant documentation recommends deploying a few pages and using the URL Inspection tool “to test how Google sees the page.”
4. Record the limits. Write down any variation that is missing from the markup, any variant without a unique ID, and whether variation URLs exist.

What the results mean:

Checklist

• Every purchasable variation listed from WooCommerce, with SKU, price, stock, and image.
• No “Any” variations, or each one understood.
• Each variation has its own SKU or barcode.
• Variant count in the markup compared with the store, and any cap noted.
• At least four representative variations checked against the page.
• Whether each variation has its own URL recorded.