AI Is Showing the Wrong Price for Your Product. What You Can Actually Do.
A search reached this site recently phrased almost exactly like this: our products show up in ChatGPT but with the wrong price and details, how do I monitor and fix that. It is a good question, and whoever typed it had already found both uncomfortable halves of the problem. Something inaccurate about their business is being repeated to strangers, and there is no obvious person to tell.
Commercial facts are the most fragile things a business publishes. The founding story does not change. The address changes rarely. Prices, stock, specifications, opening hours, delivery terms, warranty lengths and the product line-up itself change constantly, and every one of them is the kind of concrete detail an assistant is comfortable stating flatly in a sentence. The facts most likely to be quoted are, unhelpfully, the facts most likely to be out of date.
Four mechanisms produce most of these errors, and working out which one you are looking at decides what you can actually do about it. Skipping that diagnosis is why so much effort here gets spent in the wrong place.
The first is the training snapshot. A model answering from what it absorbed during training is describing the web as it existed at some point in the past, and it has no idea that the moment has passed. Updating your page does not reach into a model's weights. If your product cost less two years ago, and a model learned that figure then, it can keep repeating the old number with total composure long after your site has moved on. Nothing about the answer signals that it is historical, which is precisely what makes it convincing.
The second is live retrieval that lands somewhere unfortunate. Assistants that browse do fetch current pages, which sounds like it should solve the problem, and often it does. But retrieval picks a document, and the document it picks may not be the one you would have chosen. A category page listing an introductory price. A campaign landing page from a promotion that ended. A specification sheet in a PDF describing the previous generation of the product. A duplicate product page that survived a site migration and still ranks. All of these are current in the sense that they are live on the internet, and stale in the sense that matters.
The third is everyone else who repeats your data. Marketplace listings from resellers, comparison sites, distributor catalogues, syndicated feeds you set up once, industry directories, and review articles that copied your specifications on the day they were written and have not looked since. Collectively these usually outnumber your own pages, and some of them carry more crawl weight than your site does. If four third-party sources agree on last year's price and only your product page carries this year's, the arithmetic is not in your favour.
The fourth is your own site, which is the one people resist. Old blog posts announcing a price. A downloadable brochure nobody has opened internally in years. An FAQ answer written around a model you discontinued. A regional subsite that never got the update. Terms and conditions superseded by a revision that was published as a new page instead of replacing the old one. These are your pages, they are indexable, and they are arguing against you.
There is a fifth situation that is not really an error at all, and it is worth separating out. Sometimes the price was never a single number. It is a range, or it depends on volume, or it excludes tax in one market and includes it in another, or it is a subscription with a term commitment, or it is quoted per unit but sold in packs. Someone asks an assistant what your product costs and gets one figure, because the question has the shape of a question with one answer. If your own pages never state the structure plainly, a model will simplify it, and the simplification will be wrong in a way that is partly authored by you.
Before fixing anything, find out what is actually being said, because most owners are working from a single alarming screenshot. Write down the questions a buyer would really ask — what does this cost, is it still available, what is in the box, how does it compare to the obvious alternative, are you open on a Sunday — in a customer's vocabulary rather than your catalogue's. Run them across the assistants your buyers use, from signed-out sessions, and record the answers word for word along with any sources the assistant shows you. Do this monthly and log it. One run tells you almost nothing, because these systems vary between sessions and between accounts. A pattern across several months tells you which errors are stable, which are sporadic, and which quietly corrected themselves after you changed something. The assistants that display their citations are the useful diagnostic instrument here even if they are not the ones your customers use most, because they show you where the claim came from, and that is the thing you actually need.
Then triage by what the error costs rather than by how much it annoys you. A price quoted too low produces an awkward conversation you at least get to have. A price quoted too high loses you the customer silently, and you will never know it happened, which makes it the expensive one. A discontinued product recommended enthusiastically generates support work and disappointment. A wrong specification can mean a return, an incompatible installation, or in some categories a safety issue. Wrong opening hours cost you a visit from someone standing outside a locked door. These are not equivalent, and the order you fix them in should reflect that.
Now the part you can genuinely change, starting closest to home. One canonical page per product, with the price and the key specifications stated in text rather than assembled by a script or hidden inside an image. A visible date or a plain statement of when the information was last confirmed. Superseded pages redirected to their replacement or removed outright, not left online because deleting things feels wasteful. A discontinued item marked as discontinued rather than deleted, so that a machine asking about it finds a current page saying it is gone, instead of finding an old page saying it is available. That last one is counterintuitive and it works.
State the same facts in machine-readable form as well, so that they can be read without interpretation. Offer data supports availability status and a date after which a price should not be trusted, and those two fields exist precisely for this problem. Markup will not rescue a page whose prose contradicts it, so the point is agreement between the two, not markup as a separate exercise.
Then go outward, which is the slow part. Make a list of every place your product data appears that you do not control, and rank it by how visible it is to a crawler rather than by how much traffic it sends you. Those are different lists and people habitually work the wrong one. Feeds you configured years ago and never audited are a common culprit, because they keep publishing confidently from a mapping that no longer matches your catalogue. Distributor and reseller pages usually update if you ask, and usually nobody asks.
Here is the part with no comfortable answer. There is no support line. No ticket queue, no correction form with a service level, no escalation path to a person who can edit what a model says about you. Some providers offer feedback controls, and using them is reasonable, but treat them as a courtesy rather than a mechanism. Models are retrained on their owners' schedule for their owners' reasons, and your product catalogue is not part of that calculation.
So the fix is asymmetric, and accepting that is most of the work. You cannot delete the wrong answer. You can only make the right one easier to find, more consistent across sources, more recently confirmed, and harder to contradict. Where a claim is supported by everything a system can check and the stale version survives in one neglected corner, the stale version tends to get outvoted. That is not a guarantee; it is the only lever available, and it happens to be the same lever that helps you in conventional search.
Expect uneven timing. Errors coming from live retrieval can clear within days of the underlying page changing, which feels satisfying and encourages the belief that you fixed it. Errors sitting in a model's training will persist regardless of anything you do until that model is replaced or until retrieval starts overriding it. When something you corrected months ago still shows up, that is usually what you are seeing, and there is no version of persistence that changes it.
The durable move is to stop treating this as an incident and start treating it as maintenance. When a price changes, the checklist that fires should include the feeds, the marketplace listings, the distributor sheet, the brochure and the FAQ, not just the product page. Public product data is a distribution problem rather than a publishing one, and businesses that already run it that way have very little trouble here.
Two years of collective experience is not a long track record, and anyone describing a dependable process for correcting what a model believes is ahead of the evidence, including us. What can be said with reasonable confidence is narrower: businesses whose commercial facts are stated consistently, in one obvious place, in a form a machine can read, and repeated the same way wherever else they appear, get described accurately more often than businesses whose facts are scattered across a decade of pages nobody has revisited. That is not a strategy so much as housekeeping, which is probably why it is so often left undone.
Want this looked at for your own business?
Эта статья описывает подход. Страница услуги показывает объём работ, результаты и стоимость.
Или получить бесплатный аудит