# When AI Shows the Wrong Price or Stock for Your Products
> If an AI assistant quotes a stale price, an expired sale, or the wrong stock for a product buyers can still see, the cause is data drift: your feed, markup, cached copy, and live page disagree, and the agent read a stale one.
## Key takeaways
- A wrong price or stock value in an AI answer is a data-drift problem, not a selection or visibility one: you are shown, but the agent read a number that no longer matches your live offer. Fix the drift; do not re-optimize your titles.
- The stale value almost always comes from one of four places: a cached copy or Markdown mirror that never refreshed, surfaces (feed, structured data, page) that disagree, an inventory feed on too slow a batch, or an edge or geo branch that shows agents a different price.
- Diagnose by diffing the same SKU across every surface an agent can read, then trace the stale one back to its source. This page finds the surface that drifted; the caching, schema, and feed pages it links to are where you fix it.
- Never fix this by serving agents a different price or stock than shoppers see. That is cloaking and a parity violation, and it gets products disapproved. Make the surfaces agree instead.
## You are shown; the data is stale
This diagnostic is for one specific failure: your product does appear in the AI answer, but the price, sale, or stock status the assistant quotes is wrong. That is a different fault from being absent (that is [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/)) and from being shown but passed over ([shown but not selected](/shown-but-not-selected/)). Here you are visible, and the number is simply out of date.
A wrong price or stock value in an agent's answer is a synchronization problem: somewhere between your source of truth and the surface the agent actually read, a value went stale. So the fix is never to rewrite your titles or resubmit for eligibility; it is to find which surface drifted and why. The stakes are higher than a cosmetic lag: an agent that quotes a price you will not honor, or offers a buyer something that sold out, produces a failed or disputed checkout, which is exactly the outcome that teaches an agent to distrust your offers.
Work the four causes below in order and stop at the first one that is true for you:
1. A cached copy or mirror of the page went stale.
2. Your surfaces disagree, and the agent trusted the wrong one.
3. Your inventory feed refreshes too slowly.
4. An edge, geo, or currency branch serves agents a different value.
## Cause 1: a cached copy or mirror went stale
The fastest miss to rule out is that the agent never read your live page at all; it read a cached or mirrored copy that was generated once and never refreshed when your price or stock changed. If your JSON-LD is baked into a cached HTML snapshot, or you publish a Markdown mirror of the page, and that copy is regenerated on a long interval, then a price change on the live page will not reach the copy until the next rebuild, and any agent reading the copy quotes the old number. A `.md` mirror is a common culprit, because it feels static and tends to get a long cache lifetime, while price and availability are the two fields on the page that change most.
To check it, fetch the exact representation an agent would read (the raw HTML, the JSON-LD block, and the `.md` mirror if you publish one) and compare the price and availability in each against your live offer. If the live page is correct but a cached copy or mirror is stale, that copy is your cause.
The freshness rule that resolves this: low-churn machine surfaces can be cached hard, but price and availability must sit on a short cache lifetime or bypass the cache entirely, or a mirror will keep quoting an offer you no longer honor. The caching mechanics (which directives serve stale content, and how to hold a short freshness window on just the fields that move) belong in [serving agent traffic](/handbook/serving-agent-traffic/); this page only points you at the stale copy.
## Cause 2: your surfaces disagree with each other
If every copy is current but the value is still wrong, the next cause is that your surfaces do not agree, and the agent trusted the wrong one. An agent can read your price and availability from several places at once (the visible page, the Product or Offer structured data, and your [product feed](/glossary/#product-feed)), and when those disagree, it has to arbitrate. We expect it to sometimes take the stale or worst-case reading, or to distrust all three, because it has no way to know which one you actually honor.
This is not only an agent-trust question; it already breaks published rules. Google Merchant Center requires the price you submit to match the product's landing page and checkout, and a mismatch can get the product disapproved, so cross-surface agreement is an eligibility rule, not merely a trust nicety. Google's structured-data policies require your markup to reflect content that is visible to the reader, so a JSON-LD price that has drifted from the live offer violates them rather than being a harmless lag.
To check it, diff the same SKU's price, availability, shipping, and return values across the visible page, the JSON-LD, and the feed row. Any field where the three disagree is a surface that needs to be driven from one source. The structured-data shape lives in [product schema for AI shopping](/product-schema-for-ai-shopping/) and the feed attributes in [make your product feed AI-readable](/make-product-feed-ai-readable/); the durable fix is to generate every surface from one source of truth so they cannot drift apart.
## Cause 3: your inventory feed refreshes too slowly
A common special case of drift is stock: the item genuinely sold out, but your feed still lists it as available because the feed regenerates on a slow schedule. The Agentic Commerce Protocol feed is designed to be refreshed frequently rather than on a slow batch, so availability and price can stay current for the agents that read it. When a fast-moving product sells out but the feed waits hours for its next scheduled run, an agent reading the feed keeps offering a buyer something the warehouse can no longer ship, and that oversell is what turns a stock lag into a failed checkout.
To check it, pick a fast-selling product, compare its current feed availability against real warehouse stock, and find out whether a stock change triggers a refresh or waits for the next batch. If the gap is wide enough to oversell, the cadence is your cause. Tightening it is feed work, covered in [make your product feed AI-readable](/make-product-feed-ai-readable/); this page's job is only to point you there.
## Cause 4: an edge, geo, or currency branch serves agents a different value
The last cause is the most dangerous, because its accidental and its deliberate forms look identical from the outside. A CDN rule, a country or currency branch, or a dedicated bot code path can hand an agent a different price than a shopper sees, for example a default-currency or pre-tax figure served to a request that arrives without a geo cookie. The agent then quotes a number no human meets at checkout, and your own logs show nothing obviously wrong.
Accidental edge variance is a legitimate cause to check for. Making it deliberate is not a fix. Google defines cloaking as presenting different content to users and search engines to manipulate rankings and mislead people, and its policy names user-agent-based swapping directly, giving as an example "inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor."
> **Do not fix drift by cloaking**
>
> Never resolve a price or stock mismatch by serving agents one value and shoppers another. Showing crawlers a favorable price while humans see a different one at checkout is cloaking and a parity violation: it gets products disapproved and it destroys the agent trust you are trying to earn. The honest fix is always to make every surface show the same offer, never to special-case the agent.
To check for accidental variance, request the product page the way an agent would, stripped of your usual geo and currency cookies, and confirm the price and availability match what a shopper reaches at checkout. If a geo, currency, or bot branch changes the value, that branch is your cause, and the fix is to make it serve one offer to everyone. This is the parity boundary the [content equivalence signal](/signals/content-equivalence-no-cloaking/) draws.
## The one diff that isolates the drift
Rather than guess which cause is yours, run a single comparison and let it point you. Take one SKU whose price or stock you know an agent got wrong, and line the value up across every surface an agent can read:
- the visible product page (the rendered HTML),
- the Product or Offer structured data inside that page,
- your product feed row,
- and any Markdown mirror or cached copy you publish.
Where they all agree and match your live offer, the surface is fine. The one that disagrees is your drift, and which one it is tells you the cause: a stale mirror or cache points to Cause 1, disagreement among otherwise-current surfaces to Cause 2, a feed that lags reality to Cause 3, and a value that only changes when you drop your geo or bot headers to Cause 4. Fixing the surface without tracing it back to its source only resets the clock, so follow the stale value to the system that generates it before you call it fixed.
## What to measure
Freshness is not a one-time fix; a batch job slips, or a cache rule regresses. Turn the diff above into a standing check rather than a one-off:
- On a schedule, pull the price and availability for a sample of fast-moving SKUs from each surface (page, JSON-LD, feed, mirror) and flag any that disagree with the source of truth. A surface that drifts repeatedly is a cache lifetime or a sync job to fix at the root.
- Track how often the value an agent quotes matches your live checkout. When you test selection, record whether the price and stock the agent stated were correct, alongside whether you were picked, so a data fault cannot hide inside a selection metric.
- Fold this into your [agent win rate](/glossary/agent-win-rate/) measurement rather than running it separately, and re-check after any change to your caching, feed cadence, or CDN rules. [How we test agent selection](/research/methodology/) gives you the repeatable protocol.
## This page finds the drift; the linked pages fix it
Keep the jobs separate. This is the flow you run after you notice an assistant quoting the wrong price or stock, to isolate which surface drifted. The fixes live where the depth is: cache and freshness in [serving agent traffic](/handbook/serving-agent-traffic/), markup in [product schema for AI shopping](/product-schema-for-ai-shopping/), and feed cadence in [make your product feed AI-readable](/make-product-feed-ai-readable/). Its sibling diagnostics narrow a different symptom: [shown but not selected](/shown-but-not-selected/) when your data is right but a competitor wins, [lowest price but not recommended](/lowest-price-but-not-recommended/) when you are the cheapest and still lose, and [the AI engine visibility gap](/ai-engine-visibility-gap/) when you appear on some engines but not others.
## Frequently asked questions
### Why does an AI still show my old sale price after the sale ended?
Because the value the agent read was cached, or came from a surface (a feed row, a JSON-LD block, or a Markdown mirror) that was not refreshed when the sale ended. Find the surface that still carries the old price, trace it to its source, and keep price and availability on a short cache lifetime so a stale copy cannot outlive the change.
### Is it ever acceptable to show agents a different price than shoppers?
No. Serving crawlers one price and humans another to influence rankings is cloaking under Google's spam policy, and a price that does not match your landing page and checkout gets products disapproved in Merchant Center. Make every surface show the same offer instead of special-casing the agent.
### How fast do I need to update stock for AI shopping agents?
There is no universal number, but availability should track reality closely. The Agentic Commerce Protocol feed is built to refresh frequently rather than on a slow batch, and a daily-batch feed is a common reason a sold-out item still shows as in stock. Tighten the cadence for fast-moving products so the feed does not oversell.