Google says your WooCommerce variant is unavailable
Imagine Merchant Center flags product variant WAVE-NVY-M at 10:14 on Tuesday. Your staff open WooCommerce, see stock on the parent product, and understandably wonder what Google is on about. For a Dubai or UK shop paying for product visibility, that is not a useful disagreement. It can leave a listing disapproved or send a buyer towards an option they cannot actually purchase.
The important detail is WAVE-NVY-M, not the product family around it. A parent product with stock does not prove that the advertised navy, medium variant was available when Google checked the feed, page and checkout route.
Start with the item Merchant Center actually assessed
Read the flagged item ID, country, destination and timestamp before changing stock settings. Then find the feed record that produced WAVE-NVY-M and retain the landing page URL Google received. If the issue concerns a wider fault in how the store represents purchasable products, it may need a more methodical WooCommerce website repair review rather than a quick stock adjustment.
A WooCommerce Google Merchant availability mismatch is resolved by comparing one exact advertised variant across every representation at the relevant time: the submitted feed value, the landing-page selection, visible availability, structured data and checkout eligibility. Correct the system that owns the wrong value, allow its update route to complete, then verify the same variant again before requesting a Merchant Center review.
Google’s Merchant Center guidance on availability mismatches requires consistency between submitted product data, the landing page, structured data and checkout. It also specifically calls out variant mismatches. That is why a broad glance at stock totals is rarely enough.
Teardown WAVE-NVY-M across the five places it can disagree
Use the same identifier throughout the check. Do not compare a blue parent product in one place and a medium variation in another, then call it a result. That is how a tidy-looking admin screen becomes a rather expensive shrug.
| Representation | What to inspect for WAVE-NVY-M | Mismatch to look for |
|---|---|---|
| Merchant feed | Item ID, availability value, price, variant attributes and submitted URL | The feed says in_stock for medium navy while a different variation supplied the value |
| Landing page | The option selected when the page loads, or the exact URL parameters used | The page defaults to another size or colour with a different stock state |
| Visible product state | Whether medium navy can be selected and added to basket | The option appears available but becomes unavailable after selection |
| Structured data | The availability attached to the advertised offer or variant | Markup describes a generic parent offer rather than the purchasable variation |
| Checkout | Whether a clean guest session can proceed with that exact option | Basket accepts it, then blocks quantity, delivery or payment progression |
The common wrong-size landing page
Take a clothing product with navy sizes small, medium and large. The feed advertises WAVE-NVY-M as in stock. The product URL opens correctly, but the page defaults to WAVE-NVY-S because it is the first option in the variation list. Small happens to be unavailable. Google sees an advertised medium option leading to an unavailable small option. Staff see medium stock in WooCommerce. Both observations can be true, but the buyer journey is still wrong.
Can the correct product still link to the wrong size or colour? Yes. A product-level URL can be valid while the page’s default variation, preselected attributes, URL parameters or variation script point the visitor towards another option. The product is right; the purchasable offer is not.
Separate an unavailable variation from a feed consistency fault
There is an adjacent problem where a WooCommerce variation cannot be purchased despite stock appearing to exist. That needs its own diagnosis of variation state, purchasing rules and the selected option. Use this guide on a WooCommerce variation unavailable despite stock when the variant itself will not behave properly in the store.
This teardown is narrower. Assume WAVE-NVY-M can be bought in WooCommerce, then ask whether Google is being shown that same fact everywhere. Do not rebuild variation configuration merely because Merchant Center has raised an availability issue.
Correct the owner of the bad value
Once the mismatch is visible, identify which system publishes it. It may be the feed plugin, an inventory integration, a custom product-data field, structured-data extension, cached product HTML or a feed rule in Merchant Center. Changing stock by hand may mask the symptom for an hour and leave the actual export path untouched.
A boring but real detail: some stores run a scheduled inventory import, then generate the feed on a separate schedule. If the feed job runs first, WAVE-NVY-M can be exported with yesterday’s state. A cache can then continue serving an older product page after the stock import has completed. Record the order and time of those jobs before deciding the stock figure is the culprit.
- Confirm the WooCommerce variation ID and stock status for WAVE-NVY-M.
- Check the source feed’s latest processed value, not an old downloaded file on someone’s desktop.
- Open the submitted landing URL in a clean browser session and select the advertised attributes.
- Inspect the product’s visible offer and structured data for the same availability state.
- Add only WAVE-NVY-M to basket and continue far enough to prove it remains eligible to buy.
- Correct the publishing source, then wait for the intended feed and cache update path to finish.
Verify the buying route before asking for review
Run the final check as a customer would, ideally in a logged-out browser with no remembered variation choices. Product tests are easy to muddle when an administrator’s session, stock-management plugin and cached public page are all showing slightly different states.
A focused WooCommerce test-order checklist is useful at this stage because it keeps the last mile honest. The test does not need to create a completed live payment. It needs to prove that the exact advertised variant remains selectable, reaches basket and is not rejected by the store’s purchasing rules.
Only request review after the feed, landing page, structured data and checkout all describe WAVE-NVY-M consistently. Merchant Center reviews cannot reconcile a disagreement that still exists in the shop.
If a flagged item is tying up product visibility, ask for a product-feed consistency review using a flagged item and its exact landing page. It is usually quicker to follow one purchasable variant end to end than to make broad stock changes and hope Google becomes less fussy.