We updated the menu. Why do Google and AI answers still show the old prices?
Because there is no single menu. There is a menu you control, several you do not, and generated answers assembled from whichever of them a system happened to read. Before correcting anything, check that the two prices you are comparing describe the same thing.
A decision guide, not research findings. We have not audited restaurants, collected menu data, or measured correction times. The framework and classifications below are ours, built from platform documentation and reasoning. Where a study would be needed to make a claim, we say so instead of making it.
The short answer
Updating one menu does not update every representation of it, and a disagreement between two prices is not automatically an error.
A correct delivery price and a correct dine-in price can differ by several pounds and both be right. An archived lunch offer is not wrong for failing to match the dinner menu. Before you treat a number as stale, establish that the two things you are comparing are actually comparable. Most of the frustration in this problem comes from skipping that step.
Where the information comes from
Google states plainly that a Business Profile is assembled from several streams, not just the one you edit.
"Information in profiles is compiled from a variety of sources including publicly-available information such as crawled web content from a business' official website, as well as users who contribute factual information (such as addresses and phone numbers) and content (such as photos and reviews)."
Google's menu tooling adds more places to look rather than one field to fix. There are menu links, a preferred menu source used when alternatives exist, and transcription of menus from websites. So "the menu on Google" can mean at least three different mechanisms, and which one is showing determines who can change it.
These are Google's documents and they describe Google. Do not use them to assert that ChatGPT, Perplexity or any other assistant updates through the same pipeline, because none of them has published one. For each answer you find, inspect that answer and its cited sources on their own terms.
A price needs seven fields before it means anything
This is the part that turns an argument into an audit. A menu price is only a fact once it carries enough identity to be checked.
| Field | Why it changes the answer |
|---|---|
| Business and branch | Two branches of one restaurant can price differently and often do |
| Item | Named dishes drift. "The burger" is not a stable identifier |
| Portion | Half, full, sharing, set menu |
| Channel | Dine-in, takeaway, delivery platform, direct ordering. These legitimately differ |
| Currency | Obvious, and still the cause of confident wrong conclusions in multi-market work |
| Tax and surcharge context | Inclusive or exclusive, service charge, weekend surcharge |
| Effective date | When it started applying, and when it stopped |
Without these, a "wrong price rate" is not a measurement. It is a count of things that looked different, which is not the same claim and does not support a correction plan.
Comparability before correction
An illustration. The amounts are invented to show the classification, not observed from any restaurant.
| What you observe | How it compares | Classification |
|---|---|---|
| Owner confirms $18 dine-in, website says $18 | Same branch, item, portion, channel and date | Consistent |
| Delivery platform lists $21 | Different channel | Not directly comparable. Ask the owner before calling it an error |
| Search shows $16 from a menu dated last year | Same item and channel, owner confirms it was replaced | Potentially stale. Now find the source and its timing |
| An assistant says $18 but links to a different restaurant | The number happens to match | Attribution failure. Not evidence of correctness |
| An assistant declines to give a price and links to the current menu | No numeric claim made | Abstention. Not a wrong price, and arguably the correct behaviour |
The fourth and fifth rows are the ones people score wrongly. A right number attached to the wrong source is a failure, and a refusal to answer is not. Any tool counting "accuracy" without separating these is producing a number you cannot act on.
Who controls which source
Sorting sources by who can actually change them turns a complaint into a task list.
Your own website menu, its structured data, the menu link on your profile, and your direct ordering page. Fix these first because they are free and immediate.
Business Profile fields, delivery platform listings, and directory entries. These have owner channels and defined turnaround.
Photos of old menus, reviews quoting old prices, user edits. You can report, not delete, and a photographed 2023 menu board is legitimately what someone saw.
What a generated answer says. You can change what it reads. You cannot edit the answer, and anyone promising otherwise is describing something that does not exist.
That last box is the honest limit of this work. The lever is source quality and source agreement. The output is probabilistic.
What can honestly be measured
Four metrics with denominators you can defend.
- Comparable stale facts divided by comparable verifiable facts. Note that both halves exclude anything you could not establish comparability for.
- Claims with supporting citations divided by generated factual claims inspected. A cited source that does not contain the number is a distinct failure worth counting separately.
- The interval between the last observation showing stale data and the first showing correct data. This is an interval, not a propagation time.
- Recurrence. Whether a later check reverts. This is the metric that decides whether correction is a project or a subscription.
If a price is wrong on day two and right on day seven, you have observed that the change happened somewhere in that window. You have not established that Google takes five days, because you do not know when it actually changed, only when you happened to look. Keep the time the owner changed a source and the time a researcher observed the effect in separate columns.
The audit protocol, if you run it properly
This is the design we would use. We have not run it.
- Get owner-confirmed current facts for a frozen set of items. Ten per restaurant, chosen by a stated rule such as five staples plus five recently changed.
- Note that such a set is deliberately enriched for change, so whatever rate it produces is not a representative menu-error rate for anyone. Say that in the output.
- Inspect four source types per item: the official menu, the Business Profile menu where it exists, one relevant ordering platform, and one specified answer surface.
- Repeat on three scheduled dates. Three restaurants, ten items, four sources, three dates is up to 360 observations, and unavailable sources reduce the valid denominator rather than being filled in.
- For generated answers, fix the prompt wording per item and record platform, mode, visible location and language settings, capture time, the displayed answer, the cited URL, and whether that citation actually supports the price.
- Classify every capture as matching, confirmed stale, different context, unsupported claim, abstained, missing or unresolved.
- Publish source-level and restaurant-level summaries separately, so one complicated restaurant cannot silently drive the headline.
Repeated observations of the same restaurant are not independent samples of restaurants. Three restaurants observed thirty times is still three restaurants.
One outcome worth planning for: if every comparable price matches, there is no information-quality problem here worth selling a retainer against. A null result is a real finding and we would publish it.
Where to stop
Do not extend this to allergens or dietary suitability. Those require direct confirmation from the restaurant and must never be inferred from a generated answer or a third-party listing. The cost of being wrong is not a bad review.
Two more boundaries. Do not publish a restaurant's apparent mistake before the owner has verified it, because an undated online menu is not ground truth. And in a research phase, inspect only. Editing listings or filing corrections is an intervention and belongs in a separate, permissioned stage.
Limits
- This is a guide. No restaurants were audited, no menus collected, no correction times measured, and every amount above is invented to illustrate a classification.
- The seven-field identity model and the comparability classifications are ours. They are reasoning tools, not anything a platform publishes or validates.
- Google's documentation describes Google. The behaviour of assistants that are not Google is not covered by it and we have not tested them here.
- We have no evidence about how often menu prices are actually stale, because nobody has published it and we have not measured it.
- Platform documentation checked 23 September 2026. These systems change.
The wider version of this problem, where the facts about a business disagree across every surface a machine reads, is the thing we actually check, and if you want to test what assistants currently say about you, the 60-second field test is a reasonable starting point.
See what is limiting your visibility.
Send the URL and tell us what you sell. You will get the first issue worth fixing, with the reason behind it.
Request an audit ↗Free · No call required