Price and availability are deceptively simple attributes. In a live ecommerce stack they can be produced by several systems: ERP or stock service, ecommerce platform, promotion engine, feed generator, structured data, Merchant Center and sometimes a marketplace or middleware layer. A mismatch means those systems did not agree at the moment Google compared them.
Google's current guidance is explicit: submitted price and availability should match the landing page, and structured data can be used to understand those values. For availability, Google also calls out consistency across the landing page, checkout, structured data and product data. That means this is as much an operating-model problem as a feed-format problem.
Think in terms of one commercial truth
The useful goal is not “make the feed say in stock”. It is: for the exact offer a customer can buy, every relevant layer should agree closely enough that the customer and Google see the same commercial promise.
| Layer | Price question | Availability question |
|---|---|---|
| Source / ERP | What is the current sell price and sale state? | What stock or fulfilment state is authoritative? |
| Ecommerce platform | Which price is assigned to the exact variant? | Can that exact variant be purchased? |
| Feed | What value was exported and when? | What status was exported and when? |
| Structured data | Which price does JSON-LD or microdata expose? | Which availability value is marked up? |
| Landing page | What does a customer see after selecting the variant? | What does the page say and can checkout complete? |
Most large-scale mismatches are timing problems until proven otherwise
Imagine stock changes at 10:02. The website updates immediately, the product feed is generated every four hours and Merchant Center processes the next file at 14:30. For several hours the systems describe different realities even though none of them is “broken”. At scale, that lag can create a recurring stream of mismatches.
The right update model depends on volatility. A furniture catalogue with stable stock may tolerate scheduled files. A high-volume retailer with rapid stock and price changes may need more frequent delivery or API-based updates. The important thing is to understand the maximum delay between source change and Google's processed value.
Ask for the timeline, not just the values
When debugging a mismatch, record when the source changed, when the landing page changed, when the feed was generated, when it was submitted and when Google reported the mismatch. Without timestamps, teams can mistakenly compare values that were never intended to be simultaneous.
Common causes I would check
1. Sale prices and promotion windows
A promotion starts on the site but the feed still holds the old base price, or the feed submits a sale price while the landing page has already ended the promotion. Time zones, scheduled jobs and caching can make short sale windows particularly fragile.
2. Variant selection
The feed submits the blue 256GB model but the landing page defaults to a cheaper black 128GB model. A crawler may initially see the default value even though the exact variant can be selected. Make sure the landing URL, visible selection and structured data identify the offer you submitted.
3. Member, bundle or conditional pricing
If the prominent page price depends on membership, quantity, location or another condition, make sure the product data reflects the price a user is actually eligible to receive under Google's requirements. Do not assume the lowest possible number is automatically the correct feed price.
4. VAT, currency and localisation
International stores can expose different tax or currency values by market. Confirm the target country's landing experience and feed are aligned, and avoid location logic that causes Google and a normal user to receive materially different offer information.
5. Structured data is stale
The page visually shows £79 but JSON-LD still says £89. Google's guidance specifically recommends keeping structured data aligned with visible landing-page values. A theme, app or cache can update one layer without updating the other.
6. “In stock” means different things to different systems
Your ERP may treat inbound stock as available, the website may allow back-ordering and the feed may classify it as in stock. Define how operational states map to Google's accepted availability values and keep that mapping consistent.
7. Caching and CDN behaviour
A product page, API response or structured-data fragment may be cached longer than the visible stock component. Check the response Google can actually fetch, not only what an authenticated browser session shows you.
A practical diagnostic workflow
Start with Google's example and timestamp
Use an affected item from the issue details and note the values Google reported. Avoid choosing a random product that happens to be healthy now.
Identify the exact offer and variant
Confirm item ID, landing URL, currency, country, size/colour/capacity and whether the product is on sale. Variant ambiguity causes many false assumptions.
Inspect visible page and structured data separately
Do not treat them as the same layer. Check the rendered price/stock message and the Product/Offer structured data. They can diverge.
Trace the feed value back to source
Was the submitted value copied directly, changed by an attribute rule, taken from a supplemental source or generated by a feed platform?
Map the refresh schedule
Document source update, website refresh, feed generation, data-source submission and Merchant Center processing. Find the longest delay.
Fix the operating cause
If the catalogue changes faster than the feed pipeline can represent it, increasing feed quality without changing cadence may not stop recurrence.
Automatic item updates: useful safety net, poor excuse for stale data
Google can use structured data and other extraction methods to update some item information when submitted data is out of date. This can reduce mismatch-related disapprovals. Google's own documentation is equally clear that automatic item updates are not a replacement for regular product-data updates.
I treat automatic updates as resilience. They can help absorb temporary lag; they should not become the reason an organisation never fixes a four-hour stock delay or broken structured data.
What to monitor after the fix
- percentage of active offers with price/availability issues;
- time from source change to channel update;
- structured-data validation on representative PDP templates;
- sale start/end synchronisation;
- high-volatility SKUs and categories;
- mismatch recurrence after releases, theme changes or feed-rule edits.
If a problem repeatedly returns, move it from “Merchant Center support” into the engineering or operational backlog. Recurrence is evidence that the system needs redesign, not another manual correction.
A useful acceptance test
Pick a product, deliberately change price or stock in the authoritative source and measure how long each downstream layer takes to reflect it. That simple test often tells you more about mismatch risk than reviewing a hundred healthy products.
Common questions
How often should a product feed update?
Often enough that the submitted data stays aligned with the rate at which price and availability change. The right cadence is a business and architecture decision, not one universal number.
Will structured data fix a stale feed?
It can support automatic item updates, but Google's guidance says this does not replace regularly updating Merchant Center product data.
Can I mark a product out of stock just to stop it showing?
Google's availability guidance distinguishes true availability from pausing products. Use the appropriate pause or destination-control mechanism rather than misrepresenting inventory.
Why does the mismatch disappear when I check the page?
The catalogue may have updated since Google crawled it. Use the issue timestamp and examine the update sequence rather than assuming the warning was wrong.
Official Google references reviewed for this guide
- Inaccurate price / landing-page mismatch
- Mismatched product availability
- Structured data markup and automatic item updates
- Tips to optimise product data
Merchant Center changes over time. This guide was reviewed against current Google documentation on 29 September 2026.
Want a second pair of eyes on the actual setup?
Start with the free Merchant Center & Feed Triage. No account access is needed for the first look. Send the website, catalogue size and the symptom and we will tell you where we would investigate first.