Map the product family before writing markup
Google supports ProductGroup alongside Product markup to describe related variants. The variesBy, hasVariant and productGroupID properties express the grouping and its differences. A shared product family and an individual sellable variant should have clear identities. Eligibility for a search feature does not guarantee that Google will display it.
Build a small product map with your catalogue owner. Include the parent style, individual SKU, colour, size, product URL and offer source. Check whether a style sold in several colours uses one page or separate pages. The technical implementation should follow the real storefront model, rather than force the catalogue into an unrelated example.
Keep the offer aligned with the selected variant
A shopper who selects a particular size should not see markup describing a different available size or an outdated price. Review the page in the same state as the structured data being inspected. Document how variant selection, availability and currency affect what is visible and what is emitted.
Include awkward cases in the brief: one sold-out size, a colour on promotion, an unavailable combination and a product with different regional prices. These examples expose mismatches that a check of the default variant alone can miss. Ask which system is responsible for each field before deciding where to fix it.
Review the rendered page and the data together
Validate representative URLs using the relevant structured-data testing tools, and compare the results with the product facts. A syntactically valid document can still contain an incorrect offer. Check that identifiers remain consistent and that links open the intended product state.
Keep a brief validation record: tested URL, variant, observed price, observed availability, date and owner. Recheck after theme, catalogue or pricing changes. For large catalogues, use a representative sample from each product pattern and investigate recurring problems at template level.
Make the hand-off specific
The SEO brief should identify the mismatch and the expected product fact, not simply request more schema. Attach a concrete example and identify whether the fix belongs to the theme, product feed or catalogue data. After the change, verify the same example again before expanding the release.
Faccelerate’s useful role in this workflow is to bring the evidence into a reviewable brief. A product-data correction remains a decision for the responsible team. This guide explains a storefront implementation pattern; it does not claim that connector access automatically updates structured data.
One jacket, several sellable variants
Imagine a jacket offered in navy and sand, each in three sizes. The team identifies the shared style and six sellable variants. The navy medium example has its own SKU, current price and stock state. The review compares that exact selection with its emitted offer, then repeats the check for a sold-out size and the promotional colour. No price or availability is inferred from the parent style alone.
Turn the guide into a useful review
- Map style, variant, SKU and URL identities.
- Verify selected colour, size, price and stock together.
- Test normal, sold-out and promotional states.
- Recheck representative products after template changes.
Reference material
Platform guidance checked 3 October 2026. Examples and working checklists are Faccelerate editorial illustrations.
Bring the question.
Keep the context.
Map the relevant sources and specialist workflow for your team.
Explore your stack
