Google Will Read Your Menu Off a Photo. Its Own Page Calls That Experimental.

What the restaurant takes on, if any of it goes wrong, lands at the door rather than on a screen. If a main is transcribed at £14 when the card says £18, the argument arrives at the end of a meal, with a guest holding a screenshot and a manager deciding whether the goodwill is worth four pounds. A parenthetical about nuts or gluten caught in shadow or in the gutter of a folded card may not survive the conversion, and a guest planning an evening around an allergy is reading a list that looks authoritative because it sits inside Google. Google's own Business Profile Help page for the menu editor documents the route as it stands, attaching an experimental label, a separate terms acceptance, an owner review step and tips about the photograph itself, all worth reading before anyone photographs anything.

The help page does not bury this feature's status. It opens with it:

That is Google's own word for its own product, printed above its own instructions. This research did not establish what the label implies about behaviour, availability or output quality, and no forecast about the feature's future is offered here. A restaurant taking this route is not being reckless; it is a documented path inside a Google product. But it accepts that the thing generating its public menu carries the label its supplier chose.

Before any question of how well a model reads a menu, which of the two documented ways a restaurant takes matters. The feature is titled "Create a detailed menu from a menu photo or PDF file with AI":

The constraint owners trip over attaches to the photograph, not to the feature. The page's tips for the photo path say the full menu must fit on one page and be captured on one photo, and warn that blurry or low contrast photos may not work well:

Count the pages of the menu currently sitting on the pass. Most independent restaurant menus are not one page: starters and mains occupy one side, desserts and coffee another, and the wine list lives on a separate card. A menu like that does not match what the tips describe for a photograph. The PDF is the other input the same page documents, and at the ingest step the instruction is to select Photos of menu, then Select photos, and upload either; but the page states no page limit for the PDF path and does not say a multi-page PDF is accepted, so whether that route lifts the one-page constraint was not established in this research. The tips bear on design as well as length: a menu printed in pale grey on cream is the low-contrast case they warn about, however many pages it runs to.

What makes this more than an inconvenience is the failure it invites. A menu that does not fit one page gets photographed anyway, because the camera is in hand, and what reaches the profile is a partial menu presented as the menu. The desserts simply do not exist, and a guest booking a birthday reads a restaurant that appears not to do puddings. Nothing on the page says the model discards what it cannot see; what it says is that a photographed menu must fit on one page, and it leaves an owner whose menu does not to work out for themselves what the PDF path will take.

The route asks for something separate from the terms under which the Business Profile is already held:

Whoever accepts is agreeing on the business's behalf, which is a question of authority: in an independent restaurant the person holding access to the profile is often a supervisor rather than the person who signs contracts. The page does not address who within a business may accept these terms. And this is a distinct instrument, additional to whatever was accepted when the profile was claimed: a restaurant that has read its Business Profile terms has not thereby read these.

This article was not read at source, and does not characterise, what those terms say about the material supplied to the model or about the generated output. The point that survives is narrower: the route requires a second agreement, named on the same page as the instructions, and an owner is entitled to read a document before agreeing to it.

The published sequence does not send the model's output straight to the profile. It routes it through the restaurant:

Read it as a safeguard, because that is what it is: nothing is published behind the owner's back, and edits are possible afterwards. It is also an allocation of responsibility. Google generates the menu; the restaurant certifies it. Every price, dish name and dietary note becomes the restaurant's own assertion the moment somebody selects Publish.

The word "review" is carrying a great deal of weight there. Reviewing a hundred-line menu properly means reading each item against the printed card, checking every price digit by digit and confirming that each allergen note survived it. That is a line-by-line reading done attentively and a scroll done the way a busy person scrolls a screen that mostly looks right, and the restaurants most drawn to a photo shortcut have least time to audit it — a statement about how the step gets used under pressure, not about how well the model reads a menu.

The same page carries a condition that sits ahead of everything else — the opening line of the section on how the menu editor works, printed before photographs or AI are mentioned anywhere:

Read where it stands, "this feature" is the menu editor: the page warns that a profile whose menu is provided by the Business Profile API may not have it in Business Profile or Google Search, and does not say which of the editor's routes that removes. This research did not locate why Google draws the line there.

What survives is narrower than a rule about photographs and more useful for it: where a menu is provided through the Business Profile API, Google's own page contemplates that the in-profile editor may not be present. The page says nothing about a menu published on the restaurant's own website, which reaches Google by no such instrument. The question worth asking is not whether the model is good enough but why Google is being asked to construct a menu at all — the same question that sits underneath which ordering provider a profile prefers, covered in the companion article on naming a preferred ordering provider and removing one the restaurant did not choose.

Set the two routes side by side and the difference is not that one uses AI; both can start from a photograph of the printed card. The difference is where the menu ends up living.

On the photo route the menu's digital form is generated inside the profile, checked once, and thereafter maintained by hand in Google's editor. Change a price on Monday and the printed card changes, the profile does not, and nothing connects them but somebody remembering.

On the structured route the scan produces the restaurant's own data: sections, dishes, descriptions, prices and dietary tags as editable fields the restaurant keeps. A price is edited once in the field that owns it, and every page and QR link that renders the menu changes with it. An allergen note is a labelled attribute carried wherever the menu appears. How far a guest has to travel to reach allergen information is its own measurable problem, set out in the companion article on counting the clicks from the order button to the allergen list.

A restaurant that publishes a structured menu from its own site is not opting out of Google; it is deciding what Google is given to work with. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and a live menu is what the site is built around. Starter is £19/month, excluding VAT, and the pricing page states the same floor for every tier:

The menu is maintained as sections, dishes, prices and dietary tags, edited once and updated across every page instantly, with one QR-ready link for table cards and windows. Direct reservations at 0% TableSpark commission are on Growth at £39/month, excluding VAT, and online ordering at 0% TableSpark commission on Full at £69/month, excluding VAT, with Stripe's standard card-processing fees applying to online payments.

The search-readiness work is part of the site, not a specialist engagement bolted on afterwards. Every plan carries crawlable restaurant pages and menus, canonical URLs, sitemaps, robots controls, schema and managed search-verification setup; the pricing table lists "Restaurant & LocalBusiness schema crawlable structured restaurant data" on all three tiers. Indexing and ranking remain decisions for Google. What a restaurant controls is whether an accurate, structured, machine-readable menu exists under its own name — the part the photo route exists to substitute for. Keeping a profile's exceptional hours and a website's hours in step is the same discipline in another field, covered in the article on special hours living in two places.

This research did not locate a documented case of this feature misreading a restaurant's price, dish name or allergen note. The risk described above is argued from what Google publishes — the experimental label, the tips putting a single-page and single-photo constraint on the photo path, the image-quality warning and the separate terms — and from the accuracy check being placed on the restaurant. No error rate is published and none is claimed here. Nor was it established whether the PDF path accepts a menu of several pages: the page attaches the one-page constraint to the photograph and states no page limit for a PDF, which is silence rather than permission.

Nor does anything here establish that a structured menu published from a restaurant's own site prevents Google from offering the photo route or removes it from a profile. The strongest inference in this article is that a restaurant is safer maintaining its menu as structured fields it controls than as a one-off transcription of a photograph, and the cited evidence supports only that Google labels the photo route experimental, publishes tips requiring a photographed menu to fit on one page, requires an additional terms acceptance, places the accuracy check on the owner, and lets an owner select a preferred menu source where Google finds several; it establishes no failure rate and no effect of a structured menu on the feature's availability to a particular restaurant.

Open the Business Profile on a desktop and read the menu as a guest reads it. Check every price against the card in service tonight and every dietary note against what the kitchen would say on the phone. Treat a menu that came from a photograph as unverified until it has been read line by line: the published sequence makes that reading the restaurant's own certification.

Then do the half of the job publishing alone does not do. A structured menu on the restaurant's own site supplies a source Google can read: the same help page says Google may transcribe menu data from a business website, and that customers can add a menu photo themselves. Where several sources exist, the profile shows the one the owner selects:

Publishing is the half in the restaurant's hands; selecting is the half in Google's interface. Do the first without the second and a good menu sits on the restaurant's site while a different one sits on the panel guests read, the failure set out in the article on the menu on a Google listing not being the one the restaurant publishes. Do both and there is one menu to maintain, with the profile pointed at it.