Does the product page match the variant you submitted?

Compare one offer, in one context ↗

Google’s product specification requires submitted price and availability to agree with the destination. Its landing-page guidance also calls for the appropriate variant to be selected and for the product information to remain consistent during page load. These are documented shopping requirements, not a promise of AI recommendations.

Use this test before a feed release or an agent-assisted recommendation. Record the SKU, submitted URL, market, currency, customer price tier, and observation time. Compare public offers with public offers; a signed-in trade price is a different context.

Source: Google Merchant Center: Product data specification; Google Merchant Center: Landing page requirements

A correct price attached to the wrong variant still fails ↗

Fictional example: a merchant submits DEMO-36-BLK, a 36-inch black fixture at USD 420, in stock. The URL opens DEMO-30-CHR at USD 350. Both prices might be correct in the catalog. The submitted offer still fails because the destination selects a different item.

Repair the variant URL or selection behavior, then repeat the check in a fresh session. Compare the initial HTML with the rendered page. Confirm that the structured Offer belongs to the selected Product, rather than picking the first price found anywhere in the page.

Source: Google Search: Product variant structured data

Run six cases before trusting the connection ↗

These are original acceptance cases. “Pass” means that the captured evidence agrees for this task and time. “Fail” means a contradiction. “Hold” means insufficient evidence. A hold should not silently become a pass.

Variant identity comes before compatibility ↗

Google documents ProductGroup and Product relationships for variant markup. That helps describe a family; it does not establish that one member fits a particular installation.

A nominal width is not an installation range. Keep finish, dimensions, included components, and compatibility separate. If the source does not establish fit, the useful answer is to request the missing specification. Do not borrow a sibling variant’s dimensions or infer compatibility from a photograph.

Source: Google Search: Product variant structured data

Turn the example into your own release check ↗

The JSON download includes an expected offer, observed feed/page/structured records, a reason for each verdict, and fields for evidence. It is an internal test format, not a Merchant Center upload or a schema.org payload. Run it against your comparison logic before replacing the fictional records with authorized catalog data.

Keep raw observations beside normalized values. Converting “InStock” and “in_stock” to one status is reasonable; filling a missing currency from a nearby product is not. Set freshness limits by field and business need. A passing snapshot says nothing about tomorrow’s inventory.

• Capture the exact URL and selected SKU on mobile and desktop.
• Check the variant’s price, currency, availability, and image; include active sale dates when applicable.
• Save the initial response, rendered evidence, source timestamps, verdict, and owner of any correction.
• Retest only the corrected case and affected variants, then record the release version.