Merchant Center Availability Mismatch: “In Stock” Where, and for Which Variant?

Availability is an exact-offer claim. Trace one variant through the submitted source, processed Merchant Center product, landing-page selection, structured data, cart, checkout, and delivery scope.

By
Hookin Team, Performance Editorial
Published
September 10, 2026
Reading time
18 min read
Views
33 views
On this page
  1. The word “product” is too broad
  2. Choose the status from what the customer can actually do
  3. Six checkpoints, one offer
  4. Filled test: one product family, six availability outcomes
  5. Diagnose the mismatch by its shape
  6. Fix the model, then fix the feed
  7. A verification run you can hand to an operator
  8. After the repair
  9. Sources

A Shopping listing sends a buyer to the Northline Trail Shoe. The submitted offer is Black / size 10, but the landing-page URL silently falls back to Blue / size 9. The page says “In stock,” so a quick visual check appears to pass. When the buyer switches back to Black / size 10, the buy button becomes disabled. The product family has stock; the advertised variant does not.

That is the central mistake behind many Merchant Center availability mismatches: “in stock” is not a family-level badge. It is a claim about one exact sellable offer, in a defined delivery scope, at a particular time. To repair the mismatch, follow the same offer ID through the commerce inventory record, the submitted Merchant Center input, Google’s processed product, the landing page’s initial variant, its structured data, and cart or checkout. A match on only one of those surfaces is not enough.

Google’s current availability specification requires submitted availability to match the website and explicitly says a variant’s source value should match that same variant on its landing page. Its landing-page guidance also recommends preselecting the variant represented by the product data. Those two rules turn a vague stock investigation into a precise question: Which offer did Google receive, which variant did the URL reproduce, and where can that exact offer actually be bought?

The word “product” is too broad

An ecommerce team may use “product” to mean at least three different things:

  • the family, such as Northline Trail Shoe;
  • a variant, such as Black / size 10;
  • an offer, such as Black / size 10 sold online in the United States under offer ID NL-TRAIL-BLK-10.

Merchant Center availability belongs at the offer level. Google’s item group ID specification says each variant should be submitted as a separate product with its own unique ID, while variants in the same family share an item_group_id. Current guidance also recommends item_group_title and the newer variant_option attribute, alongside standard fields such as color and size, to identify the dimensions that distinguish one option from another.

A common implementation collapses those levels into one parent boolean:

parent_in_stock = any variant is purchasable

That can support a category-page message such as “Available in some options.” It cannot safely populate every child offer with in_stock. If Blue / size 9 is available and Black / size 10 is not, both statements can be true at the family level while only one is true for the offer represented in a feed row.

Delivery scope is part of the claim too. Under Google’s definition, an in_stock product must be orderable and deliverable to the locations supported by the offer’s product data and shipping setup. A product that is physically sitting in one warehouse is not necessarily “in stock” for every destination you target. Regional differences should be modeled through the appropriate supported configuration—such as regional shipping settings or regional availability and pricing, where the account, country, regions, and surfaces are eligible. Do not replace that modeling with a landing page that quietly changes availability by IP.

A useful working model is:

Availability truth = exact offer identity × commercial state × delivery scope × time.

If any factor changes, the availability record may need to change.

Choose the status from what the customer can actually do

Google currently supports four general online availability values: in_stock, out_of_stock, preorder, and backorder. The distinction is operational, not cosmetic. The value should describe whether an order can be placed now, whether the product has been released, and when it is expected to ship.

Value Use it when Evidence the page and checkout should provide A common wrong substitution
in_stock You accept the order, can fulfill it in a timely manner, and can deliver it throughout the locations supported by the offer’s data and shipping setup. The exact variant is selected, the buy control works, it can be added to cart, and checkout can be completed for the tested destination. Marking every child in_stock because at least one sibling variant is available.
out_of_stock You are not accepting orders for that offer, or it is not purchasable. Clear unavailable text or a disabled option and buy control; checkout should not pretend the offer can be purchased. Using out_of_stock merely to stop an otherwise available item from appearing in a destination.
preorder You accept orders for a new product that has not yet been released. A working order path plus a visible expected shipping date that agrees with availability_date. Calling an unreleased item in_stock because the preorder button is active.
backorder An existing product is unavailable now, but you accept orders and expect to ship it when stock returns. A working order path, a visible expected shipping date, and messaging that makes clear the item is returning rather than unreleased. Calling a returning existing item preorder, or calling a non-orderable item backorder.

The definitions and page requirements come from Google’s availability attribute documentation. For preorder and backorder, Google’s availability_date specification requires a date up to one year in the future, formatted as ISO 8601 in the data source. The page may show an exact or estimated date, but it should be clear to customers; Google recommends including a time and timezone in the submitted value and does not accept date ranges in that attribute.

Availability is also the wrong switch for campaign visibility. If an offer is still buyable but should temporarily stop appearing in a particular Google destination, use the relevant pause or excluded-destination control rather than falsifying stock. That preserves the difference between “we cannot sell this offer” and “we do not want to promote it here.”

One subtlety matters when diagnosing apparently harmless records. Google says Merchant Center automations use relaxed availability matching: a submitted in_stock value may remain unchanged when the crawler detects preorder or backorder. Automations are a safety net for temporary discrepancies, not proof that your status semantics are exact. The absence of an automatic correction does not validate a parent-level in_stock rule, and automations do not replace frequent accurate source updates.

Six checkpoints, one offer

Teams often compare “the feed” with “the website” and stop. That hides several independent states. For one affected offer, capture all six checkpoints below.

Checkpoint What to record Why it can differ
1. Commerce inventory record SKU or variant ID, orderability, quantity or business state, release/restock date, fulfillment scope The source system may aggregate children, lag a warehouse, or use internal statuses that map badly to Google values.
2. Submitted Merchant Center input Offer ID, feed label or target context, availability, availability date, link, variant attributes, source name A scheduled feed, app, rule, or API job may submit stale or transformed data.
3. Google’s processed product Final processed attributes, destination status, issues, and the data sources that contributed Google can apply rules and combine primary and supplemental inputs. A successful submission is not the same as approval.
4. Landing page on initial load URL, selected color/size, visible availability, date, price, and buy-button state before interaction Query parameters may be ignored, redirects may strip them, or JavaScript may default to another variant.
5. Structured data in the initial response SKU or variant identity, Offer.availability, price, and availabilityStarts where relevant A theme, app, cache, or template can publish a parent or stale child record even when visible text is right.
6. Cart and checkout Exact selected variant, cart line identity, orderability, shipping eligibility, and promised date for one explicit destination Inventory may be rechecked late, a shipping restriction may appear only after an address, or the cart may substitute a sibling.

The split between checkpoints 2 and 3 is especially important for custom integrations. Current Merchant API product documentation separates ProductInput, which contains submitted data, from the read-only processed Product, which reflects Google’s processing, combined sources, product status, and issues. The add-and-manage guide also warns that a successful input insertion does not mean the product is approved. A clean export file therefore proves only what you intended to submit; it does not prove what Google finally processed.

Filled test: one product family, six availability outcomes

The following is an original fictional teaching fixture, not a live merchant, Google account, policy review, or campaign result. It uses one online-only US product family, a $129.00 example price, and one explicit checkout test scope: home delivery to postal code 94107. The point is to make every comparison reproducible without implying that the same shipping or regional setup applies to another merchant or country.

Offer tested Submitted source state Landing page on first load Cart or checkout at the stated scope Result
Blue / 9 — NL-TRAIL-BLU-09 in_stock Blue / 9 is selected; “In stock”; active Add to cart Correct SKU stays in cart and can proceed for 94107 Pass
Blue / 10 — NL-TRAIL-BLU-10 preorder; 2026-10-15T09:00-0700 Blue / 10 is selected; “Preorder — expected to ship October 15, 2026” Correct SKU can be ordered; the same date remains visible Pass
Blue / 11 — NL-TRAIL-BLU-11 out_of_stock Blue / 11 is selected; “Out of stock”; buy control disabled No purchasable line is created Pass
Black / 9 — NL-TRAIL-BLK-09 backorder; 2026-09-24T09:00-0700 Black / 9 is selected; “Backordered — expected to ship September 24, 2026” Correct SKU can be ordered; the same date remains visible Pass
Black / 10 — NL-TRAIL-BLK-10 in_stock The link ignores Black / 10 and loads Blue / 9 as “In stock” Selecting Black / 10 reveals it is unavailable and blocks purchase Fail: wrong variant
Green / 9 — NL-TRAIL-GRN-09 in_stock for the modeled US offer Green / 9 is selected and can be added to cart Checkout says the exact offer cannot be delivered to 94107 Fail: wrong delivery scope

Open the interactive variant availability test to switch among all six cases, or download the filled source/page/checkout comparison matrix. The package also includes machine-readable local demo test results; those results verify the behavior of the original demo, not Merchant Center approval.

Original variant availability demo showing a failed Black size 10 offer because the landing page loads Blue size 9 instead
The deliberately broken case looks “in stock” until the requested offer identity is compared with the variant selected by the landing page.

What the two failures expose

The Black / 10 row is not repaired by changing the words next to the buy button. Its URL must reproduce Black / 10 on first load, and its visible content, structured data, cart line, and source row must all refer to that same offer. A page saying “In stock” for Blue / 9 is irrelevant evidence for Black / 10, even when both variants share a family page and price.

The Green / 9 row is a different problem. Its identity is correct, but “in stock” overstates where it can be fulfilled. The fix may be shipping configuration, a target-scope correction, or supported regional inventory modeling—not a cosmetic page edit. Google’s checkout requirements say an in-stock listing should remain in stock through landing page and checkout and should be purchasable. Test the destination your offer actually targets; do not infer nationwide or cross-country availability from one successful address.

Diagnose the mismatch by its shape

Start with the observed contradiction instead of editing every feed rule at once.

What you observe Likely fault line Decisive check
The family page says “In stock,” but a size becomes unavailable only after selection Parent-level “any child available” logic is being reused for child offers Compare the affected offer ID with the selected option and buy state, not with the family badge.
The link contains color and size parameters, but another option loads Variant parameters are ignored, stripped by a redirect, or overwritten during hydration Open the final URL in a clean session and record the selected controls before clicking anything.
Visible text and buttons are correct, but the issue persists Structured data or initial HTML may identify another variant or stale status Inspect the initial response and the exact offer’s structured-data node, not only the post-interaction DOM.
Product data and page both say in_stock, but an address blocks checkout Shipping scope, regional inventory, or fulfillment rules contradict the offer Add the exact SKU and test a named destination within the configured target scope without completing payment.
Store inventory is correct, but Merchant Center shows an old value Update cadence, failed sync, mapping rule, or wrong data source Compare the commerce timestamp with the submitted input and source name.
Submitted input is correct, but the processed product differs or has issues Supplemental data, account rules, automations, or processing may be contributing Inspect the processed Product, status, and contributing sources rather than resending blindly.
The page is right in your normal browser but wrong in a crawl or clean session Geolocation, cookies, device-specific pages, redirects, cache, or client-only rendering may alter initial state Test without login or stored state, on mobile and desktop URLs where both are submitted, and compare the raw response.

Google’s current mismatch troubleshooting page identifies variant preselection, dynamic location behavior, stale HTML or microdata, preorder and backorder labeling, and landing-page/checkout inconsistency as common causes. It also says basic availability should not remain hidden until a customer supplies a postal code. Regional differences still need an explicit supported model; a silently personalized page is not a substitute.

Fix the model, then fix the feed

A durable repair starts upstream and moves forward. Editing the Merchant Center row alone often creates a brief match that breaks at the next inventory sync.

1. Make each variant a first-class offer

Create or confirm a stable offer ID for every sellable combination. Keep the common family relationship in item_group_id, but do not submit the parent as though it were another purchasable child. Populate the exact standard dimensions, such as color and size, and use variant_option for the full set of identifying dimensions where applicable.

The commerce availability resolver should return a status for that exact offer and scope. It should not inherit a family status unless every child genuinely shares it. Normalize internal states deliberately: “incoming,” “supplier order,” “presale,” “notify me,” and “store only” are business labels, not automatic synonyms for Google values.

A corrected preorder record for the fictional example would contain the following relationship:

id: NL-TRAIL-BLU-10
item_group_id: NL-TRAIL
color: Blue
size: 10
availability: preorder
availability_date: 2026-10-15T09:00-0700
link: https://shop.example/northline-trail?color=blue&size=10

2. Give the offer a URL that reproduces it

The submitted link must open the represented variant by default. Google recommends this explicitly in its landing-page requirements, and its current product variant structured-data guidance shows variant-specific URLs for single-page implementations.

Preserve selection through redirects, tracking parameters, consent handling, localization, and client hydration. Test the final URL, not the string in the export. If the page cannot reliably reproduce the exact option, separate variant URLs may be safer than a generic family URL that depends on session state.

3. Make the initial response and structured data agree

Availability that appears only after JavaScript runs is more fragile than availability present in the initial response. Google recommends including product structured data—especially price and availability—in initial HTML where possible and warns that dynamically generated markup can make shopping crawls less frequent and less reliable for fast-changing fields.

The structured-data offer must identify the same SKU or variant and use the matching Schema.org availability value: for example, InStock, OutOfStock, PreOrder, or BackOrder. For preorder and backorder, align availabilityStarts with the submitted availability_date and visible customer-facing date. Remove stale parent offers or duplicate JSON-LD blocks that contradict the selected child.

4. Make cart and checkout prove the claim

An active button is evidence only when it adds the correct offer. Confirm the cart line’s SKU, option labels, quantity eligibility, price, availability message, and expected ship date. Then continue far enough into checkout to verify fulfillment for one explicitly recorded destination, without placing or paying for an order.

This catches two failures a product page can hide: inventory revalidation that blocks the item after cart, and shipping logic that makes an allegedly in-stock offer unavailable inside the target scope. Record pickup-only or delivery restrictions visibly and model them correctly rather than allowing checkout to surprise the buyer.

5. Update the site and Merchant Center as one operation

Publish inventory, page state, structured data, and Merchant Center input as close together as practical. For fast-changing catalogs, Google’s current Merchant API guidance for frequent updates supports partial productInputs.patch updates for fields such as availability, while still recommending regular reinsertion to keep all product data synchronized. Merchants using a platform connector should fix the platform’s source mapping and follow that provider’s supported sync path rather than layering an unmanaged second writer on top.

Do not rely on automations to repair a systematically wrong source. They cover only part of a catalog, operate from crawled page evidence, and use the relaxed compatibility rule described earlier. A consistent source remains the durable fix.

6. Verify Google’s processed result

After resubmission, inspect the exact affected offer—not merely the family name—and confirm the final processed availability, link, variant attributes, destination status, and issues. In the Merchant Center interface, begin with Products → Needs attention and use the affected-item examples or downloadable issue data where available; Google’s missing availability help documents that workflow. In an API integration, retrieve the processed Product and its productStatus rather than treating a successful ProductInput write as the end of the test.

A verification run you can hand to an operator

Use one row per affected offer. Do not put “all variants checked” in the notes unless each linked offer was actually opened and exercised.

  1. Copy the exact offer ID, feed label or target context, item group ID, color, size, and submitted link from the affected product.
  2. Record the submitted availability and availability_date; then record the final processed value and any item issues separately.
  3. Open the submitted link in a clean browser session. Before touching the controls, capture the selected variant, visible status, date, price, and buy-button state.
  4. Confirm that the visible option labels exactly identify the feed variant. Color naming should not be silently generalized from a specific page value to a broad feed value.
  5. Inspect the initial HTML and structured data for the same SKU or variant. Record Offer.availability and availabilityStarts where relevant.
  6. Add the item to cart. Confirm that the cart line has the same SKU, color, size, status, price, and promised date.
  7. Test checkout for one explicit destination within the configured target scope. Stop before payment. Record whether delivery is offered and whether the availability promise changes.
  8. Repeat the landing and checkout checks for submitted mobile URLs or materially different mobile rendering.
  9. Fix the commerce source or mapping rule first, then publish page, structured-data, and Merchant Center changes together.
  10. Recheck the processed product after Google has recrawled and reprocessed it. Preserve screenshots, timestamps, and the before/after row for editorial or operational review.

The downloadable matrix in this package turns those steps into a filled comparison rather than an empty template. Duplicate its columns for your real affected offers, but replace the fictional scope, dates, SKUs, and outcomes with evidence from your own source, page, and checkout.

After the repair

Do not request a review while the old page, schema, or checkout behavior is still live. When technical fixes are live and a fresh crawl is triggered through the documented review path, Google’s mismatch guidance says those crawls usually complete within 24 to 48 hours, while the interface may take additional time to reflect processing and some violations have extra verification steps or review limits. That is a processing window, not permission to leave contradictory surfaces in production.

The strongest closure note is not “feed fixed.” It is a compact chain of evidence:

Offer NL-TRAIL-BLK-10; submitted and processed state out_of_stock; Black / size 10 preselected at the submitted URL; matching OutOfStock structured data in the initial response; disabled purchase path; verified for the stated target and delivery scope.

That sentence answers both questions the generic status could not: in stock where, and for which variant?

Sources

Back to blog

Keep reading

Turn the idea into a playable

Build and test an interactive ad in Hookin. No code required.

Start free