Google Shopping says in stock but your site says out of stock: How to find the layer serving stale availability

Google Shopping shows a product as in stock while your site says out of stock because availability reaches Google through layers that update on different schedules: your inventory source, page and CDN caches, the feed, and Merchant Center. Check the live page, the cache headers, the feed value, and the value Merchant Center holds, then update the page and product data together, using the Merchant API for fast-selling items.

When a shopper clicks a Google Shopping listing for an in-stock product and lands on a page that says it is sold out, the visit is over before it starts. Nothing breaks in the usual sense: the feed is approved, the campaign runs, and the page loads. The mismatch exists because inventory, page caches, CDN caches, the product feed, and Merchant Center all update on their own schedules, which opens a window in which stale availability keeps driving paid clicks that cannot convert.

This guide explains where that window comes from, what Google expects availability to look like, and how to work out which layer is serving the outdated value. It then covers the fix for each layer, a timing test to confirm it worked, and the habits that keep it from coming back, which matters most on days when products sell out in minutes, such as flash sales and the Black Friday and Cyber Monday weekend.

Why does Google Shopping show a product as in stock when your site says out of stock?

Availability travels through up to six layers between a sale and a Google Shopping listing. A product can sell out at the first layer while the others keep showing the old value, and the delay at each layer adds to the next:

Layer	What can make it stale	How to check it
1. Inventory source	Stock counts that sync into your store from an ERP, POS, warehouse, or marketplace in batches, so the store itself is behind the real stock	Compare the stock figure in your admin with the warehouse or POS figure
2. Storefront page cache	A cached product page that still shows the add-to-cart state for a product that has sold out	Open the page in a private window and compare it with the admin
3. CDN edge cache	An edge copy of the page kept for longer than your products stay in stock	Read the age, cache-control, and CDN headers on the page
4. Feed file or API output	A feed generated on a schedule, or served from a cached endpoint	Open the feed URL and search for the product’s <g:availability> value
5. Google’s fetch or API processing	A scheduled fetch that runs less often than your stock changes, or an API change still being processed	Check the data source’s last fetch time and status in Merchant Center
6. Merchant Center’s stored value	The value Merchant Center last processed, which may differ from your feed and your page	Open the product in Merchant Center and compare what it holds with the feed and the page

Two of these layers are easy to underestimate. Scheduled fetches in the Merchant API can run daily, weekly, or monthly, and Google says that if you need to fetch more than once a day you should update products through the Products service instead. So a plugin that regenerates your feed every hour does not help if Google only collects it once a day. And when you do push changes through the API, Google notes that a successful response only means the change was accepted, that processing continues afterwards, and that it can take a few minutes, or longer, before the processed product reflects it.

As an illustration, a product that sells out at 10am can still be listed as available at 4pm, or until the next day, depending on which of these layers you rely on. To size the cost for your own store, take the clicks that out-of-stock products received during the period and multiply them by your average cost per click.

What does Google expect availability to look like?

Google’s help page on inaccurate availability status states the problem plainly: when someone clicks a Shopping ad or free listing they expect to see the same availability on your landing page, and you may be paying for wasted clicks if they return to Google after finding the product unavailable. It also says availability must match across the landing page, the checkout page, your structured data, and your product data source, and that a mismatch in any one of them can trigger a disapproval. The situations that most often cause mismatches look like this:

Situation	What to submit and show	Common mistake
Sold out	Submit out_of_stock and make the page clearly say sold out, or disable the buy button	Page or markup still says in stock
Preorder	Submit preorder with availability_date, and show the date on the page	Marked in stock before release
Backorder	Submit backorder only if the product can still be bought and dispatched in a reasonable time, and show the expected shipping date	Using backorder for products you cannot actually sell
Planned maintenance	Do not set out_of_stock to hide products. Use the excluded_destination attribute instead	Hiding the catalogue through availability
One variant sold out	Do not let the landing page pre-populate the sold-out variant, and ideally pre-populate the exact variant in the feed	One URL that always opens the default size
Regional availability	Use regional pricing and availability instead of changing the page by visitor location	Changing availability by IP address

Google also lists a few page behaviours that cause mismatches: requiring a zip code before availability is shown, a buy button that is greyed out or missing for a product that is available, and outdated microdata or HTML that contradicts the visible page. Each is worth checking when everything else looks correct.

Which stores are most exposed to stale availability?

Every store that advertises on Google Shopping has this gap, but it costs most where stock moves quickly or through many systems. The risk is highest if your store:

• Sells limited or fast-moving stock, where a product can sell out within minutes of a campaign
• Runs flash sales, seasonal campaigns, or the Black Friday and Cyber Monday weekend on 27 and 30 November, when sell-outs outpace schedules measured in hours
• Syncs inventory from an ERP, POS, warehouse, or marketplace, so the store’s own stock figure can already be behind
• Serves product pages or the feed through a page cache or CDN
• Sells products with variants, where one size or colour sells out while the product stays available

A small catalogue with slow-moving stock and a native integration that pushes changes to Google is less exposed, though one timing test is still worth running.

Signs stale availability is reaching your shoppers

• Shopping listings show in stock for products that are sold out on your website, visible when you compare a listing with the live page
• Merchant Center flags availability mismatches, for example “Mismatched value (page crawl) [availability]”, where what Google sees on the landing page differs from the feed
• Customers complain about clicking ads for unavailable products, and the complaints arrive as support tickets because no conversion funnel fires
• Bounce rates on specific product pages rise after stock-outs, because traffic arrives expecting an in-stock product and leaves straight away
• Automatic item update notices appear for availability, showing that Google corrected a value your own data should have had right

How to find which layer is serving stale availability

Work backwards from the customer experience, and change one thing at a time so you know which layer was responsible.

Step 1: Check the live product page

Open the product URL in a private window, which avoids cookies that may route you to a cached copy. Does it say in stock or out of stock, and does the add-to-cart button match? For a product with variants, open the exact variant URL from your feed. If the page is correct, the problem is further upstream.

Step 2: Check the cache headers on the page

In your browser’s developer tools, open the Network tab, select the page document, and read the response headers: age, cache-control, and CDN-specific headers such as cf-cache-status or x-cache. Header names vary by CDN. An age value larger than the time your products take to sell out shows that a cached copy is being served.

Step 3: Check the feed itself

Open your product feed URL directly and search for the product’s <g:availability> value. If the feed still says in stock for a sold-out product, the feed is the bottleneck. Check the feed URL’s own response headers too: if a page cache or CDN is serving the feed, it can hand Google an old file even though the database is correct.

Step 4: Check the source of truth

Compare the stock figure in your store admin with your warehouse, POS, or ERP. If the admin figure is already behind, no amount of caching or feed work will fix the listing, and the problem is the inventory sync.

Step 5: Check Merchant Center and your data sources

In Merchant Center, open Products, go to the Needs attention tab, and filter for availability mismatches, then open an affected product to compare what you submitted with what Google collected. Also look at your data sources. Google’s data model lets a supplemental data source take priority over a primary one for an attribute, so a second source, such as an app feed alongside a plugin feed, can supply a different availability for the same product. Confirm which sources supply each product and in what order.

Step 6: Check automatic item updates

Automatic item updates are turned on by default. You can see their status in the Automatic item updates section under Tools and settings, and review recently updated products in the downloadable report on the Diagnostics page. If a product appears there, Google had to correct availability that your own data should have carried.

A quick way to read the results

What you see	Likely layer	Next check
The live page says in stock when the product is sold out	Inventory source or page cache	Compare the admin and warehouse figures, then the cache headers
A private window is correct, but other visitors still see the old state	CDN or page cache	Read the cache headers and purge rules
The page is correct but the feed is wrong	Feed generation or feed cache	Feed schedule and the feed URL’s cache headers
The feed is correct but Merchant Center is wrong	Fetch schedule or processing	Last fetch time, data source status, and any second data source
Everything looks correct but a page crawl mismatch persists	Structured data, variant, or page behaviour	Structured data value, pre-populated variant, zip code prompts

How to fix each layer

Feed updates: Use the API for fast-selling products

Since scheduled fetches run at most daily, regenerating the feed more often will not by itself speed up Google. For products that sell out faster than that, push availability changes through the Merchant API (the successor to the Content API for Shopping) and keep scheduled fetches for the rest of the catalogue. If your platform has a native integration that already pushes changes, confirm how often it does so. Expect processing time after each push, as described earlier, and update the landing page and the product data together, because Google asks that they match.

Feed endpoint caching

Exclude the feed URL from page cache and CDN rules, or give it a very short lifetime. This is one of the quietest causes of stale feeds, because everything inside the database is correct and the file Google collects is not.

Page cache and CDN configuration

Product pages that are cached for hours cannot reflect a sell-out in minutes. Options, from most to least precise:

• Purge or refresh the cached page when stock status changes, using your platform’s cache invalidation hooks or a plugin
• Keep the availability and add-to-cart elements out of the cached page and load them fresh, where your platform allows it
• Use a short cache lifetime on product pages as a backstop. A range of 5 to 15 minutes is a practical starting point, and it is our suggestion, not a Google requirement

Be careful with stale-while-revalidate. It lets a cache serve an old copy while it fetches a new one, which keeps pages fast but means a shopper can still see the previous availability during that window. Keep the window short, or avoid it for availability-critical pages.

Structured data alignment

Your page’s Offer availability markup must reflect current stock, not a cached product object or a hard-coded value. Some older themes print in-stock markup for every product regardless of inventory, so check yours. Google asks you to update the landing page, the product data, and any microdata at the same time, and treats outdated microdata or HTML as a cause of mismatch.

Variants, preorders, and backorders

Use the values in the table above, and make sure the page shows what the data says: the exact variant pre-populated, the availability date for preorders, and the expected shipping date for backorders. A product that is available in some sizes should not open on a sold-out size.

Data sources

If you hold back a safety buffer

Some stores treat a product as out of stock when only a few units remain, to avoid overselling while systems catch up. If you do, apply the same rule to the page, the structured data, and the product data, because Google expects all of them to agree.

Automatic item updates: Keep them as a backup

Leave automatic item updates on, but do not rely on them. Google describes them as designed to fix temporary problems for a small percentage of your products, says they are not a replacement for regular product data updates, and says they will not be very effective if the availability of most of your products changes several times a day. It also warns that if too many mismatches occur, automatic item updates stop working and your account is at risk of preemptive item disapproval.

After the fix: Ask Google to re-check

Once your technical fixes are live, Google says that making a small ad edit or selecting Appeal starts a fresh crawl, which usually finishes within 24 to 48 hours. The Diagnostics page can take some time to reflect the change.

How to verify the fix

A timing test shows which layers are still slow. Use a product you can safely change, or a test product, and record the time at each stage:

1. Set the product to out of stock in your admin and note the time.
2. Check when the live page (in a private window) shows out of stock.
3. Check when the feed file shows out of stock.
4. Check when Merchant Center shows the new value.

Repeat the test for a product variant. The gap between the first and the last time is your real mismatch window, and the longest single step is where to work next. Then confirm the result over the following days:

• Check the Diagnostics page for availability mismatches, allowing for the delay in the page updating
• Compare bounce rates on product pages that sold out before and after the change
• Compare clicks on out-of-stock products, multiplied by average cost per click, before and after

Common mistakes when fixing availability mismatches

• Speeding up feed generation without checking Google’s fetch schedule. If Google collects the file once a day, an hourly rebuild changes nothing.
• Hiding products by marking them out of stock. For maintenance or excluded products, Google asks for the excluded destination attribute instead.
• Using backorder for products you cannot sell. Backorder is for products that can still be bought and dispatched in a reasonable time.
• Treating automatic item updates as the main fix. They cover a small share of products and stop working when mismatches are widespread.
• Fixing the feed and leaving the markup hard-coded. Google reads the landing page and its structured data, not only the feed.
• Testing in a normal browser window. A cached copy can hide the problem you are trying to see. Use a private window and read the headers.
• Forgetting variants. A product-level check can pass while one size is sold out and still pre-selected.

What to do before Black Friday

1. Run the timing test on your three fastest-selling products and one product with variants, and write down the longest step.
2. Move your fastest-selling products to API updates, and make sure the feed URL is excluded from page cache and CDN rules.
3. Check that your structured data and your add-to-cart state reflect live stock, then set up a regular comparison of the feed, the page, and Merchant Center for the weekend itself.

Watching the signals around availability with AuditIQ

Stale availability leaves traces before a customer writes in: paid clicks that do not convert, product pages that start to bounce, or markup that has broken. AuditIQ helps you see all three:

• Spend signal: Google Ads tracks spend, CPC, conversions, CPA, and ROAS across your campaigns and alerts you when performance deviates from normal patterns, next to your site health data, so a stretch of clicks that stop converting after a stock-out stands out.
• Behaviour signal: Analytics shows unsampled Google Analytics data, including bounce rate and conversion funnel analysis, in the same platform as your technical monitoring, so a rise in bounces on product pages can be read alongside stock changes.
• Markup signal: SEO Audit runs a weekly crawl of up to 20,000 pages with 100+ checks per page, including structured data, so product pages whose markup is missing or broken are flagged with the exact pages affected.

AuditIQ does not read your product feed or Merchant Center, and it does not compare availability across your feed, your caches, and your inventory. Keep the timing test and the feed check in your routine, and use monitoring to tell you when it is time to run them.

Beyond Google Shopping, AuditIQ is a 360° eCommerce monitoring platform purpose-built for Magento, Adobe Commerce, and Shopify stores. It continuously monitors every critical layer of a store — performance, infrastructure, SEO, security, user experience, configuration, and code quality — from a single, unified dashboard, so the quiet failures that waste ad spend are caught before they compound.

Start monitoring your store for free today to catch the signals of stale availability before they cost you clicks.

Others also read

• Google Merchant Center goes down: Your revenue doesn't come back automatically
• Google Shopping ad shows wrong variant on landing page? How to fix the mismatch costing you clicks and revenue
• Ways to sync Magento and POS inventory: Technical risks and solutions

Frequently asked questions

1. Will Google’s automatic item updates fix the problem?

Only partly. Google describes them as a fix for temporary problems on a small percentage of products, not a replacement for regular updates, and says they are less effective when availability changes several times a day. Use them as a backup layer.

2. How often does Google fetch my product feed?

A scheduled fetch in the Merchant API runs daily, weekly, or monthly. You can trigger a fetch outside the schedule, but Google says that if you need to do so more than once a day you should use the Products service to update your product data instead.

3. Should I use out of stock or backorder?

Use out_of_stock if you are not accepting orders for the product. Use backorder only if it can still be purchased and dispatched within a reasonable time, and show the expected shipping date on the page.

4. Can I mark products out of stock to hide them during maintenance?

No. Google asks you not to set availability to out of stock to exclude products and to use the excluded_destination attribute instead.

5. Does this only affect Google Shopping?

The guidance above comes from Google, but the same idea applies wherever a channel reads your feed or crawls your product pages: each has its own schedule, so the mismatch window can differ by channel. Check each channel’s documentation for how often it collects data.

6. How can I tell if my CDN caches product pages for too long?

Check the response headers for a product page in your browser’s developer tools, such as cache-control, age, and CDN-specific headers. Compare the age value with how long your products take to sell out. If the page has been cached for longer, it can show stale availability to shoppers and crawlers.

7. How long until Google reflects my fix?

After a push through the Merchant API, processing can take a few minutes or longer. After a review request or appeal, Google says its fresh crawl usually finishes within 24 to 48 hours, and the Diagnostics page can take longer to update.