Compare markup with the exact variant state
Check identity, price, currency, stock and applicable policy for the exact lamp variant being displayed. Record the storefront and generated-data values together before changing a synthetic stock state. This catches a validly formatted offer attached to the wrong item, which a syntax-only check would not resolve.
Worked example — illustrative data.
| Field | Visible fictional storefront | Validation question |
|---|---|---|
| Product identity | Arc lamp, brass, SKU ARC-BR | Does markup identify this exact variant? |
| Offer price | USD 85 | Do amount and currency match? |
| Availability | Brass unavailable; black available | Is each offer attached to the correct variant? |
| Policy | Returns link beside purchase information | Is the referenced policy accurate and applicable? |
Take a dated snapshot before changing test inventory. Record the selected variant, displayed price, markup value, product-feed value if used and source-system value. Change one synthetic stock state in staging, then inspect the page again. Separate parsing errors from content mismatches: a passing validator cannot confirm a warehouse count. Retain the comparison sheet so a later discrepancy can be traced to the update path rather than guessed at.
Cached markup can disagree with visible stock
Cached markup may lag behind the visible interface. If the button says unavailable while an offer still says in stock, trace caching and data generation before changing the product record merely to satisfy the validator.
Accept the implementation only when the relevant variant agrees across the visible page and generated data. Search appearance remains outside that acceptance decision.
Continue with Guides for stores, software teams and local businesses, Technical SEO services and What belongs on an eCommerce product page?.
For product structured-data requirements, see Google product structured-data documentation (checked November 2026).