When an AI Overview Can Answer "What's on the Menu" From Somewhere Else

That changes what an out-of-date menu costs. While a guest clicked through, any error sat on the restaurant's own page, for the restaurant to find. When the answer is written for them, that page may not be in the transaction at all. A dish withdrawn in March, a set lunch repriced in April, a nut warning that survives on the printed card but not in a copy typed out two winters ago, each restated as fact. The first the kitchen hears of it is at the door, when a table of six arrives quoting a price no one has charged since the spring, entirely certain, because the answer they read looked authoritative and carried no author.

This is not speculation. Google published an account of the mechanism on 30 May 2024, under Elizabeth Reid's byline as VP of Search, after a week in which, as the post puts it, people on social media had shared "some odd and erroneous overviews (along with a very large number of faked screenshots)". Of the faked screenshots implying dangerous results, Google writes, "Those AI Overviews never appeared", while also confirming that "some odd, inaccurate or unhelpful AI Overviews certainly did show up". The mechanism it sets out next is worth reading in full:

Read as an operating constraint rather than a reassurance, this says something specific about restaurants. The generated answer is generally not invented: it's built from whatever pages the ranking systems treat as the best available material on the question. If the best available material about a restaurant's dishes and prices isn't the restaurant's own page, the answer gets built out of whatever is. Google's own qualifier stays attached: the same post records that "In a small number of cases, we have seen AI Overviews misinterpret language on webpages and present inaccurate information." Being the best available material is the part an owner governs, not a guarantee that every answer comes out right.

The post then names the failure mode that matters here, a category of question where the material is simply too thin:

Google's example, an absurd query about eating rocks, shows the consequence in concrete terms:

The word doing the work is "faithfully": the system did not malfunction. The post names two things together: a data void, and satirical content on the question that had also been republished on a geological software provider’s website. What the overview found was the only material on offer, and it used it as designed. The result was wrong because the material was: a failure of input rather than of intent.

It has to be said plainly what the cited post does not cover. It discusses an unrelated, nonsensical query and does not mention restaurants, menus, dishes or prices; no instance of an AI Overview sourcing a restaurant's menu from a directory was located in this research, and none is asserted here.

The argument here is narrower and more useful than that. Google has documented a mechanism: thin material on a topic produces an answer built from whatever exists, and the company states that overviews are built from top web results. A restaurant whose menu online is a PDF, a photograph of a printed card, or a page of eleven words and a phone number has made its own menu a thin topic. That's a plausible consequence of a documented mechanism rather than a reported incident, and the remedy is the same either way.

Thin isn't a verdict on the food or the design. It describes how much readable, current, structured text about the restaurant's dishes sits at an address the restaurant controls, and four patterns account for most of it.

The menu is a PDF: immaculate, prints beautifully, and the dish names and prices inside it are locked in a document rather than page text. The menu is an image, a photograph or the designer's artwork exported, and the words on it are pixels. The menu is drawn in by a script after the page loads, so a crawler may find a container and no dishes. Or the page genuinely is thin: a heading, a line inviting the reader to call, and a file from last summer.

A fifth pattern isn't anyone's fault: a site gets rebuilt, or a theme gets swapped, and the pages carrying the detail don't come across intact. What survives a template change is set out in the companion article on what a free template refresh actually deletes.

A thin menu page doesn't leave a vacuum. Delivery marketplaces, booking directories, local listing sites and aggregators that scrape other aggregators may all carry a version of it, most created without anyone at the restaurant typing a word, and most carrying no visible date.

Those copies freeze at the moment they're made and won't track a seasonal change, a supplier switch, a withdrawn dish or a reprice. What deferring a reprice costs is a margin question of its own, worked through in the companion article on what waiting to reprice the menu costs. A second cost follows: when the restaurant moves a price, the copies stay put, and if they're the substantial material, the answer a guest reads keeps quoting the old figure.

A menu answered from somewhere else isn't an abstract loss of visibility. It arrives in person: a price dispute at the end of a meal, where the guest holds a screenshot and the manager decides what goodwill is worth; a dietary conversation held from a list missing the change the kitchen made over summer, far more serious than four pounds; a booking that never happens because the answer described a menu the restaurant stopped serving.

None of these arrives as an attribution: no report names the source a generated answer was built from. What is readable is narrower, and still worth reading. Since 31 August 2026, as the companion article on what Search Console's AI report actually shows sets out from Google's own announcement, the generative-AI performance reports have covered all websites worldwide, recording how often a site's URLs appeared in AI features and which pages those were. The announcement doesn't list clicks, click-through rate or the question asked, an absence Google doesn't state as an exclusion; it points to its help-centre documentation for the full data available and says it may add metrics over time. A restaurant finding none of its own pages there knows only that its pages aren't being used: an answer may be built from something else, or no AI answer about it may be appearing at all. Attribution of any single wrong answer stays silent by construction, which is why the menu is worth fixing before there's evidence of the failure.

The remedy follows from the mechanism: if an answer is built from the best available material on a topic, the work is putting that material at an address the restaurant owns, in a form a machine can read, kept current as routine rather than as a project.

In practice that means four things. The dishes and prices are page text, not a picture or a file. The menu is marked up as restaurant data, not because markup buys entry to an AI answer (it doesn't), but because named fields make the dishes and prices unambiguous to anything reading the page. The page is reachable: linked from the site, present in the sitemap, not blocked. And a price change happens once and shows up everywhere the menu renders, because a menu needing four edits across four systems will be current in one by August.

None of that is a ticket, and it shouldn't be sold as one. Google has stated plainly that no new machine-readable file, no AI text file and no special schema.org structured data is required to appear in these features, the subject of the companion article on why no markup file gets a restaurant into an AI Overview. Readable and current is a different question from eligible.

No promise of a ranking or of indexing follows from any of that: what it does is remove the restaurant's own page as the reason a thin topic exists.

The reason so many independent menus end up thin is not indifference. Doing the above properly has usually meant a designer for the page, a developer for the markup, a technician for the sitemap and search verification, and the owner's evenings afterwards — or a PDF, one export away. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and it exists to make the structured version the easy one.

The menu is held as sections, dishes, descriptions, prices and dietary tags — editable fields, not a document — and renders as real page text, with one QR-ready link for table cards and windows. A dish or a price is changed once and updates across every page instantly, editing is unlimited on every plan, and the pricing page states one floor for every tier: "Every plan starts with AI website setup, a live QR-ready menu, guest records and managed search readiness." Starter is £19 a month, excluding VAT, for one restaurant that needs to launch direct and stay easy to update. Bookings against the restaurant's own tables and floor plan sit on Growth at £39 a month, excluding VAT, and direct online ordering at 0% TableSpark commission on Full at £69 a month, excluding VAT, with Stripe's standard card-processing fees on online payments.

The search-readiness half is bundled rather than sold separately, in the published words of the product's own how-it-works page: "A live link is not the same as an indexed one. Crawlable restaurant content, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema and managed search-verification setup. Indexing and ranking remain decisions for Google." That last line is the honest boundary. What a restaurant governs is whether a current, machine-readable account of its own menu exists under its own name; whether a generated answer is built from it is decided elsewhere, and no such promise is made here.

Four limits are worth stating. No case of an AI Overview sourcing a restaurant's menu from a directory or aggregator instead of the restaurant's own page was located in this research. The adjacent case is documented rather than missing: the companion article on the menu on Google that may not be the one you publish sets out how a listing's Menu tab can be built from an old PDF, a guest's photograph or a stale third-party copy. No published rate at which generated answers misstate a restaurant's dishes or prices was located, and none is claimed. Nothing here establishes that a structured, crawlable menu page changes which sources a generated answer draws on in any individual case. And no rate at which a generated answer ends a session without a click was located; the cited post points the other way, describing overviews as a jumping off point to web content, so the opening paragraph puts it as a possibility, not a norm.

The strongest inference in this article is that a restaurant whose own menu is thin, locked in a file, or absent as page text has made its menu the kind of topic Google's own post describes as a data void, and has thereby left an answer about its dishes and prices to be built from whatever else exists; the cited post supports only the general mechanism and the statement that overviews are built from top web results, illustrated by an unrelated query, and it neither discusses restaurant menus nor reports any restaurant-specific failure.

Open the restaurant's menu page on a phone and ask three questions. Can the dish names and prices be selected as text, or are they a picture? Does the page carry the current menu, including the changes made since Easter? And if that page were the only thing a machine could read about the food, would it amount to a substantial account, or eleven words and a download?

Then open Search Console's generative-AI performance view: does the menu page appear among the pages listed for AI features at all? A zero there isn't a verdict on the food. It's a prompt to check whether the page can be read.

Finally, search the restaurant's own name with the word "menu" and read what comes back above the links. If the dishes described aren't the ones being served tonight, that's the whole argument in one screen, and the fix isn't to complain about the answer. It's to become the source it has to use.