Restaurant menu SEO: how to make every dish you sell findable

Restaurant menu SEO is publishing your menu as readable text on your own website, structured so search engines and AI assistants can identify each dish, its description, its price and its dietary attributes. In practice that means an HTML page rather than a PDF or photograph, organized with real headings, supported by Menu structured data. The purpose is to make every item you sell into a phrase your restaurant can be found for, particularly in dish-level searches, which carry the highest purchase intent in the category.

Poorly, and often not at all. Google can sometimes extract raw text from a PDF but cannot reliably interpret its structure — which line is a dish, which number is a price, which heading is a section, which item is vegetarian. A photographed or fully designed menu is worse, because the words are pixels rather than text. AI assistants hit exactly the same wall. Google's own AI menu tool exists specifically to convert these files into structured fields, which is the clearest evidence that the raw file is not usable on its own.

Yes, and completely rather than partially. A photographed or designed image menu contains no text from a machine's point of view — the dish names are shapes. Search engines can attempt image recognition but will not confidently surface your restaurant for a dish they only think they saw, and they cannot associate that dish with a price, a section or a dietary attribute. The fix is not a higher-resolution image; it is publishing the same content as text.

Put it on its own page on your own domain as real text, with each section as a heading and each dish written out with a description and a price. Add Menu structured data to the page. Point the menu URL field on your Google Business Profile at that page rather than a PDF. Then separately use Google's Edit menu tool to generate a detailed menu on the profile itself from a photo or PDF, so both surfaces carry the information. The website version is the one that reaches AI assistants and other search engines.

Only on Google's own surface. The tool converts an uploaded photo or PDF into a structured menu displayed on your Google Business Profile, which is genuinely useful for Search and Maps. It does not change the PDF on your website, which remains unreadable, and it does not reach ChatGPT, Perplexity or other assistants that read the open web rather than your Google profile. Use it, but publish a proper HTML menu on your own site as the source of truth.

No. Both are simply ways of opening a web address at the table, one by camera and one by tap. Neither is read by a search engine and neither affects rankings. What determines whether your menu is searchable is the destination: an NFC tag pointing at a PDF is exactly as invisible as a QR code pointing at the same PDF. Choose between them on guest experience — NFC suits dim or upscale rooms, QR is free and works on any camera — and make the SEO decision separately, about the page they open.

At minimum, the hasMenu property on your Restaurant schema pointing at the menu page URL. Beyond that, the nested pattern is Menu, then hasMenuSection with MenuSection, then hasMenuItem with MenuItem, each item carrying a name, description and an Offer containing price and priceCurrency. Dietary attributes use suitableForDiet with values such as VeganDiet, VegetarianDiet or GlutenFreeDiet. Schema.org has no native allergen type as of 2026, so specific allergens are typically expressed with additionalProperty. Validate everything in Google's Rich Results Test before publishing.

No. Build dedicated pages only for dishes you can write something substantial and true about — usually your three to six signature items, plus anything with real search demand locally. A page for your side salad has nothing to say that the menu line does not, and sixty near-identical pages that swap one dish name is the thin-content pattern Google has spent years demoting. Everything else belongs on the menu page, which is entirely sufficient for those dishes to be findable.

Yes. Price is one of the strongest filters diners apply, and a menu without prices reads as either expensive or evasive — many people will skip you rather than call to ask. It also removes a field AI assistants rely on when someone asks for somewhere under a certain budget. The usual objection is that prices change, which is really an argument for a menu you can edit in five minutes rather than an argument against publishing them.

Changing the contents of a stable page will not — search engines expect a restaurant menu to change, and a regularly updated page reads as a live business. What causes damage is changing the page's URL without a 301 redirect, deleting seasonal pages that had accumulated value, or leaving the page untouched for years until it describes a restaurant that no longer exists. Keep one permanent URL per menu type and change what sits underneath it freely.

The page itself typically begins being crawled and reflected within two to six weeks. Dish-level searches often move first because there is usually little competition for them — you may be the only restaurant in your area that has actually published a given dish as text. Broader cuisine and category terms take longer and depend on the rest of your local signals. AI assistant accuracy tends to improve as the page is recrawled and corroborated elsewhere, but that timing is not predictable.

Typing the menu as text on a page is something most people can do in whatever system already runs the website — it is ordinary content editing, not development. The structured data is a block of code that needs to be pasted into the page correctly, which is straightforward for anyone comfortable with HTML and awkward for anyone who is not. The realistic split is that you can do the content and may want help with the markup, or with the underlying problem if your site is one nobody at the restaurant can edit at all.