Price and availability mismatch
Why price and availability mismatch is the most common and most dangerous disapproval, how Google's crawl compares to your feed, refresh cadence, structured data, and preemptive disapproval.
Price and availability mismatch is the disapproval that catches the most merchants and does the most damage. It happens when Google crawls your landing page and the price or stock state doesn't match what your feed said. Left unfixed it escalates from item disapprovals to account-level trust problems. The fix is making your feed and your page agree, and keeping them agreeing.
What Google is actually comparing
A price or availability mismatch is not a feed-versus-feed check. Google crawls the product's landing page and compares what it renders there against what your feed submitted. When they disagree, the item is disapproved, and Google trusts the page, not the feed, because the page is what the shopper will see.
So there are always two numbers in play: the one in your price / availability attributes, and the one Google reads off the live page. A mismatch means those two have drifted apart. The fix is never "correct the feed" in isolation; it's making the feed and the page agree, and structuring the page so Google reads it unambiguously.
Why it's the most dangerous disapproval
Most item-level disapprovals stay item-level. Price and availability mismatch doesn't. Because it's a trust signal (Google inferring that your data can't be relied on), a sustained pattern of mismatches escalates from individual disapprovals to preemptive disapproval of clean items, and in the worst case to an account-level misrepresentation flag. A merchant who ignores 50 price mismatches for a month can find the whole catalogue suppressed. See misrepresentation and account suspension for where that road ends.
The four causes, and their fixes
| Cause | What's happening | Fix |
|---|---|---|
| Slow feed vs fast site | Feed fetches daily; site reprices or sells out hourly | Increase refresh cadence to match how fast the site changes |
| Tax / currency display | Feed price is ex-VAT or in a different currency than the page shows | Submit the price the crawler sees on the page, tax included where the page includes it |
| Sale price on-site only | Page shows a discount the feed doesn't carry | Submit sale_price so the feed mirrors the on-page discount |
| Unreadable page price | Price is in an image, loaded by script Google doesn't run, or behind a variant selector | Expose the price in crawlable structured data on page load |
The single most common of these is the first: a feed that refreshes far less often than the site changes. Everything else is a data-shape problem; that one is a cadence problem.
Availability specifically
Availability mismatch follows the same crawl-vs-page logic. The feed says in_stock; the crawl finds a sold-out page, or vice versa. Common triggers: the feed reflects warehouse stock while the page reflects a per-variant sellout, back-in-stock that the feed hasn't picked up yet, or pre-order states the page and feed describe differently. Keep availability sourced from the same system that renders the page, and refresh it as often as stock actually moves.
Deep dive Structured data, refresh cadence and preemptive disapproval
Three mechanics decide whether this disapproval ever appears, and they compound.
Structured data is how Google reads the page price cleanly. Google prefers to read price and availability from schema.org microdata (or JSON-LD Product / Offer) embedded in the page. If your page exposes correct structured data matching the feed, the crawl comparison is unambiguous and mismatches rarely fire. If the price only exists as rendered text (worse, as text injected by client-side script Google may not execute, or baked into an image), Google can misread it or fail to read it, and flag a mismatch against a feed that was actually correct. Fixing structured data fixes mismatches that look inexplicable from the feed side.
Refresh cadence sets the drift window. Between two feed fetches, the feed is frozen while the site moves. A once-daily feed against an hourly-repricing store has a 24-hour drift window in which every price change is a latent mismatch. Tightening cadence (scheduled fetches, content API pushes, or price-and-availability updates pushed the moment they change) shrinks the window toward zero. There is no structured-data trick that saves a feed that's simply too stale.
Preemptive disapproval is Google losing patience. Once Google has seen enough mismatches from an account, it stops waiting for a shopper to hit a wrong number; it preemptively disapproves items it predicts are stale, even ones currently correct, because it no longer trusts the feed's freshness. This is why a mismatch problem left to fester feels like it suddenly explodes: you cross a trust threshold and Google starts disapproving on suspicion. The way out is to rebuild the freshness signal: accurate data, refreshed fast, sustained long enough for trust to recover.
The durable setup treats price and availability as a monitored signal, not a fire-and-forget feed field. /tools tracks price and availability consistency continuously and flags products drifting toward a mismatch, or matching the patterns that trigger preemptive disapproval, before Google acts, so the fix lands while the item is still serving. See change monitoring and disapproval prediction.
Fixing a live mismatch
- Crawl the landing page yourself. Read the exact price and stock state Google would see, including tax, discounts and any currency toggle. This is the number that matters.
- Compare against the feed attribute. If they differ, decide which is wrong: often the feed is right in principle but the page renders differently, or the feed is genuinely stale.
- Make them agree at source. Correct the feed value, add
sale_priceif the page carries a discount, and check the page exposes the price in structured data. - Tighten cadence if drift is the cause. If the mismatch is a timing problem, no single fix holds; increase refresh frequency so the feed can't fall behind the site.
- Let it re-crawl. Data fixes clear automatically within 24–72 hours of the next fetch. Don't hand-edit items in Merchant Center; the next fetch overwrites manual edits.
Because enrichment is non-destructive (corrections live in a supplemental layer over your source data), you can align the feed to the page without touching what your store platform produces, and every other channel keeps the corrected values too.
Frequently asked questions
My feed price is right but Google says mismatch. What's it seeing?
Google trusts the landing-page crawl over your feed. It's reading the price rendered on the page: often the microdata or the on-page number after tax, discounts, or a currency toggle. If the page shows £49.99 and your feed says £45.00 (ex-VAT), that's a mismatch even though your feed is internally correct.
How often does my feed need to refresh?
Often enough that price and stock never drift from the site between fetches. For fast-moving catalogues that means multiple fetches a day or a real-time sync; a once-daily feed against a store that reprices hourly will generate mismatches continuously.
What is preemptive disapproval?
Google disapproving items for a predicted price/availability problem before any shopper saw a wrong number, triggered when your feed updates much less often than your site changes. It's Google saying it no longer trusts your feed's freshness.