Published: Last updated:
TL;DR
A product can look correct on the shop page while an older price, different variant or stale stock status reaches Google. Check the same item across the customer-facing page, its structured data and the product source submitted to Merchant Center before deciding what needs changing.
This guide gives a shop owner and their implementer a shared worksheet. Use it to record mismatches before changing your store. For decisions about which pages to create, start with the collection and product-page planning guide.
Compare three records of the same product
- Shop page: what a customer sees after following the submitted landing link, including the selected variant and its current buying information.
- Structured data: the Product and Offer information the page exposes for machines, checked against the visible product and relevant variant.
- Product source: the submitted record and its latest processing state in Merchant Center. Record the source name and submission time; an old local export is not proof of the current processed record.
Google's product-data specification describes attribute requirements and common discrepancies. The Product structured-data documentation explains the separate search appearance routes. A structured-data validation result alone does not establish Merchant Center account approval or publication.
A fictional variant reconciliation worksheet
Illustrative shop and product only. This example uses a navy, large storage bag with store item ID BAG-NV-L. These are invented planning values, not a real listing, product identifier or client result. No GTIN is provided: never invent one to complete a sheet.
| Check | Shop page | Structured data | Submitted product source | Action and owner |
|---|---|---|---|---|
| Item and variant | Navy, large; SKU BAG-NV-L | SKU BAG-NV-L; navy, large | ID BAG-NV-L, but size says medium | Catalogue owner checks the source mapping and corrects the size. |
| Price and currency | 48.00 GBP | Offer price 45.00; currency GBP | Price 48.00 GBP | Implementer checks why the template still exposes the old offer price. |
| Availability | Out of stock; ordering unavailable | OutOfStock | in_stock | Stock/source owner investigates update timing and verifies the current processed record. |
| Image | Navy, large bag | Matching navy product image | Image shows a red bag | Catalogue owner chooses the correct permitted image and checks the submitted image URL. |
| Landing URL | Opens navy, large selection | URL describes the relevant product/variant | Link opens default medium selection | Implementer checks variant links and the actual landing behaviour. |
Add the evidence location and check time to every observation. Where a field is absent, record "missing" rather than copying a value from another record and treating it as verified. Identify which catalogue or stock system is authoritative for each fact before changing templates or source mappings.
Keep identifiers and variants understandable
Use a separate row for each item or variant being checked. Record the store SKU, submitted item ID, variant attributes and any applicable manufacturer identifiers. Different systems may use different field names; the task is to establish which records describe the same sellable item, not force every identifier to have an identical value.
For variant grouping, compare the source's group identifier and attributes with the page's actual product relationships. Google's product-variant structured-data guide explains ProductGroup and its associated properties. Do not paste a generic markup example onto the page without checking the platform's existing output and variant URL behaviour.
Check changing prices and stock at a known time
Record when you checked the page, markup and processed source. A scheduled export, cache or delayed stock update can explain a discrepancy, but the cause still needs evidence. Recheck after the agreed refresh rather than assuming a successful upload corrected the public result.
Google's price requirements cover currency and agreement with landing-page and checkout pricing. If the item is on promotion, compare the relevant current and sale-price fields and dates using the sale-price guidance. A valid sale does not guarantee that a sale annotation appears.
Compare the same target country, currency and variant. Do not compare a UK page in pounds with a different market's source and label the difference an error. Verify the actual price the customer can buy at, including the applicable market settings, before correcting a field.
For stock, use Google's availability guidance to distinguish the supported states. A product description saying "available soon" is not enough to decide whether the submitted status should be preorder, backorder or out of stock. Ask the stock owner what orders the business actually accepts and can fulfil.
Record the correction and prove the recheck
Copy this row for each mismatch:
| Product/source reference | Field and evidence | Verified intended value | Owner and correction | Recheck and outcome |
|---|---|---|---|---|
| [SKU, item ID, source name, variant and landing URL] | [observed values and check time for page, markup and source] | [business-confirmed fact and its source] | [responsible person, change and date] | [reprocessed source, public page/markup result, outstanding issue and next review date] |
In the fictional example, the source owner records that the stock record was corrected. The recheck then asks whether the latest processed source says out of stock, whether the page still shows the same variant and whether its structured data agrees. Until those checks are complete, the worksheet stays open. A receipt for a file upload is not the final result.
Test the landing and image URLs without relying on an administrator session. Confirm the page loads the intended item and the image depicts it accurately. Use the image SEO checklist for photo permissions, useful alternatives and mobile presentation. Keep account credentials and private customer information out of the worksheet.
What a clean worksheet does not prove
Matching these fields is one operational check. Merchant Center policies, account status, other required attributes and processing issues still need review. Search features have their own eligibility and display decisions. Neither a passed markup test nor corrected product data guarantees impressions, ads approval, free listings, rankings or inclusion in an AI answer.
Record those outcomes separately from the correction. Use the ecommerce SEO reading guide for the wider store review and ecommerce SEO services to discuss an agreed website scope. A real-store investigation needs the relevant access, source ownership and responsibilities agreed first; this article does not promise ongoing source management.
Reviewed 23 October 2026. Product requirements and interfaces can change; check the linked Google documentation for the market and programme you use.
