Restaurant schema markup is one of the few technical SEO tasks with a clear finish line — there’s a defined vocabulary, Google publishes what it supports, and you can validate your work in a browser. What makes it go wrong for restaurant groups isn’t difficulty. It’s that most implementations mark up the wrong things, mark them up on the wrong pages, and chase rich results that Google stopped showing.
This is a practical checklist for restaurant operators and the people doing their technical SEO: what to implement, what each piece actually buys you, and what to stop doing.
Key takeaways
- Use the most specific type available.
Restaurant, notLocalBusiness, and JSON-LD rather than microdata. - One schema block per physical location, on that location’s own page, with its own address, geo coordinates, and hours.
- Menu markup helps machines read your menu — but a visible menu rich result is not something most restaurants will get.
- Event schema still earns rich results, which makes it the most under-used opportunity for restaurants running wine dinners, tastings, and live music.
- FAQ rich results are gone. Google stopped showing them in May 2026. The markup is still valid and harmless; the SERP feature it was added for no longer exists.
- Structured data must match visible page content. Marking up a menu that isn’t on the page is a guidelines violation, not a shortcut.
Get Free Consultation
Read more about our Restaurant Marketing Solutions!
What restaurant schema markup actually does
Structured data doesn’t rank you. It describes you.
Schema markup translates your page into machine-readable facts: this is a restaurant, it’s at this address, it serves this cuisine, it opens at these times, it takes reservations here. Search engines use that to build an accurate entity rather than inferring one from your HTML.
The practical payoffs are three. It makes your business eligible for certain rich results. It feeds the knowledge panel and helps Google reconcile your site with your Google Business Profile. And it removes ambiguity for any system reading your site, which matters more as retrieval-based search grows.
What it does not do is move your organic position directly, and any implementation sold on that basis is overselling. On the AI question specifically, be careful: Google’s own guidance on its generative search features states there’s no special schema.org markup required for AI Overviews or AI Mode. Structured data is good hygiene for machine readability. It isn’t an AI visibility lever, whatever the current round of advice claims.
The core entity: Restaurant
Start here, on every location page.
Restaurant sits in the schema.org hierarchy under FoodEstablishment, which sits under LocalBusiness. Google’s Local Business structured data documentation recommends using the most specific subtype that accurately describes the business, so Restaurant beats FoodEstablishment, which beats LocalBusiness. If you run a bar, BarOrPub is more specific still.
| Property | What it does | Priority |
|---|---|---|
name | The location’s name as it appears publicly | Required |
address (PostalAddress) | Street, city, region, postal code, country | Required |
telephone | Must match the number on your Google Business Profile exactly | Required |
openingHoursSpecification | Structured hours, including special and holiday hours | High |
geo (GeoCoordinates) | Latitude and longitude for the specific address | High |
servesCuisine | Spanish, Cajun-Italian, Japanese — be specific | High |
priceRange | The $–$$$$ convention | Medium |
url | The canonical URL of that location page | High |
image | Exterior, interior, and food images | Medium |
acceptsReservations | Boolean, or a URL to the booking page | Medium |
hasMenu | URL or nested Menu object | High |
sameAs | Links to GBP, Yelp, Instagram, Facebook — entity reconciliation | Medium |
aggregateRating | Only if genuine, first-party, and visible on the page | Conditional |
Two cautions on that last row. Ratings must be your own collected reviews displayed on the page, not your Google rating scraped back onto your site. Marking up review data you don’t display is a guidelines violation and can attract a manual action.
Use JSON-LD, placed in a <script type="application/ld+json"> block. Google prefers it, it’s easier to maintain than inline microdata, and it doesn’t couple your markup to your template’s HTML structure.
Menus
The menu hierarchy nests like this: Restaurant → hasMenu → Menu → hasMenuSection → MenuSection → hasMenuItem → MenuItem, with an offers object on each item for price and currency.
It’s worth doing, and it’s worth being honest about why. Menu markup makes your dishes machine-readable, which supports entity understanding and helps Google reconcile what you serve with what your Google Business Profile claims. What it will not reliably do is produce a visible menu rich result — Google’s own documentation notes that the restaurant carousel is limited to a small set of participating providers, with an interest form rather than open eligibility.
So implement menu markup for accuracy, not for a SERP screenshot.
Three implementation rules:
The menu must exist as crawlable HTML on the page. A menu that lives only in a PDF or an image can’t be marked up honestly, and structured data has to match visible content.
Keep prices in sync or leave them out. A MenuItem with an offers price that no longer matches the menu is worse than no price at all. If your prices move seasonally and nobody owns updating the markup, omit the price and mark up name and description only.
Simpler is more maintainable. For most restaurant groups, hasMenu pointing to a menu page URL is the realistic implementation. Full nested item-level markup is for sites where the menu is generated from a database, not hand-maintained.
Events
This is the most under-used piece of restaurant schema markup, and unlike FAQ markup, Event still produces rich results.
Restaurants run more events than they mark up: wine dinners, tasting menus, chef collaborations, live music, holiday services, brunch specials with a fixed date. Each of those is a legitimate Event with a name, startDate, endDate, location pointing to the restaurant, offers for ticketing, and an eventAttendanceMode.
For a group running regular ticketed dinners, this is a genuine visibility opportunity that competitors are mostly ignoring. Two practical notes: startDate needs a timezone offset, and an event page that’s been sitting expired for months is worth removing rather than leaving to rot in the index.
FAQs: what changed, and what to do now
Here’s the part most checklists haven’t caught up with.
Google deprecated FAQ rich results. The expandable question-and-answer panels stopped appearing in search results on 7 May 2026, and the deprecation notice sits at the top of Google’s own FAQPage documentation. The FAQ search appearance filter, the Search Console rich result report, and Rich Results Test support were removed the following month, with Search Console API support ending in August 2026.
This was the end of a longer trend rather than a surprise. In August 2023 Google narrowed FAQ rich results to well-known government and health sites and removed HowTo rich results entirely. The 2026 change closed the remaining eligibility.
What this means practically:
- Don’t remove existing FAQPage markup. Google has said unused structured data doesn’t cause problems,
FAQPageremains a valid schema.org type, and other crawlers may still parse it. - Do stop adding it to chase a SERP feature. That feature is gone. If someone is selling FAQ schema as a traffic lever, the lever was disconnected.
- Do keep writing FAQ content. A well-built FAQ section covering the questions guests actually ask is one of the most efficient ways to cover long-tail intent. That was always the real value; the rich result was a bonus that has now expired.
- Do check your dashboards. Any automated Search Console reporting pulling FAQ appearance data needs updating, or it will return empty values silently.
The honest reframe: FAQ schema is now a description, not a tactic.
Multi-location groups
Everything above gets harder at eleven locations, and the failure modes are specific.
One schema block per location page. Not one group-level block listing every address. Each location needs its own Restaurant object with its own address, geo, telephone, openingHoursSpecification, and url.
@id for each location. A stable, unique identifier — typically the location page URL with a fragment — lets you reference locations consistently and avoid entity collisions between sites a mile apart.
parentOrganization linking each location to the group entity, with a corresponding Organization block on the brand page.
NAP must match the Google Business Profile exactly. A suite number in the schema that isn’t in the GBP listing is an inconsistency you’ve now published in machine-readable form.
Schema hygiene sits alongside the architecture problems that come with running multiple addresses — if your location pages are competing with each other, markup won’t fix it. Our guide to multi-location restaurant SEO covers the structural side.
The checklist
| Page | Schema type | Key properties |
|---|---|---|
| Each location page | Restaurant | name, address, geo, telephone, openingHoursSpecification, servesCuisine, hasMenu, url, image, sameAs, @id |
| Brand or homepage | Organization | name, logo, url, sameAs, subOrganization or department links |
| Menu page | Menu with hasMenuSection | Section names, item names, descriptions; prices only if maintained |
| Event pages | Event | name, startDate with offset, endDate, location, offers, eventAttendanceMode |
| Blog posts | Article or BlogPosting | headline, datePublished, dateModified, author, image |
| Reservations | acceptsReservations on Restaurant | Boolean or booking URL |
| FAQ sections | FAQPage (optional) | Keep if accurate; expect no rich result |
| Breadcrumbs | BreadcrumbList | Still supported and still useful for site hierarchy |
Validating, and the errors that keep recurring
Run every template through Google’s Rich Results Test and the Schema.org validator, then monitor Search Console’s enhancement reports.
The recurring errors in restaurant implementations:
- Marking up content that isn’t visible on the page. The most serious one, and the one that attracts manual actions.
- One group-level schema block for multiple addresses, so no individual location is described properly.
- Prices in
MenuItemoffers that nobody maintains, drifting from the actual menu within a quarter. openingHoursSpecificationthat never gets holiday hours, quietly contradicting the GBP listing.- Using
LocalBusinesswhenRestaurantwas available. - Missing timezone offsets on event dates.
aggregateRatingpopulated from Google reviews rather than first-party reviews displayed on the page.- Markup added once and never audited, so it describes the restaurant as it was two menu changes ago.
That last one is the real failure mode. Schema isn’t a launch task; it’s a maintenance task, and a group with eleven locations has eleven sets of hours, menus, and phone numbers that all drift.
Structured data is one layer of the technical work underneath local visibility. For the wider picture — what drives map pack placement and how to measure it honestly — see our guide to local SEO for restaurants.
Get your markup audited before you build more of it
Primi Digital runs technical and local SEO for restaurant and hospitality groups — schema audits and implementation, location page architecture, Google Business Profile management, and grid-scan benchmarking across multi-location portfolios.
If your restaurant schema markup was implemented once at launch and hasn’t been looked at since, an audit usually finds the same three things: hours that contradict the GBP listing, a group-level block where per-location blocks should be, and markup describing a menu that changed two seasons ago. Get in touch and we’ll tell you which of those you have.
Frequently asked questions
What is restaurant schema markup?
Restaurant schema markup is structured data, usually written in JSON-LD, that describes a restaurant to search engines in machine-readable form — name, address, coordinates, hours, cuisine, menu, and reservation availability. It’s based on the schema.org Restaurant type, which sits under FoodEstablishment and LocalBusiness in the vocabulary.
Does schema markup improve rankings?
Not directly. Structured data doesn’t function as a ranking factor. It makes pages eligible for certain rich results, supports knowledge panel accuracy, and removes ambiguity for systems reading your site. Any claim that adding schema lifts organic position on its own is overstating it.
Should I still use FAQ schema in 2026?
You can, but not for rich results. Google stopped showing FAQ rich results on 7 May 2026 and removed the associated Search Console reporting shortly after. FAQPage remains a valid schema.org type and existing markup is harmless, so there’s no need to strip it out — but don’t add it expecting a SERP enhancement.
What schema type should a restaurant use — LocalBusiness or Restaurant?
Restaurant, or a more specific subtype like BarOrPub where accurate. Google recommends using the most specific type that describes the business, and Restaurant inherits everything LocalBusiness offers while adding food-specific properties like servesCuisine, hasMenu, and acceptsReservations.
How do I mark up a restaurant menu?
Nest hasMenu on the Restaurant object, then Menu → hasMenuSection → MenuSection → hasMenuItem → MenuItem, with an offers object for price where you’ll maintain it. The menu must exist as crawlable HTML on the page. For most groups, pointing hasMenu at a menu page URL is the more maintainable option.
Do restaurants get menu rich results in Google?
Rarely. Menu markup supports entity understanding, but the restaurant carousel is limited to a small set of participating providers rather than being openly available. Implement menu markup for accuracy and machine readability, not for a guaranteed visual result.
How should a multi-location restaurant group handle schema?
One Restaurant block per location, on that location’s own page, each with its own address, coordinates, phone number, hours, and stable @id, linked to the group entity via parentOrganization. A single group-level block listing every address describes none of them properly.