Most restaurant websites treat the menu as a document to be handed over rather than a page to be found. It gets exported as a PDF, parked behind a link that says View Menu, and then left alone for a year. That one decision quietly removes the most searched part of the site from the index.
The menu page is usually the second most valuable page a restaurant owns, behind the booking page. People search for dishes, for dietary options, for prices and for what is on tonight. If none of that exists as readable text on a page you control, the answer gets pulled from a delivery platform, an aggregator or a review site instead, and the click goes with it. The searches that lead to a booking are rarely the venue’s own name, which is the ground covered in what diners search before booking a table.
Why a PDF menu costs you the search
A PDF is not a web page. Even where a search engine can extract some text from it, the file is a dead end for almost everything that makes a page rank and convert.
- It has no title tag, no meta description and no heading structure that a crawler can use.
- It cannot carry internal links back to your booking page, your location pages or your other menus.
- It usually opens as a download on a phone, pinch to zoom, which is a poor experience and an accessibility failure.
- It cannot hold structured data, so it can never be eligible for the richer menu results.
- It is invisible to a screen reader unless it has been tagged properly, which almost none are.
Keep the PDF if your front of house needs it for printing. Just stop making it the only version. The web version is the one that has to earn the search.
Treat the menu as a landing page
The mental shift that fixes most of this is simple. The menu page is not a document viewer, it is a landing page for a person who has already decided they want to eat somewhere and is now deciding whether it is you. That person wants four things quickly: is the food what I want, is it in my budget, can I eat here given my dietary needs, and how do I book.
So the page needs the menu itself as real text, plus enough surrounding context that a search engine understands what the page is about and a human can act on it. That means the venue name, the suburb, the service type, the current price points and a clear next step, all on the page, all in text.
How to structure a menu page
One page, or a page per menu
If you serve one menu that changes seasonally, use one page. If you run genuinely different services, breakfast, lunch, dinner, a set banquet, a function package, a drinks list, give each one its own page with its own URL, title and description. Those are different searches with different intent, and a single page trying to answer all of them will do it badly.
The test is whether someone would search for that thing on its own. People search for a venue’s breakfast menu and its function packages separately, so those deserve separate pages. People do not usually search for the entrees section on its own, so that stays a heading inside the main menu page rather than a page of its own.
Where you do split, link the menus to each other and give each a distinct focus so they are not competing for the same phrase. Two near identical pages both aiming at the same wording will split their own signals and neither will settle.
Headings that match how people order
Use one h1 that names the page plainly, something like the venue name and the menu it covers. Then use h2 for each course or section, Entrees, Mains, Sides, Desserts, Wine by the Glass, and h3 only if a section genuinely nests inside another.
Do not skip levels and do not use a heading tag purely to make text bigger. The heading order is how assistive technology builds a page outline, and it is also how a crawler works out which parts of a long page belong together. Getting this right is free.
Item names, descriptions and prices as real text
Every dish should be a text item with a name, a short description and a price. Not an image of a name, not a background image with text baked in, not a canvas element. Plain text in the markup.
Descriptions are where the search value sits. A dish listed as Pappardelle, 32 tells a crawler almost nothing. The same dish written as slow braised beef ragu with hand cut pappardelle, parmesan and gremolata matches how people actually search, and it also sells the dish better to the person reading it. Write the description you would want a waiter to give.
Prices should be current. An out of date price is worse than no price, because the first thing it teaches a diner is that the site cannot be trusted. If you change prices often, put a short line at the top saying when the menu was last updated and keep that line honest.
Dietary and allergen wording people actually search
Dietary searches are some of the highest intent queries a restaurant can capture, because someone searching for a gluten free option in a suburb is not browsing, they are choosing where to book. Yet most menus bury this in a legend of tiny symbols that exists only as an image.
Label the items in text. If a dish is vegan, the word vegan should appear in the markup next to it, not just a leaf icon. Use the words people type: vegetarian, vegan, gluten free, dairy free, nut free, halal, and spell out that kitchens handling allergens cannot guarantee no trace where that is the case. If you use icons for visual clarity, keep them, but pair each one with text or a proper accessible label so the meaning survives for a crawler and a screen reader alike.
A short paragraph above the menu that says plainly which dietary requirements you cater for, and which you cannot, will do more for the right kind of enquiry than a page of general copy about your passion for produce.
Structured data worth adding
A menu page can carry valid JSON-LD that describes the venue and the menu itself. At minimum, mark up the restaurant with its name, address, phone number, opening hours, price range and cuisine. Where the menu is stable enough to maintain, the menu, its sections and its items can be described too.
Two rules keep this out of trouble. The schema must match what a human sees on the page, so do not describe dishes or hours that are not there. And it must stay current, because structured data that contradicts the visible page is worse than none at all. If nobody will maintain item level markup, describe the venue properly and stop there.
Photos without wrecking mobile speed
Food photography sells, so nobody sensible is arguing for a menu with no images. The problem is that menu pages are where image discipline usually collapses, twenty full resolution photos straight off a camera, no dimensions, all loading at once.
Serve modern formats with a fallback, size each image to what it is actually displayed at, set explicit width and height attributes so the layout does not jump while it loads, and lazy load everything below the first screen. Preload only the single hero image. Give every photo real alt text that names the dish rather than a filename. Done properly you can carry a gallery and still hold a strong mobile score. Done carelessly, the menu becomes the slowest page on the site, and it is also the page most people open on a phone with poor reception outside your front door.
Where the menu page should link
A menu page that goes nowhere is a wasted opportunity. From the menu, link to the booking page with wording that says what happens next, link to the other menus you publish, and link to the location or contact page so the address and hours are one tap away. If you have a functions offer, link to it from the relevant section rather than from a generic sidebar.
Use descriptive anchor text. Book a table for dinner is useful to a person and to a crawler. Click here is useful to neither. Keep the links inside sentences that would exist even if there were no link to place, because a paragraph invented purely to hold a link reads exactly like what it is.
Mistakes worth fixing this week
- The menu opens as a PDF or an image gallery with no text version.
- The page title and the h1 are both just the word Menu, so neither tells a search engine which venue or which suburb.
- Prices were last touched two menu changes ago.
- Dietary information exists only as icons with no text equivalent.
- The page has no link to the booking flow, so the diner has to go back to the navigation to act.
- Photos are unsized, so the layout shifts while the page loads and the mobile score suffers for it.
- Every menu variant lives on one enormous page that takes ten seconds to scroll on a phone.
Where to start
Publish the menu as text first. That single change is worth more than everything else on this list combined, because it turns an invisible file into an indexable page. Then add headings, prices and dietary wording, then the internal links, then the schema, then the photography once the page is fast.
If the menu is one part of a bigger problem, that the venue does not appear for the searches happening in its own suburb, the menu page alone will not fix it. That work sits across the location signals, the profile and the site together, and it is what restaurant SEO services are built around. Either way, start with the menu in text, because nothing else you do to the page matters while the content is locked inside a download.
