Menu SEO: how to structure a menu page Google can read

This is the most common technical problem I find on restaurant websites, and it is also the cheapest to fix. Nobody chose it. A designer wanted the layout to match the printed menu, so they exported a PDF and linked to it, and that was the end of it.

The cost is quiet. You do not lose a ranking you can see. You never appear for the dish you are known for.

Why can Google not read my PDF menu?

It can technically open a PDF, but almost none of the value survives.

A PDF is a document, not a page. It has no clean structure Google can associate with your restaurant, it usually loads badly on a phone, and it cannot hold the internal links, the ordering button, or the hours that a real page holds. When someone searches for a dish plus your city, a page with that dish written in text has an obvious answer to give and your PDF does not.

A photo of your printed menu is worse. It is an image. The words in it are decoration to a crawler.

An ordering widget is a third version of the same problem. The menu lives on somebody else's system and loads after the page does, so the text is often not part of your page at all. That is one of the mechanics behind a delivery app outranking your own website, because the marketplace publishes your items as readable text and you do not.

What does the PDF cost you a second time?

Speed, and this part is measured rather than argued.

Google, working with Deloitte on a study it calls Milliseconds Make Millions, analyzed 37 brand sites hourly over 30 days across 30.5 million sessions. A 0.1 second improvement in mobile load time produced an 8.4% lift in retail conversions and a 9.2% lift in average order value. That is 2019 data from retail and travel brands, not restaurants, so read it as direction rather than as your number.

Google's February 2018 SOASTA update, using a model trained on bounce and conversion data, found that as page load goes from one second to ten seconds, the probability of a mobile visitor bouncing increases 123%, and that as the number of elements on a page goes from 400 to 6,000, the probability of conversion drops 95%.

The context that makes it concrete: Google sampled 11 million mobile web domains on a representative 4G connection in January 2018 and found mobile landing pages took more than five seconds to display above-the-fold content, with 79% over 1MB and 23% over 4MB.

A print-resolution PDF menu is frequently the heaviest thing on a restaurant website. You are asking a hungry person on a phone to download a document to find out whether you have a vegetarian entree. Google's Core Web Vitals thresholds call Largest Contentful Paint good at 2.5 seconds or better, at the 75th percentile of visits. A PDF is not evaluated against that at all, which is another way of saying it is not really part of your website.

What does a readable menu page actually look like?

Plain, boring, and text based.

One page, its own URL. Something like yoursite.com/menu. Linked from your main navigation and from your Google Business Profile.

Sections as real headings. Appetizers, mains, desserts, drinks. Headings, not styled text inside an image.

Every dish written out by name. The name your guests use, the name on the printed menu, the name people would type.

A description under each dish. One line is enough. This is where the searchable words live: ingredients, preparation, whether it is spicy, whether it is vegetarian. A menu of bare dish names gives a search engine almost nothing to match.

Prices, if you publish them. Not required for search, but the absence of prices costs you more inquiries than any price ever has.

A clear next action. Order, reserve, or call, on the page, not three clicks away.

That is the whole specification. There is no schema trick that substitutes for having the words on the page.

Do I need FAQ schema or special markup on the menu?

No, and if an agency has quoted you for it, this is the paragraph to send back.

Google restricted FAQ rich results to well-known authoritative government and health websites in August 2023, and stated the result type would no longer be shown regularly for everyone else. HowTo rich results were fully deprecated the following month. Neither appears in Google's current rich results gallery, which does still list Local business, Organization, Review snippet, Breadcrumb, Event and roughly two dozen others.

On the AI question specifically, Google's own documentation says structured data is not required for its generative features and there is no special schema you need to add.

There is a real mechanism underneath the hype. Fabrice Canel, a principal product manager at Microsoft Bing, confirmed at SMX Munich in March 2025 that schema markup helps Microsoft's language models understand web content. That supports the indirect path: search engines ingest structured data at index time to resolve what your business is, and that understanding feeds the answer layer. There is no credible published test showing a model reads your JSON-LD directly and cites you because of it.

What to implement on a restaurant site: `LocalBusiness` with the `Restaurant` subtype, `Organization` with `sameAs` pointing at your verified profiles, and `Menu` or `Service` where it fits. Not for AI visibility. For entity disambiguation and the rich results that still exist.

Two hard rules go with it. Google requires that your structured data matches the visible text on the page, so marking up dishes or prices you do not display is a violation rather than a shortcut. And Google's guidelines prohibit marking up reviews about your own business on your own site, which means the plugin that scrapes your Google reviews and stamps `AggregateRating` on your homepage is a manual action risk with zero upside. That plugin is on a startling number of restaurant sites.

Should I have one menu page or several?

Several, if you genuinely run several menus. One, if you are splitting a single menu to look bigger.

Lunch, dinner, brunch, happy hour, and drinks are legitimate separate pages when the offerings are different, because the searches are different. Somebody looking for brunch is not looking for the same thing as somebody looking for a late dinner.

The failure mode is splitting for its own sake, or duplicating the same menu across pages, or across locations. Two locations of the same restaurant with the identical menu text on both pages end up competing with each other in the results, which is exactly how multi location restaurants start cannibalizing themselves.

Rule of thumb: one page per menu that a customer would actually ask for by name. If nobody says "can I see your bar snacks menu," it does not need a page.

Does the menu page help me rank for near me searches?

Indirectly, and more than you would expect.

A near me search is decided mostly by proximity and profile data, not by your website. But a readable menu page supports those results, because it confirms what you serve, gives your profile a working menu link, and answers the follow up question the customer asks after the map shows them three options. The full mechanics of how proximity works are in why the closest restaurant is not always the one that ranks.

Where the menu page wins outright is dish level and constraint level searching. A person looking for a specific dish, or for gluten free options, or for a vegetarian version of your cuisine, is looking for text that only exists on a menu page.

Those long questions are also where the answer boxes live. Ahrefs analyzed 146,122,391 desktop SERPs and found AI Overviews on 9.5% of one-word queries and 46.4% of queries seven words or longer, with question-shaped queries at 57.9%. Your menu page is the only asset you own that contains those words.

The phone confirms it. Maple's analysis of 1.2 million calls across more than 1,000 US restaurant and local business locations found 15% of restaurant calls are menu questions, every one of them answerable by a readable page without ringing your host stand. Maple sells restaurant phone software, so treat the taxonomy as vendor research with a disclosed sample.

What is a text menu actually worth?

Here is the arithmetic. Every input is yours to replace, and I have marked which ones are assumptions.

Count the items on your menu. Say 42. On a PDF, exactly zero of those 42 names exist as text a search engine can match. Convert the page and all 42 become matchable, along with the ingredients in the descriptions.

Now size it. Assume 30 incremental visits a month arriving from dish-level and constraint-level searches. That is an assumption, and you should replace it with real Search Console data after 90 days. Then:

• One in ten of those visits produces a booking or a walk in: 3 parties a month.
• Average party of 2.4 people at a $38 check: 3 times 2.4 times 38, or $273 a month.
• Annualized: $3,276 in sales.
• The National Restaurant Association puts food at roughly 33 cents of every sales dollar for a typical independent, so contribution is about $2,195 a year.

Now the conversion that makes it worth doing. The same Association analysis puts pre-tax profit for a typical independent near 5% of sales, meaning one dollar of profit takes roughly twenty dollars of sales to produce. That $2,195 is the profit equivalent of about $44,000 in additional dinner volume, and it came from an afternoon of typing.

If your version comes out at 3 visits a month rather than 30, the menu page is still worth doing and it is not worth paying an agency a retainer for.

What to do this week

Open your menu on your phone. If it downloads a file, opens an image, or takes more than a couple of seconds, you have found the project.

Then copy the printed menu into a plain page, section by section, with one line of description under each dish. Do not redesign anything. Text first, appearance later.

Then check that the menu link on your Google Business Profile points to that page and not to a PDF or a marketplace.

Then look at your homepage for an `AggregateRating` block pulling in your own Google reviews, and remove it.

If you only do one thing, write real descriptions under the dishes you are known for. That is where the searchable language lives, and it is the part almost every restaurant skips.

If your menu changes around local events and seasons, build the page so an update takes ten minutes rather than a call to a developer. The same planning logic applies to building a calendar around local events, where the menu, the staffing, and the marketing all move together.

Questions about your menu page?

Email me at eric@seod.com with the URL of your menu. I will tell you exactly what a search engine can read on it and what it cannot, in plain language, with the specific lines that are invisible. Takes me a few minutes and costs you nothing.

I ran restaurants for sixteen years and I answer these myself. If your menu page is already fine, I will tell you that instead of finding something to sell you.

Or keep reading more on restaurant marketing.