The short answer
Open the exact URL submitted for the variant. Compare its selected item, price, currency, and availability with the feed and that variant’s structured data. A family page or a valid schema test is not enough. If a required fact is missing or the records disagree, hold the recommendation and fix the source.
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.
| Surface | Observed value | Decision |
|---|---|---|
| Feed | DEMO-36-BLK · USD 420 · in stock | Expected offer |
| Selected page variant | DEMO-30-CHR · USD 350 · in stock | Fail: wrong destination selection |
| Structured offer | DEMO-36-BLK · USD 420 · in stock | Does not cancel the visible mismatch |
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.
| Case | Change to the expected offer | Expected result |
|---|---|---|
| V1 · Control | All three surfaces agree | Pass |
| V2 · Wrong selection | Page selects DEMO-30-CHR | Fail |
| V3 · Old price | Structured offer still says USD 400 | Fail |
| V4 · Availability conflict | Feed says in stock; page says out of stock | Fail |
| V5 · Missing currency | Page price is 420 with no currency evidence | Hold |
| V6 · Unknown fit | Buyer requires a 36-inch opening; fit range is unknown | Hold the fit claim |
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.
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.
Check the handoff after a repair
For a supported Shopify-style family repair, Specstead is an independent service built by this guide’s author. Its paid package includes a full preserved snapshot and a later CSV recheck. The recheck compares the exported repaired values; it does not certify storefront rendering or platform acceptance. Review the package against a fresh export before importing, because preserved prices, inventory, and other untouched values can have changed.
The optional paid service currently includes up to ten rechecks during 30 days of access. That window does not make the original snapshot current. Export again, inspect unrelated changes, and keep the merchant in control of the import.
Source: Specstead: full-snapshot import and recheck example; Specstead: agent workflow and service boundaries
Sources & scope
Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.
- Google Merchant Center: Product data specification ↗
Supports matching submitted product facts with landing pages and structured data. The six-case test is an original editorial method.
Checked September 5, 2026 - Google Merchant Center: Landing page requirements ↗
Supports variant selection and consistent information during page load. This guide does not test or certify a real merchant account.
Checked September 5, 2026 - Google Search: Product variant structured data ↗
Documents ProductGroup and Product relationships. It does not establish installation compatibility.
Checked September 5, 2026 - Specstead: full-snapshot import and recheck example ↗
Author-owned service. This fictional worked example explains the specific repair boundary; it is not independent evidence of accuracy, merchant adoption, or commercial performance.
Checked October 11, 2026 - Specstead: agent workflow and service boundaries ↗
Author-owned service documentation. Describes current input limits, private capability handling, review and billing sequence; check the runtime manifest for current purchase availability.
Checked October 11, 2026
AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.
Editorial policy & corrections ↗Cite this guide
George Kelly. Does the product page match the variant you submitted? iamgeorgekelly. Updated October 11, 2026. https://www.iamgeorgekelly.com/field-guide/product-variant-acceptance-test
Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.