Check a Product Variant Before You Fix Its Structured Data

Before changing a product's markup, identify the exact item and variant a visitor is viewing. A shirt in one size can have a different price or availability from another size. Comparing the page for one variant with the markup for another creates a finding that may be wrong before anyone edits the store.

This exercise uses a fictional notebook product. The identifiers, amounts and stock states are illustrative and do not describe a real store or a STEADYWRK offer. Download the review sheet and keep a separate row for every variant you inspect.

Establish one reproducible view

Open the product's public URL in a fresh browser session. Select the intended variant and record the resulting URL, selected option labels and observation time. If the URL stays the same, record the selection steps so another reviewer can reproduce the view.

Use this fictional example as your starting note:

Item	Observed value
Product	Demo notebook
Variant	Blue cover, small
SKU	DEMO-BLUE-S
Displayed price	14.00
Displayed currency	JOD
Availability	Out of stock

Copy the values as displayed before interpreting them. “Unavailable in this size” and “ships later” may describe different states. If the currency is absent, record not shown; your location or another product's currency does not settle the question.

Compare the same fields in the same state

Inspect the structured data emitted for that view, including any markup added after the page loads. Identify the Product and Offer that refer to the selected variant. When several products or offers appear, keep their identifiers with your notes so you do not accidentally compare a recommendation card with the main product.

Google's product variant documentation describes ProductGroup, Product and the relationship between a group and its variants. The Product documentation distinguishes product snippets from merchant listings. Check the documentation relevant to your page structure; this worksheet does not replace a complete markup implementation review.

Imagine that the fictional page above emits this partial comparison excerpt, not a complete markup template:

{
  "sku": "DEMO-BLUE-S",
  "offers": {
    "price": "19.00",
    "priceCurrency": "JOD",
    "availability": "https://schema.org/InStock"
  }
}

The SKU agrees with the selected variant, but the price and availability disagree. That supports two specific findings. It does not show whether the page or the markup is the source of the error. Ask the store owner which catalog record is authoritative before copying either value into the other.

Write a correction that can be checked

A useful correction record contains the URL, selection steps, SKU, observed field values, confirmed intended values and the place the change was made. Include the observation time because inventory and promotions can change while someone is investigating.

For the example, the record might say: “The owner confirmed that DEMO-BLUE-S is out of stock at the displayed 14.00 JOD. The Offer emitted by this variant still reports 19.00 and InStock. Update the data source responsible for that Offer, then inspect the same selection again.”

That wording is actionable. “Fix SEO” is not enough to identify which value should change. If the owner cannot confirm the intended offer, keep the finding open instead of inventing a price or availability value.

Repeat the inspection after the change

Reload the page in a fresh session and reproduce the variant selection. Inspect the visible offer and the emitted markup again. Record the later result next to the earlier one. If the product uses several URLs or languages, check the relevant versions independently; one corrected URL does not establish that every version changed.

Keep matched, mismatched and could not inspect as separate outcomes. An unavailable page, a script error or an unreadable report is not a clean result. Also keep payment testing separate: matching Product and Offer fields does not demonstrate that checkout, fulfillment or refunds work.

Use the result to choose the next step

For one clear mismatch, the store owner may be able to correct the source directly. For a broader review, compare the Store Guard scope with the sample report, then read the field-by-field report guide. The useful outcome is a correction someone can reproduce and recheck; structured-data changes do not guarantee indexing, rich results or sales.