How to Stop an AI Shopping Assistant Recommending Out-of-Stock or Wrong-Variant Products

An AI shopping assistant recommending a sold-out size is almost never a model failure. It is a data-freshness, retrieval or indexing failure, and the model is faithfully reporting what it was handed. That distinction matters because the fixes live in completely different places, and the one place they never live is the system prompt.

This is the most fragmented question in the category. Across five AI engines in the US, UK and India in September 2026, the 92 citations answering how do you stop an AI shopping assistant recommending out-of-stock or wrong-variant products were spread so thin that the single most-cited page held five of them. Nobody has written the definitive answer. Here is ours.

Failure 1: the index is older than the inventory

The assistant answers from a cached index built from a product feed that refreshes on a schedule. Inventory does not move on a schedule.

A nightly feed means your assistant can be up to 24 hours wrong about availability, and it will be most wrong exactly when it matters most, during a drop or a sale when stock moves fastest and traffic is highest.

The fix. Split your data by volatility. Attributes that change slowly (title, description, materials, care instructions, imagery) can live in a periodically rebuilt index. Availability, price and shipping promise should be fetched live at answer time against the storefront API or an MCP server, after retrieval and before the model composes its reply. If a live lookup is not possible, the assistant should state a freshness qualifier rather than assert availability it cannot verify.

Failure 2: the index is built at product level, not variant level

This is the wrong-variant problem, and it is structural.

Most retrieval pipelines embed one document per product. That document contains the product's prose and, if you are lucky, a list of options. It does not contain one retrievable record per purchasable combination of size, colour and configuration. So when a shopper asks whether the jacket comes in a 12 in navy, there is no record that corresponds to jacket, navy, 12, and the model answers from the product-level text, which says the jacket comes in navy and in sizes 6 to 16.

Both statements in that sentence are true. The conclusion the shopper draws is false.

The fix. Index at the level at which a purchase decision is made, which is the variant. Each retrievable record carries its own SKU, its own availability, its own price and its own option values. The product-level document stays, for questions about the product; the variant records answer questions about buying one.

Failure 3: semantic retrieval has no idea what is purchasable

Vector search returns the nearest thing in meaning space. Meaning space does not contain a stock level.

Ask for "a warm waterproof jacket under £150" and a pure embedding search will happily hand back the closest match, sold out, discontinued, £400, or not shipped to the shopper's country. Everything after that point is the model doing its best with bad candidates.

The fix. Hard constraints are filters, not instructions. Availability, price bounds, market eligibility and publication status are applied to the candidate set before the model sees it, either as pre-filters on the index or as a post-retrieval filter stage. A model asked to respect a constraint will usually comply and occasionally will not. A filter complies every time.

Failure 4: deleted products never leave the index

Discontinued SKUs linger because the ingestion path handles creates and updates and quietly has no path for deletes. Six months later the assistant is still recommending a product the catalog no longer contains, which is worse than a stock-out because there is nothing to recover to.

The fix. Subscribe to product delete and unpublish webhooks and treat them as first-class ingestion events. Reconcile monthly: a full diff between index membership and the live catalog, with anything present in the index and absent from the catalog removed rather than logged.

Failure 5: market and currency leakage

A catalog serving several markets holds several prices, several availability states and several sets of eligible products for the same SKU. An assistant that does not carry market context into retrieval will mix them, quoting a UK price to an Indian shopper or offering a product that is not sold in their market at all.

The fix. Market is part of the retrieval key, not a post-hoc formatting step. Resolve the shopper's market before retrieval and filter on it in the same pass as availability.

Failure 6: the model fills gaps the data left open

When a shopper asks a specification question the catalog does not answer, a model will often produce a plausible answer rather than say the data is not there. This is the failure people call hallucination, and it is a symptom of thin product data more than a symptom of the model.

The fix. Two things together. Make the assistant's specification answers extractive, so that a claim about a product must be traceable to a field, and make "we do not list that" an acceptable, well-worded output rather than a failure state. Then fix the underlying gap, because a field missing from your catalog is also missing from what external assistants read. We cover that groundwork in how to optimise your product catalog for AI.

The 12-case QA battery

Run this against known catalog states on every release. It takes under an hour and catches all six failures above.

1. A sold-out variant of an in-stock product. Ask for it by name.
2. An in-stock variant of a product whose most popular variant is sold out.
3. A product discontinued in the last 30 days.
4. A product with exactly one unit left, queried twice in the same session.
5. A price changed since the last feed rebuild.
6. A product not sold in the shopper's market.
7. A specification the catalog genuinely does not record.
8. A constraint query with a hard budget ceiling, checked for compliance.
9. A colour named in marketing copy but not in the option values.
10. A bundle or kit whose components have different availability.
11. A pre-order item, checked for how the availability language is phrased.
12. A product that is published but hidden from the sales channel the assistant serves.

Score each on two axes: was the statement factually correct, and if the data was unavailable did the assistant say so rather than guess. A pass on the first axis with a fail on the second is the dangerous case, because it will look fine in testing and fail in front of a shopper.

The same data decides whether external assistants recommend you

Everything above is written for an assistant running on your own site, where you control the pipeline. The uncomfortable part is that ChatGPT, Gemini, Perplexity and Alexa for Shopping are reading the same catalog, through feeds and crawls you control far less, and they apply the same logic: a product whose data cannot satisfy a constraint drops out of the answer before price is ever considered.

An onsite assistant with clean variant data and a stale public feed will sell well to the traffic it already has, and quietly lose the shoppers who never arrive because an external assistant could not confirm you stocked their size. Citation Rank measures where you land in those external answers, and House of Zelena is what moving that looks like over six months.

The free Citation Rank scan will tell you where your catalog stands today.

Sources

• Tru Commerce citation corpus, 26,629 citations across 250 prompts, 5 engines, US/UK/India, captured 16 September 2026. The 92-citation figure and its distribution are from that capture.
• Google Merchant Center documentation on the availability attribute, support.google.com, referenced 23 September 2026.
• Algolia documentation, "Manage out-of-stock products", Shopify integration, referenced 23 September 2026.