A shopper clicks a product priced one way in a listing and finds a different offer on the page. That contradiction is worth fixing before adding more structured data. Compare the exact item across the visible page, merchant feed and markup, then trace each mismatch to its source.

This matters most when a product changes: a price is updated, a size becomes unavailable or a delivery condition is revised. Use the audit below to find contradictions before adding more markup.

Identify the item before comparing the fields

Start with the exact product and variant. Record its page URL, internal identifier and selected options. A feed entry for a blue medium shirt should not be compared casually with a page currently showing the black large option.

Decide how your site handles variant URLs and canonical pages before treating differences as errors. The canonical URLs and product variants guide explains the page decision that comes first.

Use one representative item with several variants for the initial audit. It will expose more real problems than checking only a simple one-option product.

Compare a small set of important fields

Build a worksheet with a column for each public surface. Read the live output rather than assuming the administrative record reached every destination.

Field What should remain consistent
Product identity Correct item, brand where applicable and variant
Price and currency Actual offer, including the selected option
Availability Current status and any conditions
Images The pictured product and relevant variant
Shipping and returns The policies that actually apply to that offer
Landing URL A working destination that presents the expected item

Treat a blank unknown as a question to resolve. Do not fill it with an attractive guess to make a validation warning disappear.

Choose markup for the actual page

Google’s Product structured-data introduction distinguishes ways to provide product information through on-page markup, Merchant Center feeds or both. Its merchant listing documentation gives the requirements for purchase-oriented experiences.

A quote-request page should not acquire an invented purchasable offer just because an example schema contains one. Likewise, do not add a review count or rating unless it represents genuine review information that meets the applicable requirements.

Use the documentation for your actual page type and selling model. Completing a code example is not a reason to claim a price, shipping promise or policy the business has not established.

Test a real change through the full chain

Choose a controlled product update in your normal workflow, then check when the visible page, structured data and feed reflect it. Record the source system and how each surface is refreshed.

For example, if a particular size becomes unavailable, inspect that exact variant. A general product-level “available” label may hide the distinction. Check the landing page again after changing the selected option.

Assign a person or process to unresolved differences. Otherwise, a spreadsheet of errors can become a permanent record of contradictions rather than a repair plan.

Record discrepancies so someone can resolve them

Use one row per conflict, with enough detail to reproduce it. For example, a hypothetical medium blue shirt might show $24 on its selected page but $22 in its feed. Record the variant identifier, both values, the source that owns the price and when you observed the difference. These numbers illustrate the audit; they are not an actual offer.

Then identify the cause: was only one system edited, did the feed fail to refresh, or did a variant land on the wrong page? The fix follows from that cause. Manually changing a derived field can hide the problem until the next synchronization overwrites it.

A useful discrepancy record has five parts: item, conflicting field, source of truth, correction owner and recheck result. Close it only after the public surfaces agree. If a system intentionally shows a range or a different currency, explain and verify that behavior rather than treating every difference as an error.

Validate syntax and meaning separately

Use Google’s Rich Results Test for supported structured data, then inspect the content yourself. A technically valid offer can still contain the wrong price. After release, use the appropriate Search Console and Merchant Center diagnostics where those services are configured.

Eligibility does not guarantee a particular search presentation. Keep the objective concrete: accurate public information with a repeatable update path.

Create a release checklist for future changes

Before a product update goes live, confirm identity, variant mapping, price, availability, imagery and applicable policies. Recheck after publication. The product-page checklist is a useful companion for the visible customer experience.

When those surfaces agree, both buyers and automated systems have a clearer account of what the product actually offers.