Blog · Agents and commerce

Stock, availability and answers that go stale

Published 16 June 2026 · Updated 12 October 2026 · 8 min read

Stock, availability and answers that go stale
Photograph: Mick Haupt / unsplash

The short answer: Your availability exists in at least three copies, your rendered page, your structured data or product feed, and whatever snapshot the engine kept, and each copy runs on its own clock. An assistant can answer from the slowest copy, in a confident sentence, with no timestamp attached. In the cases we have looked at, stale stock in an answer was not a data error. It was a synchronisation gap, and that gap is something you can measure.

One retailer brought us an answer that recommended a product their warehouse no longer stocked. The product page was correct. The feed was correct. The engine was quoting a cached copy of a category page, and nobody had thought to look there. That is one case reported to us, not a measurement, and we record it because it shows a path people forget to check.

Three copies, three clocks

Draw the path a stock number travels and the problem explains itself.

The first copy lives in your commerce system and changes whenever an order is placed. The second is whatever you publish: the rendered HTML a shopper sees, the JSON-LD inside that page, and a product feed if you file one. Those usually update on a schedule, not on an event. A nightly feed job means a figure can be eighteen hours old before anyone reads it.

The third copy is the one you do not control. An engine that fetched your page yesterday, or that is reading a shopping index built from your feed, holds a snapshot. We cannot see inside an engine's retrieval, so we infer behaviour from our own access logs and from the answers themselves. On that evidence, some assistants re-fetch at answer time and some answer without a fresh fetch, and we have seen single answers that appear to mix the two, taking price from one source and availability from another.

That mixing is the bit people miss. An answer can be fresh and wrong in the same sentence, because its two halves came from different hours. Agentic commerce: what an agent needs from your catalogue covers which fields the agent reads. This post is about when it read them.

The vocabulary loses detail on the way down

Availability is not a boolean anywhere in the stack, and the stack does not agree on how many states exist.

Counted on 12 October 2026, schema.org's ItemAvailability enumeration lists twelve values, including LimitedAvailability, BackOrder, PreSale, Reserved and SoldOut. Google's merchant listing documentation accepts ten of those for offers.availability, every one except Reserved and MadeToOrder. OpenAI's published commerce feed specification narrows further, to five: in_stock, out_of_stock, pre_order, backorder and unknown. Those three counts are from those three documents on that date, and nothing here claims the same ladder applies to engines whose feed specs are not published.

Twelve, then ten, then five. Every step down that ladder is a rounding operation, and you do not choose how it rounds. SoldOut and Discontinued and LimitedAvailability all have to land somewhere inside a five-value set. A line that reads "limited stock, two left" on your page can reach a surface built on that five-value set as plain in_stock, with nothing left in the field to say the depth was one.

Notice the fifth value in that list. unknown is a real, documented state, and in that same feed specification an omitted or empty value is read as unknown rather than as a prompt to go and look. We cannot see how any surface then ranks an unknown against a stated value, so treat the practical advice that follows as inference from the documented semantics, not a measured effect: a field you leave empty is a field that reads as unknown.

Where the lag is usually manufactured

Automatic extraction is the source of quiet staleness we run into most often in audits, and it is worth reading what the documentation actually says about it.

Google's Merchant Center automations will update price, sale price, availability and condition by crawling your landing pages and structured data. The guidance attached to that feature is unusually direct: automations are not a replacement for regular updates of your product data, and they may not keep up with products that change more than once per day. Repeated mismatches can get items disapproved rather than quietly corrected.

Read that as a design note. The crawler is a fallback, tuned for a daily rhythm, and the same page records that automations use relaxed matching, where in_stock, preorder and backorder are all treated as compatible with in_stock. If your stock turns over faster than daily, the documentation itself says automations may not keep up, and the system treats your page as the source of truth while the two disagree. We have not measured how often that produces a wrong answer, and the documentation does not put a figure on it either.

Three more lag sources we see often. Client-side rendered stock badges, where the HTML an engine stores says nothing about availability because the number arrives after the JavaScript runs. Variant pages that inherit the parent product's availability, so a sold-out size reports as in stock. And cached category or collection pages, which in our audits are the copy teams most often forget, and which are a page shape engines do quote because one page lists many products at once.

A check you can run this afternoon

Pick five products with real turnover. For each one, write down four values and the clock time you read them.

One, the availability a shopper sees in the rendered page. Two, the value inside the page's JSON-LD, read from the raw HTML rather than the browser inspector, since that is what a fetch without JavaScript returns. Three, the value in your feed, taken from the file you actually filed, not the admin screen. Four, what two assistants say when you ask whether the product is in stock today, run twice each.

Any disagreement between one and two is a rendering or templating bug and is yours to fix this week. A disagreement between two and three means two publishing paths have drifted apart. A disagreement between three and four is engine lag, and the only thing you can do about it is shorten your own cycle and wait. The self-check has the rest of the ten things worth testing by hand before anyone buys tooling.

Then do the part most teams skip. Deliberately mark one test product out of stock, note the minute, and re-ask the same question every few hours until each assistant catches up. You now have a propagation time for your own site, which is a far more useful number than any industry average. It also sets honest expectations, because the shape of that curve is the same one described in how long AEO takes to show up in answers.

One more thing to watch while you do it. Your logs will show the fetches that answer these questions, and they do not look like ordinary crawling. They arrive in bursts, at the moment a user asks, from a narrow set of agents. Agent traffic is not bot traffic explains how to separate them, and once you can, your access log becomes a direct read on which engine refreshed what and when.

Fix order, cheapest first

Serve availability in the HTML, not after it. Keep the JSON-LD generated from the same variable the visible badge uses, so the two cannot disagree. Set priceValidUntil honestly instead of a year out. Push an event-driven update on the transitions that matter most, which are in stock to out of stock and back, even if the rest of the feed stays nightly. Fix variant inheritance before you touch anything else, because it is the error that produces the angriest customers.

Engines differ in how much of this they re-check, though we are reading that difference from the outside rather than from any published cadence. An answer grounded in a shopping index need not behave like one assembled by a fetch at answer time, which is part of why how Gemini answers brand questions reads differently from the same question put to a chat assistant.

Honest limits

We have not found a published cache lifetime for the five engines in our prompt set, and we cannot observe one from outside, so every statement here about when an engine refreshes is an inference from access logs and from the answers themselves. The three value counts are the only hard numbers in this post, and they are counts of three documents on 12 October 2026, not claims about engines generally.

The retailer case above was reported to us, not instrumented, so treat it as an illustration of a failure path rather than evidence of how often that path fires. We have no controlled test of how an assistant weighs a stale availability signal against a fresh one when its sources conflict, and we have removed an earlier sentence that implied we did. The propagation check above produces a number for your site and tells you nothing about anyone else's.

FAQ

Does marking everything in stock help visibility? It raises the odds of being recommended and then disappointing the buyer, and repeated mismatches between markup and landing page can get listings disapproved. The downside is larger than the upside.

Should I leave availability out if I cannot keep it current? No. In OpenAI's feed specification an omitted value is read as unknown, so omission states something rather than nothing. We cannot see how a surface ranks an unknown against a stated value, but a field that reads as unknown is not a field held open for later.

How fast should a feed update? Fast enough that the field is true when it is read. Automatic crawling is documented as unsuitable for items that change more than once a day, so anything turning over faster than that needs an event-driven push on at least the in-stock transitions.

Why does one assistant have the right stock and another does not? They appear to source differently. One may fetch your page at answer time while another quotes an index built hours or days earlier, and we have seen single responses that look like a blend of both. None of the engines publishes its refresh cadence, so this is inference, not doctrine.

Sources

All four were opened on 12 October 2026 and each still carries the sentence cited against it.

Related reading

Agentic commerce: what an agent needs from your catalogueAgent traffic is not bot trafficHow long AEO takes to show up in answersHow Gemini answers brand questionsMCP servers for brands: a practical lookProduct feeds for AI shopping surfaces