When the feed says In stock but the page says sold out (or the reverse)

What the error means

Google verifies each listing by fetching the landing page and comparing the availability it finds against the feed value. When the two disagree — feed says available and the page is sold out, or the feed says unavailable and the page still sells — the item is disapproved or silently excluded.

Why Google rejects it

The feed is a promise and the page is the proof; a disagreement between them means one of them is lying to the shopper. The page-says-sold-out direction disapproves for misleading availability. The reverse is quieter: the item just stops appearing, while everything in your admin looks healthy.

How to fix it

1. Decide the source of truth for availability per channel and make the feed read from it live — not from a cached export.
2. Tighten the sync schedule. Daily is the minimum for stores with meaningful stock movement; faster shrinks the mismatch window.
3. Check the "continue selling when out of stock" flag against reality: if you do not backorder, the page must not take orders at zero stock.
4. Watch for the chronic version — a product unavailable for weeks is still "live" in the admin, so nobody rechecks it. A daily re-scan records the day each product’s availability changed.

Common causes

Variant selected on page differs from feed item

A feed item may represent a specific size, color, or variant while the landing page opens with a different option selected. Google then sees a sold-out selection even though another size is available. Send a variant-specific URL when supported and make the submitted variant the page's default selection.

Stock changes before the next feed update

The product page can update inventory immediately while a scheduled feed still contains yesterday's value. This is common when stock moves quickly or multiple systems update at different times. Compare the source inventory timestamp, page response, and most recent product data fetch for the same item.

Backorders are treated as ordinary stock

An existing product can accept orders while inventory is zero, but its feed or page may report in_stock instead of backorder. Google distinguishes backorder from preorder and requires an availability date for these cases; the expected shipping date should be visible on the landing page.

Availability changes by location

IP-based pages may show in stock in one region and unavailable in another, while the product data targets a wider country. Google expects customers in the targeted area to see consistent availability. Check geolocation rules, shipping eligibility, and the location used by the crawler.

Legacy schema or app output contradicts the visible state

A page can show Sold out while stale JSON-LD still says InStock, or the reverse. Theme markup, inventory apps, and caches may each use a separate stock source. Inspect the visible buy button, structured data, checkout behavior, and submitted availability together.

Fix it on your platform

On Shopify

1. Open the affected product and compare the exact variant in the Google feed with its inventory at the location used for fulfillment. Do not rely on the parent product's stock total when one size or color is sold out.
2. For variants intended to be purchasable at zero inventory, review the variant's continue-selling setting and how the feed app maps that state. If orders are not accepted, disable the setting and show unavailable consistently.
3. For genuine preorders of unreleased products, ensure the feed uses preorder and an availability date, and that the date is visible on the product page. For existing products accepted on backorder, use backorder and its expected availability date instead.
4. Check theme and inventory app output for availability JSON-LD, and purge storefront or CDN caches after bulk stock changes. Compare the selected variant's button and structured data.

On WooCommerce

1. In the product Inventory tab, compare stock status, quantity, and Allow backorders for the exact variation. Confirm the storefront disables the purchase control when the item cannot be ordered.
2. Inspect the feed plugin's availability mapping for out-of-stock and on-backorder states. Use the matching Merchant Center values and an availability date for preorder or backorder cases.
3. Check the SEO plugin's Product Offer markup against WooCommerce stock status. If an inventory extension overrides one source, configure the feed and schema to read from that same source of truth.
4. Purge page, object, and CDN caches after inventory updates. Test the public variation URL and checkout from a location included in your target country.

On other platforms

1. Compare stock state in the catalog, feed integration, product page, and checkout for the same variant and delivery destination.
2. Map preorder, backorder, in-stock, and out-of-stock states to the corresponding supported Merchant Center availability values. Show the expected date for preorder or backorder on the landing page.
3. Remove IP-based availability changes or configure regional availability and pricing where available. A shopper and crawler in the target area should see a state consistent with the submitted product data.
4. On custom sites, keep feed generation and Product Offer markup connected to one inventory source, then invalidate caches whenever that state changes.

How to confirm it is fixed

1. Use a sample of affected items and record item ID, selected variant, feed availability, visible page state, JSON-LD availability, and checkout result.
2. For preorder or backorder, verify the availability date in product data and the expected date on the landing page. Confirm the date and terms are not hidden behind a login or location prompt.
3. Update and resubmit the product data, then use Merchant Center Diagnostics to see whether the issue remains. Google notes that diagnostics may take time to reflect changes.
4. Run the availability check to compare public catalogue data and product-page availability markup on other products.
5. If products are disapproved, request a review after the technical fix is live. Recheck the same variant after Google fetches the page and feed again.

A worked example

Hypothetical case: a shoe store's feed item for size 9 says in_stock, but Google lands on a product page preselected to size 11, which has sold out. Other sizes remain available, so the parent product looks healthy in the admin. The owner updates the feed link to include the size 9 variant and changes the product template to initialize that variant when the URL is opened. They also check that size 11 displays as unavailable in both the page and feed. After resubmitting the data and requesting a review, the item is checked again on the exact variant URL.

Other errors like this