Availability markup tells a machine whether a product can be bought right now. Pick InStock when you can fulfill orders, OutOfStock when you are not selling the item, PreOrder when an unreleased product takes orders, and BackOrder when a sold-out product still takes orders and ships later. One listing carries one value, and that value has to match the page, the cart and the feed. The examples use smartwatch bands, where stock changes by color, wrist size and watch model.
The value definitions come from the Merchant Center Help page on availability (Opens in a new tab), the schema.org ItemAvailability list (Opens in a new tab) and the Google Search Central merchant listing documentation (Opens in a new tab). Google may change these pages, so check the current versions before you rely on a detail.
The one value rule: how availability is filled
The merchant listing documentation lists availability as a recommended Offer property. The accepted values are BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, OnlineOnly, OutOfStock, PreOrder, PreSale and SoldOut. They can be written as a full URL or as the short name. The documentation also says: do not specify more than one value.
That rule means there is no "in stock and on pre-order" state for one listing. If two states exist, you have two variants, and each variant carries its own value on its own page.
Google's list and schema.org's list differ
The schema.org ItemAvailability type lists twelve members: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, MadeToOrder, OnlineOnly, OutOfStock, PreOrder, PreSale, Reserved and SoldOut. MadeToOrder and Reserved do not appear in the accepted values of Google's merchant listing documentation. The schema.org page describes the type as a list of possible product availability options and the availability property as the availability of the item, for example in stock, out of stock or pre-order. It does not define each member separately. Practical suggestion: when you write for Google's product experiences, choose from Google's accepted list rather than assuming every schema.org member is used.
The four values a marketplace needs first
Merchant Center defines four feed values: in_stock, out_of_stock, preorder and backorder. For a marketplace listing these four settle the large majority of everyday decisions. The documentation has no detailed definition for the other accepted markup values such as LimitedAvailability, OnlineOnly, InStoreOnly or PreSale. If you use one, make sure the page itself shows the situation it names.
Where InStock ends and OutOfStock begins
Merchant Center describes in_stock as products you accept orders for and can fulfill, deliverable to all locations you support. out_of_stock means you are not accepting orders for the product, or the product is not available for purchase.
What the landing page must show
- For an in-stock offer, the buy button should be active.
- For an out-of-stock offer, show clear text or a disabled buy button.
- For preorder and backorder offers, show the expected shipping date.
These three points come from the minimum requirements on the Merchant Center page. An active button next to OutOfStock, or a disabled button next to InStock, are two faces of the same mismatch.
Regions that are not served
If a product is not sold in part of the target country, the Merchant Center page says to set out_of_stock for those regions, or to use regional availability and pricing where supported. A watch band shipped only from one warehouse to certain countries needs that gap stated on the page and in the feed.
PreOrder versus BackOrder
Both values mean orders are still accepted. The difference is the history of the product. Merchant Center defines preorder as accepting orders for a product that has not been released for sale. It defines backorder as a product that is not available at the moment but is still accepting orders, to ship when the item is back.
| Question | PreOrder | BackOrder |
|---|---|---|
| Has the product been sold before? | No, not yet released | Yes, it sold out |
| Are orders taken? | Yes | Yes |
| What does the date mean? | When it becomes available for delivery | When it will ship |
| Is the date visible on the page? | Yes | Yes |
The date requirement
Merchant Center says you must submit an availability date with either value. For preorders it shows when the product becomes available for delivery, for backorders when the item will ship. The page adds that the availability date should be visible on the landing page.
When the exact date is unknown
If you do not know the exact date, an estimated date such as "May 2023" is acceptable according to the page. Practical suggestion: stay at month and year, and update the text as soon as the date passes. A "coming soon" message with a date in the past damages trust in the whole page.
PreOrder is for new products only
The boundary is stated plainly: the preorder value should only be used for new products that have not been released yet. An existing out-of-stock item that still takes orders should use backorder. A new generation of silicone band that is in production and open for orders is a preorder. Last year's band that sold out and awaits a fresh batch is a backorder.
Variants: color, wrist size and watch model
Smartwatch bands multiply variants quickly: a color, a wrist size, a lug width, a compatible watch model. The Merchant Center page gives a direct example about variants: a small yellow shirt can be out_of_stock while the green and blue small versions are in_stock, and each variant must match its own landing page.
One page per variant
If each variant has its own address, each page carries its own availability value. A black medium band that is in stock and a black large band that is sold out are two pages, two values.
One page with a selector
If a single page offers all sizes through a selector, the availability in the markup should describe the variant currently selected. Practical suggestion: bind the markup to the default selected variant and make sure the value changes when the shopper picks another size.
Compatibility is not availability
A band that does not fit a particular watch model is a compatibility matter, not a stock matter. Do not use OutOfStock to say "not for your watch". Show compatibility in the product name, specification table and selector, and keep availability about whether the item can be bought.
Retiring a band line without hiding behind OutOfStock
When a band is withdrawn for good, OutOfStock only says it cannot be bought now. Discontinued is a separate value in Google's accepted list. The fate of the page is the real decision: redirect, keep with an alternative, or remove. That choice is a separate topic, linked in the conclusion.
Hiding temporarily
Merchant Center says that to hide a product temporarily without causing a mismatch, use excluded_destination or pause instead of changing availability. If your interface is not in English, the label names may differ. This matters when a band line takes a short seasonal break: use pause, which Merchant Center limits to 14 days, rather than faking an out-of-stock state. Use excluded_destination when the page still shows the item in stock but you do not want it shown on certain surfaces. For a band line that is no longer sold, do not set out_of_stock: Merchant Center says to remove it from your product data.
Order of questions
- Will the product return? If so, consider OutOfStock or BackOrder.
- It will not return, but the page still has value? Consider Discontinued with a visible alternative.
- The page has no value left? Decide on a redirect or removal.
Order of updates when stock changes
Stock moves faster than price. The page, the markup and the feed should change together when the last unit of a size leaves. Tie them to one source rather than three manual steps.
- The warehouse or order system updates stock.
- The page template reads the same source and enables or disables the button.
- The template writes the availability value from the same source.
- The feed is built from that source, or automatic item updates are on.
- Caches are purged.
The Merchant Center page notes that automatic item updates can sync availability with your landing page to prevent mismatches. Practical suggestion: measure the lag between the page and the feed on a sample item and treat it as a known window.
Matching all four places
Merchant Center requires availability to match across the landing page, structured data, checkout and your data source. Table: the four places and the cost of a mismatch.
| Place | What it shows | Cost of a mismatch |
|---|---|---|
| Product page | Buy button and stock text | Shopper expects the wrong thing |
| Structured data | The availability value | Markup contradicts the page |
| Checkout | Whether the item can be bought | The feed item can be disapproved |
| Data source | The feed attribute | The item can be disapproved |
The page states the consequence plainly: a mismatch in one of these will trigger a product disapproval. If the product is out of stock on the landing page or at checkout but in_stock in your data, it is disapproved. If it is in stock on the page and at checkout but out_of_stock in your data, it is also disapproved.
Checkout as a source of truth
A band can show an active button and still fail at checkout because the last piece went to another order a minute earlier. Two shoppers can race for the final unit. The window cannot be removed, but it can be kept short: decrement stock in the same transaction that confirms the order, and purge the page cache the moment stock reaches zero. Practical suggestion: if you reserve stock for carts, say so on the page, and if you do not, do not imply that you do.
Feed names versus markup names
Feed values and markup values describe the same state in two vocabularies. The mapping in the table is a practical suggestion, not a statement from the documentation.
| State | Merchant Center feed | Markup | Extra requirement |
|---|---|---|---|
| Can be bought and delivered | in_stock | InStock | Active buy button |
| Not for sale | out_of_stock | OutOfStock | Clear text or disabled button |
| Unreleased, orders open | preorder | PreOrder | Availability date, shown on page |
| Sold out, orders open | backorder | BackOrder | Availability date, shown on page |
Feed values are lowercase with underscores. Markup values use the short name or a full URL such as https://schema.org/InStock. Pick one markup style in the template so the two do not mix.
Worked example: a smartwatch band catalog
A seller lists four bands on a marketplace. The scenario is invented.
| Listing | Reality | availability | Page shows |
|---|---|---|---|
| Graphite silicone, medium | In the warehouse | InStock | Active button |
| Graphite silicone, large | Sold out, orders closed | OutOfStock | Out of stock, disabled button |
| Sand woven loop, medium | Sold out, new batch coming, orders open | BackOrder | Estimated ship date |
| New-generation leather band | Not released, orders open | PreOrder | Expected delivery date |
When the batch is late
The sand woven loop page said "ships in January" and February arrived. The batch is late but orders still come in. The page must show the new estimate, and the feed must carry the same date. If the batch does not arrive, close orders and return to OutOfStock. The scenario is invented.
Season changes
When a new band generation opens for preorder while the old one sells out, two listings can show up together. Put the generation in the product title so each page makes clear which state it describes.
Who owns stock data on a marketplace
The seller knows the stock, and the platform generates the page and markup. Stock flows from the seller dashboard to the platform, then to the page and the feed. A delay at any link causes a mismatch.
| Data | Source | Updated by | Risk |
|---|---|---|---|
| Stock count | Seller dashboard or warehouse | Seller | Update forgotten |
| Order acceptance | Platform setting | Seller | Not closed when sold out |
| Expected date | Seller dashboard | Seller | Date passes, text stays |
| Markup value | Template | Platform team | Old value in cache |
| Feed attribute | Feed generator | Platform team | Refresh interval |
Plain rules for sellers
Give sellers three rules. If stock is zero and you take no orders, mark the listing out of stock. If you still take orders, choose pre-order or back-order depending on whether the product was ever released, and enter a date. If the date passes, update the listing. Put short helper text next to the fields in the dashboard.
Making the date field required
When a seller picks pre-order or back-order, the date field should become required and reject a past day. A listing saved without a date cannot meet the date requirement in Merchant Center. Hide the field until one of those two states is chosen.
Diagnosing a disapproved item
Merchant Center mentions a guided troubleshooter for disapprovals caused by mismatched values from page crawls. Before opening it, check your side in order.
- Open the page in a private window and note the state of the button.
- Add the item to the cart and go to checkout to see whether it can still be bought.
- Read the availability value in the page markup.
- Read the same item's availability in the feed.
- Put the four observations side by side and find the one that differs.
- Fix it at the source, purge caches and wait for the feed to refresh.
| Observation | Likely source | Look first at |
|---|---|---|
| Page sold out, feed in_stock | Feed lag | Feed refresh time |
| Page in stock, feed out_of_stock | Stale feed data | Link between stock source and feed |
| Markup InStock, button disabled | Template prints a fixed value | Template code |
| Page and checkout disagree | Cart stock check | Checkout logic |
The documentation has no statement on how long a correction takes to show. Re-check with the same observations after the fix instead of assuming success.
Testing the template before release
A template that prints availability needs a test for every state, because one wrong branch affects every listing that uses it. Prepare a small set of sample listings, one per state, and read the output after each template change.
| Case | Expected availability | Page |
|---|---|---|
| Size in stock, orders open | InStock | Active button |
| Size sold out, orders closed | OutOfStock | Out-of-stock text |
| Sold out, orders open, restock planned | BackOrder | Estimated ship date |
| Unreleased, orders open | PreOrder | Expected delivery date |
| Pre-order with a past date | Needs an update | No stale date shown |
Template logic in plain words
First check whether the product takes orders. If not, print OutOfStock. If it does, check whether the item is in hand. If so, print InStock. If not, check whether the product was ever released. If not, print PreOrder, otherwise BackOrder, and show the date on the page and write it to the feed. For several variants, run this logic once per variant.
Reading a result
If one case fails, assume every listing on the same template is affected and rerun all five cases after the fix. Keep the sample set stable between releases so results can be compared. Practical suggestion: store the expected output next to the sample so a reviewer sees a difference at a glance.
Handing the rule to a developer
A short note is enough: one value per listing, the button must agree with the value, the two order values need a visible date, variants are marked separately, and a temporary hide uses a supported option. Attach the test table as the acceptance test.
Availability markup checklist
- Does each listing carry exactly one availability value?
- Is the value in Google's accepted list?
- Does an InStock page have an active buy button?
- Does an OutOfStock page show clear text or a disabled button?
- Is PreOrder used only for products not yet released?
- Is BackOrder used for sold-out products that still take orders?
- Do PreOrder and BackOrder pages show the date?
- Does each variant match its own page?
- Do page, markup, checkout and feed show the same state?
- Has a retired product avoided a fake OutOfStock?
Decision rule: which value?
Ask in this order. Are you accepting orders? If not, OutOfStock. If yes, is the item in hand and deliverable? If so, InStock. If not, has the product ever been released? If not, PreOrder. If so, BackOrder. For PreOrder and BackOrder, write the date on the page and in the feed. Run the question once per variant.
Worked through for one band: the graphite medium is in the warehouse and orders are open, so the answer is InStock. The graphite large sold out and the seller stopped taking orders, so OutOfStock. The sand loop sold out but a batch is coming and orders are open, and since it sold before, BackOrder with a ship date. The new leather band has not been released yet and orders are open, so PreOrder with a delivery date. Each answer then has to appear on the page as a button state or a date.
The rule also protects the seller from over-promising. A date that the seller cannot keep is worse than a wider estimate. If a supplier gives only a month, publish the month. Update it when the supplier confirms the real day.
Mistakes to avoid
PreOrder for a sold-out item
Merchant Center reserves preorder for unreleased products. A sold-out item that takes orders is a backorder.
A date missing on either order value
The page asks for an availability date with both values, and for the date to be visible on the landing page.
Two values on one listing
The documentation says not to specify more than one value. Split the listing into variants.
Changing the value to hide an item
For a temporary hide, use excluded_destination or pause. A false value creates a mismatch.
Compatibility mistaken for stock
A band that does not fit a watch is not out of stock. Express fit through specifications.
Frequently Asked Questions
Can I write InStock and PreOrder together on one listing?
No. The merchant listing documentation says not to specify more than one availability value. Split the product into variants and mark each one on its own page.
When is BackOrder right and when is PreOrder right?
Merchant Center reserves preorder for new products that have not been released. An existing item that sold out but still takes orders should use backorder.
Do I need a date for pre-orders and back-orders?
Yes. Merchant Center asks for an availability date with either value and says the date should be visible on the landing page. An estimated month and year is acceptable if the exact date is unknown.
How do I pause a band listing without a mismatch?
Merchant Center says to use excluded_destination or pause instead of changing availability. Changing the value to something false creates a mismatch.
Should one sold-out size make the whole band page OutOfStock?
No. The Merchant Center page says each variant's availability must match its own landing page, for example one size out_of_stock while other sizes stay in_stock.
What happens when feed availability and the page disagree?
Merchant Center states that a mismatch triggers a product disapproval, in either direction. The page also mentions a guided troubleshooter for mismatches found by page crawls.
Conclusion
Availability markup works with one value per listing, and that value has to be identical on the page, in checkout and in the feed. InStock is for items you can fulfill, OutOfStock for items not for sale, PreOrder for unreleased products with open orders, and BackOrder for sold-out products that still take orders. The last two need a visible date. Variants carry their own state, compatibility stays out of the stock field, and a temporary hide uses the supported Merchant Center options instead of a false value.
To plan the page fate of items that will not return, read the guide on out-of-stock and discontinued product pages. For the feed errors that surround price, stock and identifiers, see Merchant Center product data errors. If you want your listings in front of more shoppers, look at the options on the ad spaces page.
Post a comment
Please log in to leave a comment. Login