SEO for Restaurants: Menu Schema, Maps, and AI Search

A restaurant owner who reads the top-ranking guides for this keyword ends up with the same list every time: claim your Business Profile, add your menu, get reviews, post on social. Each item is correct. None of them tells you what to actually change on your site this afternoon.

I read the three highest-ranking guides before writing this. The longest runs about 4,200 words. Between them they contain one line of structured data (which the page uses on itself, not as advice), one page-speed number that is stated without a source and does not match Google's published threshold, and nothing at all about the two restaurant-specific Google documents that no longer exist.

That last point is the reason this article exists. The standard advice for this vertical points at documentation that has been removed, and at a rich result almost nobody can get.

What restaurant SEO is actually competing against

The search result for a restaurant query is not ten blue links. Type "thai food near me" and the first screen is a map pack with three profiles, then aggregator listings, then an AI Overview, and only then somebody's website. Your site is competing for the space left over after Google, Yelp, DoorDash and Tripadvisor have taken theirs.

That changes the order of work. For most local businesses the website is the main asset and the profile supports it. For a restaurant the profile is frequently the transaction, because a diner who finds your hours, your photos and your phone number in the map pack never needs your site at all.

So the honest framing is two surfaces, not one:

• Google Business Profile wins the "near me" and "open now" traffic, plus most of the map pack.
• Your website wins the dish-level, occasion-level and neighbourhood-level queries that a profile cannot express, and it is the only one of the two that you own.

Neither replaces the other. The mistake I see most often is a restaurant that has polished its profile to a mirror finish and left its website as a single page with a PDF attached. That business is invisible for every query more specific than its own name.

If you run more than one location, the split matters even more, and the same logic that applies to contractors working several service areas applies here: one profile per physical location, one page per physical location, and never a page per neighbourhood you would like to serve.

Your Business Profile is a ranking surface with published rules

Google publishes what drives local ranking, and it is short. From the Business Profile help documentation: "Local results are mainly based on relevance, distance, and popularity."

Worth noting for anyone who has read older guides: the section heading further down that same page still reads Prominence, while the summary sentence now says popularity. The definition underneath is unchanged, so nothing about your work changes, but if you see both words quoted as if they were different factors, they are the same one.

The same page carries a sentence that should end a category of sales call: "There's no way to request or pay for a better local ranking on Google."

Of the three factors, exactly one is fully under your control today. Distance is the diner's location. Popularity is built from reviews and from how many sites reference you, which is slow. Relevance is Google matching your profile to the query, and it is driven by how completely you have filled the thing in.

Concretely, on the profile:

The menu link deserves emphasis. If it points at your DoorDash page you have handed the relationship to a marketplace that charges you for it, which is the same trade-off examined in SEO versus Google Ads: renting demand is faster, owning it is cheaper once it works.

The Restaurant schema you can paste

Here is where restaurants are genuinely different from every other local vertical, and where the ranking guides are silent.

Restaurant is a schema.org subtype of LocalBusiness, and Google's local business documentation is explicit about which one to use: "Use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on."

For structured data purposes, only name and address are strictly required on a local business. Everything else is optional and useful. This is the block to adapt, drawn from the shape Google publishes in its own examples:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Trattoria Example",
  "image": [
    "https://example.com/photos/1x1/dining-room.jpg",
    "https://example.com/photos/16x9/dining-room.jpg"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "148 W 51st St",
    "addressLocality": "New York",
    "addressRegion": "NY",
    "postalCode": "10019",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.761293,
    "longitude": -73.982294
  },
  "url": "https://example.com/",
  "telephone": "+12122459600",
  "servesCuisine": "Italian",
  "priceRange": "$$",
  "menu": "https://example.com/menu",
  "acceptsReservations": "True",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday"],
      "opens": "17:00",
      "closes": "22:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "17:00",
      "closes": "23:00"
    }
  ]
}

Put that in a plain <script type="application/ld+json"> tag in the page head. Four details matter more than they look:

• servesCuisine is the field that says what kind of restaurant you are in machine-readable form. Most sites never set it.
• menu takes a URL, not a nested menu object. Point it at an HTML page, for reasons covered in the next section.
• openingHoursSpecification uses 24-hour times and can carry several blocks. Split lunch and dinner service rather than flattening them.
• priceRange is a free-text string. The dollar-sign convention is conventional, not required.

Then validate it. Google's guidance is to "Validate your code using the Rich Results Test and fix any critical errors", and the tool also flags non-critical issues, which the docs note "isn't necessary to be eligible for rich results" but is worth reading anyway.

If you are on a framework rather than a website builder, the mechanics of injecting JSON-LD safely (plain script tag, escape the closing bracket, never a client-side script loader) are covered in more depth in the Next.js SEO walkthrough.

The two Google documents that no longer exist

This is the finding that surprised me, and I checked it twice because I did not believe it.

A large amount of restaurant SEO advice tells you to implement "Menu schema" and "Restaurant rich results" and links to developers.google.com/search/docs/appearance/structured-data/menu or the equivalent /restaurant path. Both of those URLs return 404 as of publication. There is no standalone Menu rich result guide and no standalone Restaurant rich result guide. The only live document is the general local business page.

What does exist there is a section headed "Restaurant carousel (limited access)", and its second sentence is the one to read before you spend a weekend on this: "The Restaurant carousel is limited to a small set of restaurant providers. If you would like to participate, register your interest in our form."

That is an invite list, not a feature you implement. If a guide promises you a restaurant carousel in exchange for markup, it is describing something you cannot switch on.

None of which makes the markup pointless, and it is worth being precise about why. Structured data still tells Google what your entity is, what cuisine you serve, when you are open and where your menu lives. Google's own AI guidance puts it this way while explicitly deflating the hype: structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search."

Add the markup because it describes your business accurately. Do not add it expecting a carousel.

The review stars trap, which most restaurants walk straight into

Almost every restaurant SEO guide tells you to display reviews on your site and mark them up with aggregateRating so you get stars in the search result. Follow that advice on your own site and you get nothing, and Google documents exactly why.

From the review snippet documentation, listing which types are supported: "Local business (only for sites that capture reviews about other local businesses; see the guidelines about self-serving reviews)".

The rule itself is stated plainly a little further down the same page: "If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature."

The documentation goes on to name the exact implementation most restaurants use as an example of the problem: a review about entity A placed on entity A's own website, "either directly in their structured data or through an embedded third-party widget (for example, Google Business reviews or Facebook reviews widget)".

So the popular tactic of embedding a Google reviews widget on your homepage and marking it up is not a shortcut to stars. It is the documented case of ineligibility.

Reviews still matter enormously, they just do their ranking work somewhere else. They feed the popularity factor on your Business Profile, where the stars actually appear in the map pack, and they are read by diners regardless of markup. This is the same distinction I drew for dental practices, where the review layer is where local ranking is genuinely decided. Collect reviews on the platforms that display them. Show them on your site because they persuade people. Do not mark them up expecting stars.

Your menu is a page, not a PDF

The advice "do not use a PDF menu" is everywhere, and the reason usually given for it is wrong. The reason given is that Google cannot read PDFs. Google can. Adobe Portable Document Format is on the published list of file types Google indexes, alongside PostScript, EPUB and the Microsoft Office formats.

The real problems with a PDF menu are different, and they are worse:

1. A PDF cannot carry structured data. No Restaurant block, no servesCuisine, no opening hours. Your single most important page is invisible to the mechanism described above.
2. A PDF is not a landing page. It has no title tag you control well, no internal links out, no meta description, and it looks terrible on a phone, which is where nearly all restaurant searches happen.
3. A PDF is one document for many queries. "Gluten free pasta [city]" and "vegan brunch [city]" are separate searches. An HTML menu can give each dish or section its own anchor, its own heading, and its own descriptive text.
4. A scanned or photographed menu is worse still. If the text is an image inside the PDF, extraction depends on optical character recognition rather than on text you supplied.

The practical rule: publish the menu as HTML at a stable URL, use real headings per section, write one honest sentence per dish, and offer the PDF as a download beside it if your guests like it. Then point the menu property and your Business Profile menu link at the HTML version.

The one-sentence-per-dish habit is the highest-leverage writing you will do on the whole site. "Cacio e pepe" ranks for nothing. "Cacio e pepe, made with Pecorino Romano and cracked black pepper, our most-ordered vegetarian pasta" is a page that can match a dozen real searches, and it is true, which is the only kind of optimisation worth doing.

Speed, with the actual numbers

Every guide in this SERP says your site should be fast. One of them puts a number on it, "shouldn't take longer than 2 seconds to load", and cites nothing. Google publishes thresholds, they are public, and they are not that.

The Core Web Vitals thresholds, from web.dev:

The part almost everyone omits: these are assessed at "the 75th percentile of page loads, segmented across mobile and desktop devices". You are not aiming for a good score on your own laptop on office wifi. You are aiming for three quarters of real visits, most of them on a phone on mobile data, standing outside deciding where to eat.

For restaurants the usual culprits are predictable. Enormous unoptimised food photography is the first. A full-screen background video is the second. A reservation widget and three tracking scripts loading before anything renders is the third. The photography problem is the same one working photographers face, and the fix is identical: correctly sized, modern-format images with width and height attributes set so nothing shifts as they load.

Measure with real tools rather than by feel. PageSpeed Insights gives you field data where enough traffic exists, and Search Console has a Core Web Vitals report grouped by URL pattern.

What to publish, in order of distance from a booking

A restaurant does not need a blog in the sense that a SaaS company needs one, and anyone selling you thirty posts a month for a single location is selling you volume you cannot use. What a restaurant needs is a small number of pages that answer questions diners actually type before choosing.

Sorted by how close each one sits to a booking:

That last two rows carry a warning worth taking seriously. Spinning up dozens of near-identical pages for every nearby neighbourhood is a documented spam pattern, not a clever tactic. Google's spam policies define doorway abuse as "when sites or pages are created to rank for specific, similar search queries", naming as an example "multiple domain names or pages targeted at specific regions or cities that funnel users to one page".

One genuine page about your actual neighbourhood is fine. Twenty templated ones are the thing the policy is describing. The same trap catches interior designers and coaches working across several towns.

And on length, since the guides in this SERP argue about it: Google's starter guide says "The length of the content alone doesn't matter for ranking purposes (there's no magical word count target, minimum or maximum, though you probably want to have at least one word)."

AI search, and what genuinely changes for a restaurant

Diners now ask assistants where to eat. That is real, and the honest answer about what to do differently is shorter than the industry would like.

Google's AI optimization guide, last updated 2026-07-10, has a section on what you can ignore. On the file every vendor has been selling for two years: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them."

On rewriting your pages into fragments for machines: "'Chunking' content: There's no requirement to break your content into tiny pieces for AI to better understand it."

And the framing sentence that should settle most arguments: "From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO."

The same document warns about the tooling that has grown around this: "Be wary of third-party tools that promise ranking success or claim to use 'internal' Google metrics. No third-party tool has access to our internal ranking or AI systems."

What does change for a restaurant is smaller and more practical. An assistant answering "where can I get a good gluten-free pizza in [city] tonight" needs facts it can retrieve: current hours, a real address, a readable menu with dietary detail written in words, and a site it is allowed to crawl. All four of those are the same work described above. The mechanics of how assistants retrieve and cite pages are covered properly in getting cited by ChatGPT and in the cross-assistant view of LLM SEO, and the measurement side in LLM brand visibility.

The one restaurant-specific point: a PDF menu and an image-only menu are both far harder for an assistant to quote accurately than an HTML page. The AI-search argument for killing the PDF is the strongest one there is.

How to measure it without fooling yourself

Set up Search Console, verify the domain, and use the URL Inspection tool. Google's own instruction is direct: "To check how Google sees your page, use the URL Inspection Tool in Search Console." Run it on your menu page first, because that is the page most likely to be rendering differently than you assume.

Three reports are worth a monthly look:

• Performance, filtered to your menu and reservations pages, watching impressions before clicks. Impressions rising with flat clicks is a title and description problem, not a ranking problem.
• Core Web Vitals, grouped by URL pattern, because one bad template usually explains every failing URL.
• Business Profile insights, separately, for calls, direction requests and menu clicks. Those are the actions that turn into covers.

On timing, the only defensible answer comes from Google rather than from an agency deck: "Some changes might take effect in a few hours, others could take several months. In general, you likely want to wait a few weeks to assess whether your work had beneficial effects in Google Search results."

And the sentence that belongs at the end of every article in this category, quoted from Google's own guidance on hiring help: "No one can guarantee a #1 ranking on Google." Anyone who does is telling you something the platform explicitly says is not true. If you are weighing doing this yourself against paying someone, Google's position on that is on the record too, in the same document: "If you run a small local business, you can probably do much of the work yourself." That case is made at more length in the do-it-yourself guide for small businesses, and the vetting questions to ask if you do hire are in the AI SEO agency piece.

Work through it in this order and the effort compounds: profile complete and accurate, menu in HTML, Restaurant markup validated, images sized, then one page at a time down the table above.

FAQ

How do I do SEO for my restaurant?

Start with the two surfaces, in order. Fill your Google Business Profile completely, especially the primary category, hours, attributes and a menu link pointing at your own site. Then publish your menu as an HTML page rather than a PDF, add Restaurant structured data with servesCuisine, menu and openingHoursSpecification, and validate it in the Rich Results Test. After that, work down from the pages closest to a booking: reservations, private events, catering. Everything else is optional until those are done.

Do I need Menu schema for a restaurant rich result?

There is no standalone Menu rich result to get. Google's dedicated Menu and Restaurant structured data documents both return 404 as of publication, and the only restaurant-specific feature described on the live local business page is the Restaurant carousel, which is "limited to a small set of restaurant providers" with a registration form to express interest. Use the menu property inside Restaurant markup as a URL pointing at your HTML menu. That is worth doing for accuracy. It is not a route to a carousel.

Should I put review stars on my own restaurant website?

You can display reviews, but marking them up will not produce stars in Google's results. Google's review snippet guidelines state that when "the entity that's being reviewed controls the reviews about itself", pages using LocalBusiness or Organization structured data are "ineligible for star review feature", and the documentation names embedded Google or Facebook review widgets as an example. Collect reviews on the platforms that display them, where they feed the popularity factor behind your map pack ranking.

Can ChatGPT do SEO for my restaurant?

It can help you draft dish descriptions, section headings and event-page copy, and that is genuine time saved. It cannot fill in your Business Profile, validate your structured data, or verify a claim about your own kitchen. Treat anything datable that it produces as a draft to check rather than a fact, and never publish a menu description an assistant invented, because a wrong allergen line is a real-world problem long before it is an SEO problem.

What is the 80/20 rule in SEO for a restaurant?

For a single-location restaurant the 20 percent that produces most of the result is unusually easy to name: a complete and accurate Business Profile, and a fast HTML menu page with honest dish descriptions. Those two carry the "near me", "open now" and dish-level queries, which is nearly all commercial restaurant search. Structured data, neighbourhood pages and link building are worth doing after those, not instead of them.

How long does restaurant SEO take to work?

Nobody can give you a date, and results vary by market, competition and starting point. Google's own guidance says some changes take effect within hours while others take several months, and recommends waiting a few weeks before judging whether a change helped. Profile corrections such as fixing wrong hours or a wrong primary category tend to show up fastest, because they change how you are matched rather than how authoritative you are. Content and links are the slow half.