A product can stop appearing on a Google surface for several reasons, and a mismatch notice is not proof that schema alone caused it. Start with the affected item and compare three representations of the offer: the data source submitted to Merchant Center, the landing page a shopper receives, and any product markup Google can read. Check the exact issue and timestamp in Merchant Center before editing anything.
Google's current Merchant Center guidance says it may compare the submitted price with the landing page and structured data. It also lists timing differences, variant selection, sale windows, currency, and data that appears only after JavaScript rendering among potential mismatch causes. A correction may need to be re-crawled and reviewed; it is not an instant reinstatement guarantee. Google: Mismatched product price
Diagnose one affected offer end to end
Pick a small, representative sample of affected product IDs and record each field from each surface. Do not begin with a sitewide feed rewrite. One incorrect product URL, a stale sale period, or a variant mismatch can affect a subset without explaining every item.
| Check | Merchant Center data source | Shopper-facing page | Product markup |
|---|---|---|---|
| Product identity | ID, title, brand, GTIN or variant identifier | Is the intended product and option selected? | Does the offer describe that same product or option? |
| Destination | link or mobile_link |
Does it load the matching product without redirecting to a substitute? | Does markup identify the same canonical offer? |
| Price | price, sale_price, effective dates, currency |
Is the relevant price clear on first load? | Does Offer.price and currency reflect that offer? |
| Availability | availability and date when relevant |
Can the customer order it, and is stock status clear? | Does the Offer availability match? |
| Market context | Country and any regional data | Does the correct market price and delivery state appear? | Is the page's markup consistent with that market? |
Capture the item ID, status, issue text, inspection time, URL, selected variant, and target country. This lets you compare the same offer at the same point in time instead of mixing a current page with an older feed snapshot.
Check the destination before editing structured data
Google identifies an incorrect product URL, missing product details, or a redirect to a similar item as possible causes of a different-landing-page issue. Follow the submitted URL on mobile and desktop. Confirm that it opens the intended product, that the relevant option is selected, and that the shopper can see the price, currency, availability, and purchase action. Google: Different product landing page
If the page changes by country, region, cookie, or variant, test the expected customer path and record the inputs. Do not assume what a crawler sees based on one logged-in browser. For regional offers, Google expects the landing page to show the corresponding regional price and availability when the regional URL is used. Google: Regional availability and pricing
Compare price and availability through the entire journey
For each sample, compare the submitted offer with what appears on initial page load, the selected variant, and checkout. A sale may have expired in one system but not another; the feed may have updated before the storefront cache; a price may depend on a variant the URL did not select; or the page may show a different currency for the target market. Google specifically says the submitted price should match the price shown on the landing page and notes that dynamically added price content can trigger mismatch issues. Google: Product data price and availability requirements
Availability also needs to make sense across the offer data, landing page, checkout, and markup. A product that cannot be shipped to the target region should not be represented as purchasable there. For preorders or backorders, check the expected availability date and whether it is visible to customers. See Google's availability guidance.
Validate markup without treating a valid result as approval
Inspect the product page's structured data for the correct product and Offer fields. Check price, currency, availability, selected variant, and URL. Use Google's Rich Results Test or the relevant Search Console report to catch markup problems, but remember that valid markup does not itself guarantee a Merchant Center listing, approval, rich result, or ranking. The product data source, policy status, crawl, and customer experience still matter.
If a third-party commerce platform generates the markup, check which catalog fields it uses and whether its cache updates when the catalog changes. Avoid maintaining separate hand-coded values that drift from the product system of record. Fix the upstream value or integration that created the discrepancy, then re-check the rendered page and submitted data.
Fix the source of truth and keep a small change log
When the mismatch is confirmed, update the relevant source and record what changed. If feed updates happen on a schedule, compare the schedule with storefront price and inventory changes. For frequently changing catalogs, evaluate the available update method against your volume and operational capacity; do not switch APIs just because one product was flagged.
After correcting the issue, check the item's current status in Merchant Center and follow the review option shown for that issue. Google says review and recrawl timing can vary; a review request does not guarantee approval. Avoid repeated requests before the underlying values and destination are consistent.
Product mismatch work sheet
Item ID and variant: [values]
Issue text and reported time: [Merchant Center]
Target country / currency: [values]
Submitted URL and attributes: [source snapshot]
Rendered URL and first-load values: [browser check]
Structured data values: [page inspection]
Checkout price / availability: [test path]
Confirmed source of mismatch: [evidence]
Correction and owner: [change log]
Status after recrawl or review: [current status]
References and limits
- Google Merchant Center: Mismatched product price
- Google Merchant Center: Different product landing page
- Google Merchant Center: Regional availability and pricing
- Google Merchant Center: Product data specification
- Google Merchant Center: Availability attribute
Interfaces and product eligibility can change. Confirm the live issue details and current documentation for the affected account and country. A correct feed and page can make an item eligible for review; they do not guarantee visibility on a particular Google surface.
Short-video script: Trace the same offer across three surfaces
Hook: “Merchant Center says price mismatch? Don’t edit the whole feed yet.”
Beat 1: “Choose one affected product ID. Compare the submitted price, the first-load product page, and the product offer markup.”
Beat 2: “Check the selected size or color, sale dates, currency, stock, market, and whether the page waits for JavaScript to show the price.”
Beat 3: “Fix the system that created the mismatch, then check the item's status after Google recrawls it. A valid schema test alone isn't an approval.”
Close: “Same product, same variant, same market, same values. Start there.”
Educational carousel: A five-point feed-to-page reconciliation
- Cover: Product disapproved? Trace the same offer before you rewrite the catalog.
- Identify: Record item ID, variant, issue text, timestamp, and target country.
- Open: Follow the exact submitted URL and confirm the intended item appears.
- Reconcile: Compare price, currency, availability, and sale dates with markup and checkout.
- Correct: Update the responsible data source or integration; preserve a change log.
- Recheck: Review current Merchant Center status after recrawl; do not promise a reinstatement date.
Field experiment thread: Test a feed correction safely
1/ Select a small sample of affected item IDs. Record the issue details and capture the same fields from the submitted data, first-load page, structured data, and checkout.
2/ Group the confirmed cause: wrong destination, variant mismatch, stale sale, currency, availability, rendering delay, or another issue shown in Merchant Center.
3/ Change only the confirmed source for the sample. Keep unrelated fields unchanged where operationally possible and record any unavoidable changes.
4/ Revisit the submitted URL and values after the next data update. Check the item's current approval or disapproval status and note the elapsed time.
5/ Compare like with like. Report the number of sampled items corrected and their current status; do not attribute broader visibility changes to one fix without supporting evidence.
Tool-neutral prompt pack: Review a Merchant Center mismatch
Prompt 1 — Evidence matrix
Compare these records for the same product ID and variant: [Merchant Center attributes], [rendered landing-page values at timestamp], [structured data], and [checkout]. Build a field-by-field mismatch table. Separate observed facts from hypotheses and list missing evidence. Do not infer that schema is the cause unless the records support it.
Prompt 2 — Root-cause triage
Here is the issue text, target country, item ID, URL, and update timeline: [details]. Rank plausible causes using only the supplied evidence. For each, state one safe check and the expected evidence. Do not recommend bulk edits or claim that a correction guarantees approval.
Prompt 3 — Change review
Review this proposed correction: [change]. Identify which source of truth it updates, which other surfaces must be checked, and what to record after recrawl. Flag any assumptions about regional currency, variants, caching, or JavaScript rendering.
Stop-doing swipe file: Catalog debugging without guesswork
Stop: “Structured data is valid, so Merchant Center must approve it.”
Use: “Markup validation covers markup syntax; verify item data, landing page, policy status, and the current Merchant Center issue.”
Stop: “The feed says in stock, so the customer can buy it.”
Use: “Check the target region, selected variant, checkout, and delivery availability.”
Stop: “One item is mismatched; rewrite every product.”
Use: “Sample affected IDs, group confirmed causes, and correct the responsible source.”
Stop: “We fixed it, so listings return today.”
Use: “Record the correction and check the current status after recrawl or review; timing and approval are not guaranteed.”
Hook–Value–Template: Correct the product record customers actually see
Hook: “Feed, product page, and markup need to describe the same offer.”
Value: A disciplined item-level comparison finds whether the error sits in the catalog, destination, variant selection, regional pricing, page rendering, or markup. It prevents a broad edit based on one unexplained notice.
Template: “For item [ID / variant] in [country], Merchant Center reports [issue] at [time]. The submitted data shows [value]; the first-load page shows [value]; structured data shows [value]; checkout shows [value]. The mismatch is [confirmed cause / unresolved]. We changed [source] on [date], and will check status after [next update or recrawl]. This does not yet establish [unverified outcome].”
Example: “For item 842-blue-M in the UAE, the feed's sale end date is later than the storefront promotion. The page now shows the base price while the feed still submits the sale price. We corrected the sale schedule in the catalog and will confirm the item status after the next data update.”
This is a diagnosis method, not a promise of eligibility or visibility.