Short answer. Merchant Center reports “Mismatched value (page crawl) [availability]” when Google crawls the product page and reads a different availability from the one in your feed: sold out on the page, in_stock in the feed, or the reverse. Update the feed as soon as stock changes and make the page’s structured data say the same thing; Google re-crawls within about 24 to 48 hours.
| Shown in Merchant Center as | Mismatched value (page crawl) [availability] |
|---|---|
| Attribute | availability |
| Effect | Product disapproved — Repeated mismatches become an account-level warning |
| Where to find it | Products → Needs attention, then filter by this issue |
| Free check | Not something a feed file shows; see below for what the check can tell you instead |
What Merchant Center means by “Mismatched value (page crawl) [availability]”
Google does not take your feed’s word for availability. It crawls the product page in the link attribute, reads the stock status there (from structured data when present, from the visible page otherwise) and compares. When the two disagree, the product is disapproved with “Mismatched value (page crawl) [availability]”, listed as availability_mismatch in the Content API’s product issues reference. The availability specification states the rule plainly: match the availability in your product data with the availability on your landing page and checkout pages.
When enough products mismatch, the issue moves up a level. Google’s help page for the account-level version, “Inaccurate availability status due to inconsistency between feed and landing page”, lists the causes and says the re-crawl after a fix usually finishes within 24 to 48 hours. That version needs a review request, and unresolved it can suspend the account.
Why it happens
- Stale feeds. The most common by far: the feed was generated when the product was in stock and has not been regenerated since it sold out. A feed uploaded once is a snapshot.
- Structured data that disagrees with the page. The theme’s schema.org markup says
InStockfor every variant regardless of inventory, while the page shows “sold out”. Google trusts the markup. - Variant mismatch. The feed row is a size that is sold out, but the link opens the product with the default (in-stock) variant selected.
- Preorder or backorder sold as in stock, or a long lead time not declared.
- Location-dependent pages. Availability that changes by visitor IP or requires a postcode before it shows, so Google’s crawler sees something your customers do not.
- Broken buy buttons or maintenance pages during the crawl.
How to fix it
In Shopify
Shopify’s own Google & YouTube channel syncs inventory changes continuously, so mismatches on Shopify usually come from a third-party feed on a schedule, or from a theme whose product JSON-LD hard-codes availability. Move to a feed that updates on inventory change, and in the theme make sure the variant’s availability in the structured data follows variant.available. Link each feed row to its variant URL (?variant=) so the crawler lands on the right one.
In WooCommerce
A feed regenerated nightly can be a day behind sales. Our free connector builds the feed at request time from the live stock status, so whatever Merchant Center fetches is what the store says at that moment; schedule Merchant Center’s fetch as often as your plan allows. Check the product page’s structured data (Rank Math, Yoast and WooCommerce’s own markup all emit an Offer) and confirm it reflects stock per variation.
In a CSV or XML feed
Regenerate the file whenever stock changes, or at least daily, and schedule the fetch in Merchant Center immediately after. For sold-out variants make sure link opens that variant. If your pages depend on visitor location, serve Google’s crawler the default market’s availability. Once the values agree across products, request a review if the account-level warning has appeared.
How long until Merchant Center clears it
Google re-crawls the pages after the feed changes; the item-level disapproval lifts when a crawl finds the values agreeing, typically within 24–48 hours of the fix reaching both feed and page. The account-level warning clears only after a review request, which you submit once the item-level mismatches are gone.
What FeedRobin does about it
The free check does the price half of this comparison today: it opens a sample of your product pages and reports where the page’s price differs from the feed’s, with the pairs shown. It does not yet compare availability against the page, and the report does not claim to. What the check does report is every availability value that no channel recognises, which is the file-side half of the problem. For connected stores, availability comes from the platform’s live inventory on every sync and webhook, so the feed Google fetches stops being a snapshot.
Questions merchants ask
The product was in stock when I uploaded. Why is it mismatched now?
Because the feed was uploaded once and the stock changed since. Google compares the page to the feed as it is today. A feed that is regenerated only when someone remembers will always drift; schedule it, or use a source that updates on every stock change.
Where on the page does Google read the availability?
From the structured data (schema.org Offer availability) when present, and from the visible page otherwise. If your theme’s structured data says InStock while the button says sold out, fix the theme; Google trusts the markup first.
How is this different from the account-level availability warning?
The item-level issue disapproves the product until the values agree. If too many products mismatch, Google raises “Inaccurate availability status due to inconsistency between feed and landing page” on the account, which needs a review request after the fix.
Sources
- How to fix: Inaccurate availability status due to inconsistency between feed and landing page — Google Merchant Center Help
- Availability [availability] — Google Merchant Center Help
- Product issues (Content API for Shopping): the issue codes and the titles Merchant Center shows — Google Merchant Center Help