The query you are already losing
Someone is deciding where to eat tonight and they search your restaurant's name plus the word "menu". They are not browsing. They have chosen you provisionally and are checking whether you serve something they want at a price they expected.
That is about as close to the till as an organic search gets. And the three most common things it lands on are all bad answers:
- A PDF that opens as a full-page document on a phone and has to be pinched and dragged.
- A photograph of a printed menu, which contains no text at all as far as a search engine is concerned.
- A third-party delivery listing, which shows a different menu at different prices and takes a commission.
The fix is not clever. It is a menu that exists as a normal web page.
What a search engine actually needs
Nothing exotic. The requirements are ordinary and a PDF fails most of them.
| Requirement | HTML menu page | PDF menu | Photo of a menu |
|---|---|---|---|
| Text a crawler can read | Yes | Sometimes, badly | No |
| Headings that describe sections | Yes | No structural meaning | No |
| Readable on a phone without zooming | Yes | No | No |
| Can carry structured data | Yes | No | No |
| Readable by a screen reader | Yes | Rarely | No |
| Updatable without a new file | Yes | No | No |
The screen reader row is worth pausing on. It is the same property that makes a page indexable -- machine-readable text in a meaningful order. Accessibility and search visibility are not two projects; they are one property viewed from two sides. QR menu accessibility takes the other view of it.
Structured data, plainly
Structured data is a small machine-readable block on the page that states what the page is about in a standard vocabulary. For a restaurant menu the relevant types describe the venue and the menu itself: the restaurant's name and address, the menu, its sections, and the items in them.
It does not make you rank. What it does is remove ambiguity about what the page is, which matters when the page is a list of dish names that could otherwise be almost anything.
Guest menus published through myQRMenu carry Restaurant and Menu structured data generated from the menu itself, so it cannot describe a dish or a price the page is not showing.
The Google Business Profile menu link
Your Business Profile has a dedicated menu field, and it is one of the few fields with a direct line to a purchase decision. It appears as a menu button on the profile, which is often the first surface a local searcher touches.
- Point it at your own live menu page, not at a PDF and not at a delivery marketplace.
- Use the canonical menu URL, so the link and the indexed page are the same page.
- Keep the profile's category specific rather than generic, since the category informs which queries you surface for at all.
- Re-check the link after any menu restructure. A dead menu button is worse than an absent one.
If your menu changes frequently, this is exactly the case for pointing at a live page rather than uploading anything: the profile keeps showing the current menu without anyone remembering to re-upload it.
Dish-level queries, and why they are worth having
Beyond the branded query there is a long tail nobody targets deliberately: people looking for a specific dish near them. Someone wanting a particular regional dish in a city they are visiting is searching for the dish, not for a restaurant category.
A menu page with real dish names in real text is eligible for those queries automatically. A PDF is not. This is not a strategy so much as a side effect of doing the first thing correctly -- which is why it is rarely worth building content specifically for it.
One caveat: it only works if the dish names are the words people actually use. A poetic menu that calls a dish something invented will rank for the invented name, which nobody searches. If you run a multilingual menu, keeping the original dish name visible helps here too -- see multilingual restaurant menus.
The failure mode: a menu page with nothing on it
There is one way this goes wrong, and it is common enough to name.
A venue creates a menu page, adds three items, and stops. The page exists, gets crawled, and offers a search engine almost nothing. Repeated across many venues on one platform, it teaches the crawler that pages of that shape are not worth fetching, which affects the ones that are complete.
Our answer is a gate rather than a warning: a menu with no items is marked no-index and left out of its own sitemap. It is better for a page to be invisible than to be indexed as evidence that the site publishes empty pages. An item count is a crude proxy for content depth, but it is a proxy that fails in the safe direction.
The practical version for an operator: publish the whole menu or do not publish the page. A half-entered menu is not a partial win.
Assistants, and what they can read
A growing share of "where should we eat" questions get asked of an assistant rather than typed into a search box. The assistant answers from pages it can fetch and parse.
The requirements are, again, unexotic: text rather than images, a page that renders without an app, and a crawler that is not blocked from fetching it. A menu locked inside a JavaScript app that returns nothing to a plain fetch is invisible to most of them, and so is a PDF.
One correction worth making, because it circulates a lot: publishing an `llms.txt` file does not affect Google rankings. Google does not read it. It is useful for the assistants that do, and it is not a search tactic.
If your menu lives inside someone else's app
Many venues have their menu only inside a delivery marketplace or an ordering platform. That menu ranks -- for the marketplace.
It is an entirely reasonable channel to be in. It is a poor place for your menu to exist exclusively, for three reasons: the prices there are usually inflated to cover commission, the branded query resolves to a page that is not yours, and you cannot change any of it.
Keeping your own menu page as the canonical version does not mean leaving the marketplace. It means the query that names your restaurant lands somewhere you control. The complete guide covers where this sits in the wider set of decisions.