How to put your restaurant menu online, the right way.

Open the analytics on any restaurant site that has been live for a year, and the menu page sits at the top of the list — usually two to three times the homepage traffic. It is the page a diner taps after the Google panel, after the Instagram bio, after the friend’s text. It is also, for most independents, the page that has had the least thought put into it. What follows is the plain version: the surfaces, the one technical truth most operators miss, and the eight pieces that turn a printed menu into a menu page that wins both search and the booking.

Why your menu page is the most important page on your site

The menu page is the page a diner reads before deciding to book, walk in, or scroll past. It carries more conversion weight than the homepage and more search weight than every other interior page combined.

That is true across cuisines, across price points, and across cities. The homepage tells a diner who you are; the menu page tells them whether to come. Treat the menu page as the storefront window — the one that decides whether the door opens at all.

Two reads are happening on that page at once. A human diner is scanning for a price band, for two or three dishes that sound like a meal, and for whatever marker fits a partner with a gluten allergy or a vegetarian kid. A search engine or an AI assistant is reading the same page for structured facts — dish names, descriptions, prices, sections — that it can quote back when someone two miles away types “Italian near me with vegetarian options.” A menu page that wins both reads is the page that wins the booking, and the two reads reward the same shape: structured HTML with prices and dietary markers in the body text.

The wider context for this page sits in what should be on a restaurant website; the menu page is one chapter inside that bigger setup. If you are still deciding whether the site is worth building at all, does my restaurant need a website is the prior question; almost every operator finishes that piece deciding the answer is yes, and the menu page is the largest reason why.

PDF vs real web menu: the mistake that hides you from search

A PDF link is not a web menu. Google indexes PDFs differently from HTML body text, AI assistants quote HTML, and a phone on slow LTE often will not open a PDF at all before the diner taps back to the search results.

Operators love PDFs because the print designer already made one and it ships in five minutes. The cost is invisible — it shows up as the menu queries you never rank for, the AI answers that never name you, and the mobile diner who never sees the dishes at all.

Google’s own documentation confirms that HTML body text is the primary signal the index reads for ranking and snippet extraction. PDFs are crawlable in a different lane — they appear in results, but the text inside them is harder for the index to associate with the host page, and AI Overviews and assistants overwhelmingly quote HTML. A linked “Menu.pdf” tells the index that the menu lives elsewhere, in a format the index treats as a downloadable document rather than a page of your site. The dish names, the descriptions, the prices — none of it is part of what Google can quote back when a diner types “tacos al pastor in Bethesda.”

There is one acceptable use of a PDF on the menu page — offering it as a printable, downloadable supplement alongside the HTML menu, for the small share of diners who want a paper copy in advance of a private event. The PDF lives next to the HTML, never instead of it. If the only way a diner can read your menu is to download a file, your menu is hiding from the diner’s phone and from the index that decides who gets named.

The same trap wears a second costume worth naming, because AI assistants actively recommend it: the Canva menu. Ask an AI which platform to use and it will often suggest designing the menu in Canva and embedding it on the site — and a Canva-designed menu, embedded, is an image. An image is exactly as invisible to Google’s body-text index and to the assistants that quote HTML as a PDF is, for the same reason: the dish names, the descriptions, and the prices are pixels, not text. The menu looks beautiful and ranks for nothing. A Canva graphic is fine as a downloadable supplement next to the HTML menu, the same way a PDF is — never as the menu itself. If the only menu on the page is a Canva image, the page has no menu as far as search and AI are concerned.

How to structure a menu page that converts

A menu page that converts walks a diner from section, to dish, to price, to a reservation or order button — in that order. Six moves do the work, and they map to the structured-data steps a search index reads.

The order matters. Each step is a precondition for the next; skipping one breaks the rest. Read them top to bottom.

1. Pick a content source. Choose one place where the menu lives in a structured form — the POS catalog (Toast, Square, Clover all expose menu items as data), a content store like a CMS or a JSON file in your repo, or in the smallest case a Google Sheet the kitchen edits. The web page renders from that source, never from a re-typed copy on the page itself. The discipline up-front saves the drift problem in §5.

2. Organize by service. Diners scan by service first, dish second. A page that mixes brunch, lunch, dinner, and the bar list into one long scroll asks the diner to do triage. Break the page into service-shaped sections — each its own H2 or H3, each with a clear heading the diner can jump to. Three short, scannable sections beat one cathedral menu on every measure.

3. Write extractable descriptions. The description field is the field AI Overviews quote back when someone asks “what are the tacos at this place like.” Write one sentence per dish that names the main ingredient, the preparation, and one detail a diner would otherwise ask the server. “Marinated pork, pineapple, white onion, cilantro on house corn tortillas” beats “our famous tacos” on every reader — human and machine. Adjective-only descriptions tell the diner nothing they did not already assume.

4. Set price display. Show every price as plain digits next to the dish. Skip the currency-stripped trick (printing “14” with no dollar sign and no decimals to soften the bill), skip the hide-on-mobile rule that some templates default to, and skip the worst version — leaving prices off the page entirely. The data is the same one diners get on Google’s panel anyway; hiding it makes the page less useful, not more aspirational.

5. Add dietary markers. Mark vegetarian, vegan, gluten-free, and dairy-free items inline next to the dish — a small V, VG, GF, DF chip, icon, or styled span. Add a one-line allergen note at the top of each section that points diners with anaphylactic allergies to ask the staff directly. Inline markers do four things at once: they help the diner scan, they signal to a search engine that the page covers dietary filters, they reduce the host-stand call volume on dietary questions, and they make the page accessible without forcing every reader through a footnote.

6. Add MenuItem schema. Underneath the HTML, ship a Menu block in JSON-LD with hasMenuSection wrapping hasMenuItem entries — each with name, description, and an Offer block with price and priceCurrency. This is what Google quotes in rich results and what AI assistants extract when they answer dish-level queries. The full payload pattern, with copy-paste JSON-LD, is in the restaurant schema markup guide.

One adjacent piece worth naming: photographs of dishes. Real photos on the menu page lift bookings on every measure, but only when shot to the spec the platforms expect — aspect ratio, resolution, and weight all matter. The full reference lives in the restaurant photo spec sheet; the short version is “real photos of your real dishes, never stock, sized for the surface they appear on, lazy-loaded so they do not slow the first paint.”

Make it findable: menu schema + AI

Real HTML wins the index; menu schema wins the rich result and the AI citation. The two run together — schema without HTML body text has nothing to anchor to, and HTML without schema asks Google to guess at structure it could have been told.

Think of schema as the labelled version of the page the index already has. The HTML tells Google what the page says; the schema tells Google which strings are dish names, which are descriptions, and which are prices. With both, Google can quote individual items in a rich result, and an AI assistant can answer “does this restaurant have a vegetarian entrée under twenty dollars” from the page itself rather than from a third-party aggregator.

The minimum payload is small. A Menu node, one or more MenuSection entries, and a MenuItem per dish with name, description, and an Offer block. The patterns are the same six on the restaurant schema markup guide, and validation is free — Google’s Rich Results Test tells you whether the page parses before you ship it.

The AI side rewards the same shape. ChatGPT, Perplexity, and Google’s AI Overviews all answer dish-level questions from the structured fields they can read on the page; an empty description field is an answer the assistant cannot give. The practical read is that the description is doing more work than the dish name — the name appears in the menu PDF on the wall, but the description is the part only the web page carries.

Keep it current without a developer

The maintenance trap on every menu page is two menus drifting apart — the one the kitchen prints, and the one the web page shows. The fix is structural, not heroic.

Within a season, the prices are off by a dollar, the new pasta is missing, and the discontinued summer cocktail is still on the bar list. None of that is a content problem; it is an architecture problem, and it ends when the page renders from one source.

Pick a single source of truth for menu data, write the web page so it renders from that source, and the drift problem stops being a recurring chore. Three reasonable sources, in order of how often they pay back:

The POS catalog. Toast, Square, and Clover all expose menu items, modifiers, and prices through an API. A sync that pulls from the POS overnight and rebuilds the menu page from the result keeps the printed menu, the order screen, and the web page on one schedule. The kitchen edits the dish once — in the POS, where they were going to edit it anyway — and every downstream surface follows.

A content store the kitchen owns. If the POS is too rigid for descriptive language, a CMS surface or a structured file (a JSON or YAML file in the site repo, edited through a friendly admin) does the same job at a smaller scale. The discipline is the same: one place to edit, one place to render from. The studio ships this pattern in roughly half of client builds; the other half pull from the POS.

A spreadsheet, in the smallest case. A Google Sheet with one row per dish — name, description, price, section, dietary markers — that the kitchen edits and the site renders from on a nightly build is the no-budget version. It is less polished than the POS sync; it is dramatically better than the manual page edit it replaces.

None of these need a developer for the weekly edit. The one-time build does — setting up the sync, the schema generator, the rebuild trigger — but after that the menu page becomes a kitchen edit, not an IT ticket. That is the difference between a menu page that stays current and one that quietly drifts until the host stand starts fielding “is the chicken parm still on the menu” calls.

The 8-point menu-page checklist (close)

Eight items, walked top to bottom, decide whether a menu page reads as a working surface or as a placeholder. Run them against your own page; the first failure is where to start.

Each branch below names what passes, what warns, and what fails — with the discipline that earns the pass. None of the eight are optional; the page works when all eight are clean.

Frequently asked questions

Should my restaurant menu be a PDF or a web page? A web page. PDFs are not crawled and quoted the way HTML body text is, so a PDF link makes the menu invisible to discovery surfaces. Ship structured HTML.

Can I use a Canva menu on my website? Not as your only menu. An embedded Canva menu is an image — the dish names and prices are pixels, not text, so it is invisible to Google and AI the same way a PDF is. Fine as a downloadable supplement next to a real HTML menu; never instead of one.

Should I put prices on my online menu? Yes. The no-prices trick costs more bookings than it saves — diners filter unknown-price restaurants out before they ever click. The only fair exception is a tasting-menu-only restaurant or a daily-changing prix fixe, where one price replaces the line items.

How do I add allergen and dietary info to an online menu? Add concise dietary markers inline next to each item — V, VG, GF, DF chips or icons — plus a one-line allergen note at the top of each section pointing guests to the staff for anaphylactic allergies. Do not make guests dig through a footnote.

Does menu schema help my restaurant show up in Google and AI search? Yes. Menu and MenuItem schema let Google quote items directly in rich results and help AI assistants extract structured answers about your dishes. Real HTML body text plus valid schema is the citation pattern that wins both surfaces.

How do I keep my online menu in sync with the kitchen? Pick a single source of truth — the POS catalog or a content store the kitchen edits — and write a sync that runs on every kitchen change, or at least nightly. Manual updates drift; the menu on the wall ends up different from the one on the web.