Restaurant Schema Markup: Complete 2027 Guide (With Copy-Paste Code)
Ishant
Published on November 12, 2026
Ishant
Ishant Sharma is the Founder and CEO of Hustle Marketers, a Google Partner digital marketing agency. Working in Google Ads, Meta Ads, SEO and ecommerce PPC since 2013, he has helped 2,500+ brands generate $780M+ in trackable sales. Upwork Top Rated Plus with 100% Job Success Score. Ishant Sharma is the digital marketing specialist, not the Indian cricketer of the same name.
QUICK ANSWER
Restaurant schema markup is structured JSON-LD code added to a restaurant website that explicitly declares business details to Google, AI systems, and voice assistants in a machine-readable vocabulary. A restaurant needs 7 schema types: Restaurant (NAP core), AggregateRating, Menu/MenuItem, Review, Event, amenityFeature, and BreadcrumbList. FAQPage is covered too, but Google removed the FAQ rich result on 7 May 2026, so it earns nothing now. Copy-paste code for all 8 is below.
Restaurant schema markup is the single most impactful technical SEO change a restaurant website can make in 2027. When someone searches “Italian restaurant open Sunday near me,” Google doesn’t read your website the way a human does. Specifically, it parses your HTML, infers meaning from your words, and makes educated guesses about what your business offers. Notably, schema markup replaces those guesses with explicit declarations. Instead of Google inferring that you’re probably a restaurant and probably Italian, your structured data tells it precisely: you’re a Restaurant, you serve Italian cuisine, you’re open Tuesday through Sunday, your price range is $$, and you accept reservations at this URL.
Consequently, that shift from inference to declaration is what powers rich results. Restaurant schema markup in Google Search, AI Overviews in 2027, voice search answers, and Knowledge Panel entries. Restaurants without restaurant schema markup leave those systems to guess their hours, cuisine and location from page text alone. This complete restaurant schema markup guide covers every schema type a restaurant needs, explains what each one does and why it matters, and gives you copy-paste JSON-LD code blocks you can validate and deploy today.
Updated for 2027: this edition checks every restaurant property against the current schema.org release (version 30.1, September 2026) and Google’s structured data documentation. It adds the Google support status of each restaurant feature, a pattern for restaurants inside hotels, and a verified copy-paste JSON-LD block. The latest pass fixes the menu and event code samples and adds Google’s position on reservation buttons, an hours sync table for your site, schema and Google Business Profile, and a monthly check routine.
All JSON-LD examples on this page use the format Google explicitly recommends. Validate every block at validator.schema.org or Google’s Rich Results Test before deploying. Schema that doesn’t match your visible page content violates Google’s guidelines and risks manual action.
Summarize this article with:
Quick Discussion
Restaurant schema markup is JSON-LD code that uses the schema.org Restaurant type to state your name, address, hours, cuisine and menu URL in a form search engines can read. This guide gives copy-paste code for the eight schema types restaurants use and shows which of them Google still turns into search features in 2027.
- What Google requires: only name and address. Google’s local business documentation lists telephone, url, geo, openingHoursSpecification, menu, priceRange and servesCuisine as recommended.
- What still shows: Local business details, Event and Breadcrumb features. Review stars about your own restaurant, FAQ rich results and any menu feature do not, and the restaurant carousel is limited to a small set of providers.
- What markup cannot do: add a reservation or order button to your listing. Google points businesses to the Maps Booking API for that.
- The code: a block for each type, a verified 2027 Restaurant block, patterns for chains, hotels and holiday hours, and a form-based generator.
- The upkeep: keep hours, menu and address identical on your page, in your schema and in your Google Business Profile, and check them monthly with the routine in this guide.
What is restaurant schema markup and why does it matter in 2027?
Restaurant schema markup is structured data code added to your website that describes your restaurant to search engines and AI systems in a standardized, machine-readable vocabulary defined by Schema.org. It’s a collaborative standard maintained by Google, Bing, Yahoo, and Yandex. The format Google recommends is JSON-LD (JavaScript Object Notation for Linked Data), placed inside a <script type="application/ld+json"> tag in your page’s HTML.
Before structured data, a search engine crawler landing on your homepage read paragraphs of text and ran probabilistic inference: “this text mentions pasta, wine, and reservations, so this is probably a restaurant.” Schema markup removes the probability and replaces it with explicit statements. That’s why rich results, such as event listings, breadcrumbs and business details like opening hours, are driven by schema, not by text content alone.
In 2027, the stakes are higher because restaurant questions are answered by more systems than Google’s classic results. ChatGPT, Perplexity, Google AI Overviews, Gemini, and Apple Intelligence are all part of how people choose where to eat. Google says no special schema.org markup is needed to appear in its AI features, so schema will not get you there on its own, but it gives every system the same facts your page shows.
The market is large: the National Restaurant Association counts more than 1 million restaurant and foodservice outlets in the US and projects $1.55 trillion in sales for 2026 (State of the Restaurant Industry report, February 2026).
JSON-LD vs Microdata vs RDFa: which format to use
Use JSON-LD. Google has explicitly recommended it since 2016, and it’s the only format worth using for new implementations. The alternatives exist for historical reasons.
Specifically, Microdata embeds schema attributes directly into your HTML tags using itemscope, itemtype, and itemprop attributes. This tightly couples your structured data to your DOM structure, making it fragile when developers update templates. If your designer moves a paragraph, your schema breaks. Acceptable to maintain on sites that already use it, never worth starting fresh with.
Similarly, RDFa is common in academic publishing and semantic web contexts. It’s functionally equivalent to Microdata for Google’s purposes. There’s no reason to choose it over JSON-LD for a restaurant website.
Mixing formats on a single page is technically legal but introduces parsing conflicts. Standardize on JSON-LD and migrate incrementally if you’re moving from an older implementation.
The Restaurant schema hierarchy: understanding where it sits
Restaurant is not a standalone type. It inherits from a chain of parent types in the Schema.org vocabulary, and understanding this hierarchy explains why your Restaurant schema block can include properties you’d normally associate with an Organization or LocalBusiness.
└── Organization
└── LocalBusiness
└── FoodEstablishment
└── Restaurant ← use this
└── CafeOrCoffeeShop
└── BarOrPub
└── FastFoodRestaurant
└── Bakery / IceCreamShop
Because Restaurant inherits from all parents, a single restaurant schema markup block can include Organization-level properties (like sameAs for your social profiles), LocalBusiness properties (like geo coordinates and priceRange), FoodEstablishment properties (like servesCuisine and hasMenu), and Restaurant-specific properties (like acceptsReservations). You don’t need separate blocks for each parent type.
Always use the most specific type that applies. “Restaurant” rather than “FoodEstablishment” or “LocalBusiness” follows Google’s instruction to use the most specific LocalBusiness subtype. It does not unlock a special rich result by itself, but it tells Google exactly what kind of business you run. If you run a coffee shop, use “CafeOrCoffeeShop.” If you run a bar, use “BarOrPub.” Google’s guidance is explicit: the more specific, the better.
What does schema.org actually define for a Restaurant in 2027?
The Restaurant type defines no properties of its own. Every restaurant-specific property (acceptsReservations, hasMenu, servesCuisine and starRating) is defined one level up on FoodEstablishment, and everything else is inherited from LocalBusiness, Organization, Place and Thing. In total, a Restaurant can use 119 current properties.
We counted these from the vocabulary file of schema.org version 30.1, released on September 16, 2026, according to the versions file in the official schemaorg GitHub repository. The method: take every property whose domain is Restaurant or one of its parent types, drop the properties schema.org marks as superseded, and count properties that both Organization and Place define only once.
| Level | Current properties defined here | Examples a restaurant uses |
|---|---|---|
| Restaurant | 0 | None. It inherits everything from the levels below. |
| FoodEstablishment | 4 | acceptsReservations, hasMenu, servesCuisine, starRating |
| LocalBusiness | 5 | priceRange, openingHours, currenciesAccepted, paymentAccepted, floorLevel |
| Organization | 69 | legalName, email, parentOrganization, department, areaServed |
| Place | 41 | geo, openingHoursSpecification, specialOpeningHoursSpecification, amenityFeature, hasMap |
| Thing | 13 | name, url, image, description, sameAs |
| Total for Restaurant | 119 | 132 listed above, minus 13 that Organization and Place both define, such as address, telephone, logo, aggregateRating and review |
One detail the hierarchy diagram above leaves out: LocalBusiness inherits from both Organization and Place. The Place branch is where opening hours, coordinates, amenities and map links come from, which is why those properties are valid on a Restaurant. If you are marking up a business that is not a restaurant, our LocalBusiness schema guide covers the parent type in more depth.
Which food establishment type should you choose?
Choose the most specific of the nine FoodEstablishment subtypes in schema.org 30.1 that matches what guests see on your site. If none fits, Restaurant or FoodEstablishment itself is the safe fallback, and every property in this guide still applies.
| schema.org type | Best fit |
|---|---|
| Restaurant | Sit-down and full-service dining |
| FastFoodRestaurant | Counter service and quick-service chains |
| CafeOrCoffeeShop | Cafes and coffee shops |
| BarOrPub | Bars, pubs and taprooms where drinks lead the menu |
| Bakery | Bakeries |
| IceCreamShop | Ice cream and frozen dessert shops |
| Brewery | Breweries that serve guests on site |
| Winery | Wineries with a tasting room |
| Distillery | Distilleries with a tasting room |
Which restaurant properties are real, and what values do they expect?
The table below lists the properties restaurants use most, where schema.org defines each one, the values it expects, and what Google’s local business structured data documentation (last updated September 8, 2026) says about it. “Not in Google’s list” means the property is valid schema.org but is not one of the properties Google documents for local businesses.
| Property | Defined on | Expected values | Google’s local business documentation |
|---|---|---|---|
| servesCuisine | FoodEstablishment | Text | Recommended: the type of cuisine the restaurant serves |
| hasMenu | FoodEstablishment | Menu, Text or URL | Not in Google’s list. Google names the older menu property instead |
| menu | FoodEstablishment | Menu, Text or URL. Superseded by hasMenu | Recommended: the fully qualified URL of the menu |
| acceptsReservations | FoodEstablishment | Boolean, Text or URL | Not in Google’s list |
| starRating | FoodEstablishment, LodgingBusiness | Rating | Not in Google’s list. schema.org reserves it for official ratings from associations or standards bodies, not guest reviews |
| priceRange | LocalBusiness | Text | Recommended. Must be shorter than 100 characters |
| openingHoursSpecification | Place | OpeningHoursSpecification | Recommended. Seasonal hours use validFrom and validThrough |
| specialOpeningHoursSpecification | Place | OpeningHoursSpecification | Not in Google’s list. schema.org defines it to override regular hours |
| geo | Place | GeoCoordinates or GeoShape | Recommended. Latitude and longitude need at least five decimal places |
| amenityFeature | Place | LocationFeatureSpecification | Not in Google’s list |
| hasDriveThroughService | Place | Boolean | Not in Google’s list |
| areaServed | Organization and others | AdministrativeArea, GeoShape, Place or Text | Not in Google’s list |
| department | Organization | Organization | Recommended for a business with separate departments |
| suitableForDiet | MenuItem | Diet or RestrictedDiet | Not in Google’s list |
| aggregateRating, review | Organization and Place | AggregateRating, Review | Recommended only for sites that capture reviews about other local businesses |
Which details in older restaurant schema examples should you double-check?
Five details trip up many published restaurant schema examples. Check each one against the current vocabulary before you deploy.
- Diet values. The schema.org RestrictedDiet list has 11 values: DiabeticDiet, GlutenFreeDiet, HalalDiet, HinduDiet, KosherDiet, LowCalorieDiet, LowFatDiet, LowLactoseDiet, LowSaltDiet, VeganDiet and VegetarianDiet. Use HalalDiet and KosherDiet, because HalalFood and KosherFood are not schema.org terms.
- Circle radius. schema.org defines the GeoShape circle radius in meters, not miles. A 5 mile delivery circle is 5 x 1,609.344 = 8,046.72 meters, so write the radius as 8047.
- Labels that look like properties. A key that is not in the vocabulary, such as an explanatory label left in a copied template, is ignored at best. Delete it and keep one areaServed property.
- menu versus hasMenu. schema.org marks menu as superseded by hasMenu, while Google’s documentation still names menu. Using both with the same menu URL keeps you aligned with both.
- Coordinate precision. Google asks for at least five decimal places, so take latitude and longitude from your map pin (for example 40.71278) rather than a rounded city center value.
Schema Type 1: Restaurant (Core / NAP Schema)
What it is and what it does
The core Restaurant block is your NAP schema (Name, Address, Phone), your business hours, your cuisine type, your price range, and your geographic coordinates. It’s the foundation everything else builds on. Without it, none of the other schema types below deliver their full value. Google says local business markup can show business details, such as opening hours, in its knowledge panel.
Keep every value identical to your Google Business Profile, which is what Maps and the local pack show. In the table below, Required means required for a complete restaurant block: Google’s local business documentation (updated September 8, 2026) requires only name and address and lists telephone, openingHoursSpecification, geo, url, servesCuisine, priceRange and menu as recommended.
Knowledge Panel
Google Maps enhancement
AI search visibility
Voice search answers
| Property | Type | Status | What it does |
|---|---|---|---|
| @type | Text | Required | Must be “Restaurant”, not LocalBusiness or FoodEstablishment |
| name | Text | Required | Your exact restaurant name as registered and shown on GBP |
| address | PostalAddress | Required | Full street address, must match GBP exactly, character for character |
| telephone | Text | Required | Phone number in E.164 format (+1XXXXXXXXXX) |
| openingHoursSpecification | OpeningHoursSpecification | Required | Day-by-day hours, use this over openingHours for holiday exceptions |
| servesCuisine | Text | Recommended | Cuisine type(s), plain text, e.g. “Italian”, “Japanese”, “Mexican” |
| priceRange | Text | Recommended | Use $, $$, $$$, or $$$$, affects “affordable” vs “upscale” query matching |
| url | URL | Recommended | Your homepage canonical URL |
| image | URL or ImageObject | Recommended | Primary restaurant photo, triggers image in Knowledge Panel |
| geo | GeoCoordinates | Recommended | Latitude/longitude, critical for “near me” query matching |
| sameAs | URL[] | Recommended | Links to Yelp, TripAdvisor, Google Maps, Instagram, Facebook pages |
| hasMap | URL | Recommended | Your Google Maps embed or directions URL |
| currenciesAccepted | Text | Optional | Currencies you accept, e.g. “USD” |
| paymentAccepted | Text | Optional | Payment methods, e.g. “Cash, Credit Card, Contactless” |
| legalName | Text | Optional | Legal registered business name if different from trading name |
NAP consistency is non-negotiable. Your name, address, and phone number in this schema block must match exactly what’s on your Google Business Profile, every directory listing, and your website footer, same abbreviations, same punctuation, same street format. A discrepancy between “St.” and “Street” in two places is enough to create a trust signal conflict that suppresses local rankings. Check all three sources before deploying.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://www.yourrestaurant.com/#restaurant", "name": "The Golden Fork", "url": "https://www.yourrestaurant.com/", "telephone": "+12125559876", "email": "hello@yourrestaurant.com", "image": "https://www.yourrestaurant.com/images/restaurant-exterior.jpg", "priceRange": "$$", "servesCuisine": ["Italian", "Mediterranean"], "currenciesAccepted": "USD", "paymentAccepted": "Cash, Credit Card, Contactless", "address": { "@type": "PostalAddress", "streetAddress": "123 Main Street", "addressLocality": "New York", "addressRegion": "NY", "postalCode": "10001", "addressCountry": "US" }, "geo": { "@type": "GeoCoordinates", "latitude": 40.71278, "longitude": -74.00597 }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Tuesday", "Wednesday", "Thursday"], "opens": "12:00", "closes": "22:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Friday", "Saturday"], "opens": "12:00", "closes": "23:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": "Sunday", "opens": "11:00", "closes": "20:00" } ], "hasMap": "https://maps.google.com/?cid=YOUR_GOOGLE_CID", "sameAs": [ "https://www.yelp.com/biz/your-restaurant", "https://www.tripadvisor.com/Restaurant_Review-YOUR_ID", "https://www.facebook.com/yourrestaurant", "https://www.instagram.com/yourrestaurant" ] } </script>
Schema Type 2: AggregateRating Schema
What it is and what it does
AggregateRating is the second layer of restaurant schema markup and summarizes the reviews shown on your page as an average score and a review count. It does not earn star ratings for your own restaurant in Google Search. Google’s review snippet guidelines say that if the entity being reviewed controls the reviews about itself, its pages that use LocalBusiness or any other type of Organization structured data are ineligible for the star review feature. Mark it up only when it matches reviews visible on the page, and treat it as a description of your reputation, not a route to stars.
Where AggregateRating fits in your JSON-LD and what Google allows
This schema is nested inside your Restaurant block, not in a separate script tag. It must represent real, genuine reviews collected on your own website or through a structured review system. You cannot use third-party review aggregates (Yelp totals, Google Maps totals) in this schema unless you are the platform. Google will issue a manual action for fabricated or scraped ratings.
No stars for self-serving reviews
Trust signals for AI systems
| Property | Type | Status | Notes |
|---|---|---|---|
| ratingValue | Number | Required | Average rating, e.g. 4.7 |
| reviewCount | Integer | Required | Total number of reviews collected on your site. Google needs reviewCount or ratingCount |
| bestRating | Number | Recommended | Maximum possible rating, typically 5 |
| worstRating | Number | Optional | Minimum possible rating, typically 1 |
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.7, "reviewCount": 218, "bestRating": 5, "worstRating": 1 } } </script>
Schema Type 3: Menu Schema (hasMenu + MenuItem)
What it is and what it does
Menu schema tells Google what dishes you serve, at what price, and what dietary accommodations are available. Google’s structured data search gallery (checked October 2026) has no menu feature, so treat menu markup as a clear, machine-readable statement of your dishes for queries like “best pasta near me” or “vegan options downtown Austin.” In AI-powered search, a crawlable HTML menu page with matching menu schema helps systems like Google AI Overviews and ChatGPT answer “does [your restaurant] have gluten-free options?” accurately without the user visiting your site.
Which approach should you use: hasMenu URL or nested MenuItem?
There are two approaches. The lightweight approach uses the hasMenu property to link to your HTML menu page, Google crawls the page and extracts what it can. The comprehensive approach uses nested Menu, MenuSection, and MenuItem types in your JSON-LD to explicitly declare every dish. Generally, for most restaurants, the lightweight approach is the right starting point. Add explicit MenuItem markup for signature dishes and dietary-flagged items where guests most often ask about them, such as vegan or gluten-free dishes.
Dietary query matching
AI recommendation accuracy
“Near me” dish searches
| Property | Type | Status | Notes |
|---|---|---|---|
| hasMenu | URL or Menu | Recommended | URL of your HTML menu page, minimum required property |
| name | Text | Required (MenuItem) | Exact dish name as shown on your menu |
| description | Text | Recommended | Short dish description, what you’d print on a physical menu |
| offers | Offer | Recommended | Nested Offer with price and priceCurrency |
| suitableForDiet | RestrictedDiet | Recommended | Use schema.org values: VeganDiet, GlutenFreeDiet, HalalDiet, KosherDiet, VegetarianDiet |
| hasMenuSection | MenuSection | Optional | Logical menu sections, Starters, Mains, Desserts, Drinks |
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "menu": "https://www.yourrestaurant.com/menu/", "hasMenu": { "@type": "Menu", "name": "Dinner Menu", "hasMenuSection": [ { "@type": "MenuSection", "name": "Starters", "hasMenuItem": [ { "@type": "MenuItem", "name": "Truffle Arancini", "description": "Crispy risotto balls with truffle oil and parmesan", "suitableForDiet": "https://schema.org/VegetarianDiet", "offers": { "@type": "Offer", "price": "14.00", "priceCurrency": "USD" } } ] }, { "@type": "MenuSection", "name": "Pasta", "hasMenuItem": [ { "@type": "MenuItem", "name": "Cacio e Pepe", "description": "Tonnarelli with aged pecorino and black pepper", "suitableForDiet": "https://schema.org/VegetarianDiet", "offers": { "@type": "Offer", "price": "22.00", "priceCurrency": "USD" } }, { "@type": "MenuItem", "name": "Gluten-Free Rigatoni Bolognese", "description": "Traditional slow-cooked beef ragu on gluten-free pasta", "suitableForDiet": "https://schema.org/GlutenFreeDiet", "offers": { "@type": "Offer", "price": "26.00", "priceCurrency": "USD" } } ] } ] } } </script>
Which schema.org menu types does a restaurant website use?
A restaurant website uses three schema.org menu types: Menu for the whole menu, MenuSection for groups such as starters or drinks, and MenuItem for each dish. In schema.org 30.1, Menu and MenuSection hold dishes through hasMenuItem and groups through hasMenuSection, and a MenuItem takes offers, suitableForDiet, nutrition and menuAddOn.
The restaurant itself points to its menu in two ways. schema.org marks menu as superseded by hasMenu, while Google’s local business documentation still lists menu as the URL of your menu. The code above follows both: menu carries the menu page URL, and hasMenu carries the structured Menu.
| Type or property | What it holds | Where it goes |
|---|---|---|
| menu | The URL of your HTML menu page, the form Google documents | On the Restaurant |
| hasMenu | A Menu object, text or a URL; the current schema.org property | On the Restaurant |
| Menu | The whole menu, for example a dinner menu | As the value of hasMenu |
| MenuSection | A group of dishes, such as starters or pasta | In hasMenuSection on a Menu |
| MenuItem | One dish, with offers for the price and suitableForDiet for diet labels | In hasMenuItem on a Menu or MenuSection |
How do you handle menus and prices that change often in schema?
Handle frequent menu and price changes by building the menu markup from the same source that builds your menu page, so the page and the JSON-LD change together. If you cannot do that, mark up only the menu URL and a few stable dishes, because Google’s structured data guidelines say not to mark up content readers cannot see.
- One source of truth: render the menu page and the MenuItem markup from the same CMS fields, never from a copy pasted into a script by hand.
- Prices only where shown: add offers with price and priceCurrency only for dishes whose price appears on the page.
- Seasonal dishes: remove a MenuItem on the day the dish leaves the menu page.
- PDF menus: keep an HTML version as the page your menu and hasMenu URLs point to. Google’s guide to AI features asks for important content in text form.
- Your Business Profile menu: Google Business Profile Help says Google may transcribe menu data from your website, lets you pick a preferred menu when it finds several sources, and can take 24 to 48 hours to show menu editor changes. Check your profile after each menu change.
Schema Type 4: Review Schema (Individual Reviews)
What it is and what it does
What Review schema does that AggregateRating alone cannot
Where AggregateRating gives Google a summary score, Review schema marks up individual customer reviews on your site. This gives AI systems like Google AI Overviews and ChatGPT specific, quotable content about real dining experiences, which gets surfaced when users ask conversational questions like “what do people say about the food at X restaurant?” or “is X good for a date night?”
Individual review entries on your own restaurant site will not show as review rich results: Google treats reviews a business controls about itself as self-serving, and review snippets for local businesses are only for sites that capture reviews about other businesses. It reinforces your E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) signals by demonstrating that real humans have documented their real experience at your restaurant.
| Property | Type | Status | Notes |
|---|---|---|---|
| reviewRating | Rating | Required | The rating given in this specific review |
| author | Person | Required | Reviewer name, must be a real person, not “Anonymous” |
| reviewBody | Text | Recommended | The full review text visible on your page |
| datePublished | Date | Recommended | ISO 8601 format, e.g. 2026-04-15 |
| itemReviewed | Restaurant | Recommended | Link back to the Restaurant entity being reviewed. Google requires it when the review is not nested inside the Restaurant block |
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Review", "itemReviewed": { "@type": "Restaurant", "name": "The Golden Fork", "url": "https://www.yourrestaurant.com/" }, "reviewRating": { "@type": "Rating", "ratingValue": 5, "bestRating": 5 }, "author": { "@type": "Person", "name": "Sarah Mitchell" }, "datePublished": "2026-04-15", "reviewBody": "The cacio e pepe was the best I have had outside of Rome. The atmosphere is warm and intimate. We celebrated our anniversary here and felt actually looked after from start to finish." } </script>
Schema Type 5: Event Schema
What it is and what it does
Event schema is one of the most underused schema types for restaurants. When implemented correctly, it generates rich results in Google’s Events carousel, a completely separate discovery surface from standard web results that most restaurants completely miss. For example, if you run a jazz night every Thursday, a Sunday brunch pop-up, a Valentine’s Day dinner, or a wine tasting event, Event schema gets those listed in Google Events where users specifically searching for things to do in your city will find them.
Specifically, each individual event gets its own Event schema block. If you have a recurring event (every Thursday), you still need a new block with each occurrence’s specific date, because Google’s event documentation does not list eventSchedule. The same documentation, last updated September 8, 2026, says each event needs its own page, must be open to the public and must happen at a physical location. It also says not to mark business hours, discounts or coupons as events, so keep a regular happy hour out of Event markup.
Second organic presence
Event-intent discovery
Booking link in results
| Property | Type | Status | Notes |
|---|---|---|---|
| name | Text | Required | Event name, specific and descriptive |
| startDate | DateTime | Required | ISO 8601 with the local UTC offset, e.g. 2027-07-15T19:00:00-04:00 for 7pm in New York in summer |
| location | Place | Required | Your restaurant with full address |
| endDate | DateTime | Recommended | Same format as startDate |
| description | Text | Recommended | What the event includes, food, entertainment, ticket price |
| eventStatus | EventStatusType | Recommended | EventScheduled, EventRescheduled, EventPostponed or EventCancelled, the four values Google documents |
| eventAttendanceMode | EventAttendanceModeEnumeration | Recommended | Valid schema.org, but no longer in Google’s event documentation. Optional: OfflineEventAttendanceMode for in-person events |
| offers | Offer | Optional | Ticket price and booking URL |
| image | URL | Recommended | Event image, appears in the Events carousel |
| organizer | Organization | Optional | Link back to your Restaurant entity |
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Event", "name": "Thursday Jazz Night & Tasting Menu", "description": "Join us every Thursday evening for live jazz from 7pm alongside our five-course tasting menu. Tickets include wine pairing. Reservations essential.", "startDate": "2027-07-15T19:00:00-04:00", "endDate": "2027-07-15T23:00:00-04:00", "eventStatus": "https://schema.org/EventScheduled", "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode", "image": "https://www.yourrestaurant.com/images/jazz-night.jpg", "location": { "@type": "Place", "name": "The Golden Fork", "address": { "@type": "PostalAddress", "streetAddress": "123 Main Street", "addressLocality": "New York", "addressRegion": "NY", "postalCode": "10001", "addressCountry": "US" } }, "offers": { "@type": "Offer", "price": "95.00", "priceCurrency": "USD", "url": "https://www.yourrestaurant.com/reservations/", "availability": "https://schema.org/InStock" }, "organizer": { "@type": "Restaurant", "name": "The Golden Fork", "url": "https://www.yourrestaurant.com/" } } </script>
Schema Type 6: FAQPage Schema
What it is and what it does in 2027
What changed with FAQPage schema in May 2026
FAQPage schema marks up question-and-answer content on your website. On May 7, 2026, Google deprecated FAQ rich results entirely. The expandable Q&A boxes that used to appear in Google Search are gone for all websites. This completed a phase-out that started in August 2023 when Google restricted FAQ rich results to government and health sites only. The SERP display feature is dead.
However, the schema type itself is not deprecated. Google confirmed it continues to parse FAQPage markup to understand pages. There is no good evidence, though, that the markup increases AI citations. One test across 1,885 pages found that adding schema did not increase AI citations on any platform, and in one dataset the pages carrying FAQ schema averaged fewer ChatGPT citations, 3.6 against 4.2. The rich result is gone and the markup earns nothing today. The visible question-and-answer content on your page is a separate matter, and it is still worth having for guests. Keep your FAQPage markup. Do not remove it. Additionally, the schema must still match content visible on your page, since Google’s structured data guidelines on that point haven’t changed.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Do you accept walk-ins or is reservation required?", "acceptedAnswer": { "@type": "Answer", "text": "We welcome walk-ins at the bar and for early seating on weekday evenings. Friday and Saturday dinner service requires a reservation. Book online through our reservations page or call +12125559876." } }, { "@type": "Question", "name": "Do you have gluten-free or vegan options?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. We offer a dedicated gluten-free pasta menu and four vegan mains. All dietary items are clearly marked on our menu. Please inform your server of any allergies when seated." } }, { "@type": "Question", "name": "Is there parking nearby?", "acceptedAnswer": { "@type": "Answer", "text": "Street parking is available on Main Street and the adjacent side streets. The Civic Center garage two blocks north offers validated parking for dining guests. Ask your server for a validation stamp." } }, { "@type": "Question", "name": "Do you host private events and large group bookings?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Our private dining room seats up to 30 guests and is available for corporate events, birthdays, anniversaries, and rehearsal dinners. Contact events@yourrestaurant.com for availability and menu packages." } }, { "@type": "Question", "name": "Do you have outdoor seating?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Our front terrace seats 24 guests and is open from late spring through early autumn, weather permitting. Terrace tables cannot be reserved in advance. They are available on a first-come, first-seated basis." } } ] } </script>
Schema Type 7: amenityFeature (What Most Restaurant Schema Guides Miss)
What it is and what it does
amenityFeature is nested inside your restaurant schema markup block and describes the specific facilities and features your restaurant offers. This is the property that almost no restaurant website implements, and it’s the one that matters most for AI-powered query matching in 2026. When someone asks Google AI Overview “which Italian restaurants in Austin have outdoor seating and private dining?” or asks ChatGPT “find me a restaurant with live music and parking in downtown Chicago,” the restaurants with amenityFeature schema are the ones that get matched. The restaurants without it are invisible to those specific queries.
Specifically, amenityFeature uses LocationFeatureSpecification, which takes a name and a value (true or false). Include every feature that’s both true about your restaurant and visible on your website.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "amenityFeature": [ { "@type": "LocationFeatureSpecification", "name": "Outdoor Seating", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Private Dining Room", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Live Music", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Free WiFi", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Wheelchair Accessible", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Parking", "value": false }, { "@type": "LocationFeatureSpecification", "name": "Takeaway", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Delivery", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Full Bar", "value": true }, { "@type": "LocationFeatureSpecification", "name": "Kids Menu", "value": true } ] } </script>
Schema Type 8: BreadcrumbList Schema
What it is and what it does
BreadcrumbList is the final restaurant schema markup type and tells Google the navigational path to any page on your site. When present, Google displays breadcrumbs in your search result instead of the raw URL, “The Golden Fork > Menu > Pasta” instead of “www.yourrestaurant.com/menu/pasta/”. This improves click-through rates because the breadcrumb path communicates page context instantly. It also helps Google understand your site architecture, which contributes to crawl efficiency and indexing accuracy. Implement it on every interior page: menu pages, event pages, location pages, and blog posts.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.yourrestaurant.com/" }, { "@type": "ListItem", "position": 2, "name": "Menu", "item": "https://www.yourrestaurant.com/menu/" }, { "@type": "ListItem", "position": 3, "name": "Pasta", "item": "https://www.yourrestaurant.com/menu/pasta/" } ] } </script>
What does a verified 2027 restaurant JSON-LD block look like?
A verified block uses only current schema.org properties, follows the formats in Google’s local business documentation, and describes only what guests can see on the page. The block below meets all three: we parsed it as JSON and checked every property against the schema.org 30.1 vocabulary file, the coordinates have five decimal places, and the New Year’s Day closure uses the validFrom and validThrough pattern from Google’s documentation, with opens and closes both set to 00:00.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
"@id": "https://www.yourrestaurant.com/#restaurant",
"name": "The Golden Fork",
"url": "https://www.yourrestaurant.com/",
"telephone": "+12125559876",
"image": "https://www.yourrestaurant.com/images/dining-room.jpg",
"priceRange": "$$",
"servesCuisine": [
"Italian",
"Mediterranean"
],
"acceptsReservations": "https://www.yourrestaurant.com/reservations/",
"menu": "https://www.yourrestaurant.com/menu/",
"hasMenu": "https://www.yourrestaurant.com/menu/",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "New York",
"addressRegion": "NY",
"postalCode": "10001",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 40.71278,
"longitude": -74.00597
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Tuesday",
"Wednesday",
"Thursday"
],
"opens": "12:00",
"closes": "22:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Friday",
"Saturday"
],
"opens": "12:00",
"closes": "23:00"
},
{
"@type": "OpeningHoursSpecification",
"opens": "00:00",
"closes": "00:00",
"validFrom": "2027-01-01",
"validThrough": "2027-01-01"
}
],
"hasMap": "https://www.yourrestaurant.com/directions/",
"sameAs": [
"https://www.instagram.com/yourrestaurant",
"https://www.facebook.com/yourrestaurant"
]
}
</script>How to adapt it safely:
- Replace every value with your own details and keep the same menu URL in menu and hasMenu.
- Keep the closure entry only for dates you also show on your site and on your Google Business Profile, and change the dates every year.
- Delete any property you cannot back up with visible content, for example acceptsReservations if you do not take bookings.
- Validate the finished block, then check the live page with our free schema checker after you publish.
If you would rather fill in a form, the generator below builds a similar block from your details. Compare its output with the checklist above before you publish it.
Dynamic Restaurant Schema Generator
This free restaurant JSON-LD schema generator runs in your browser. Fill in your restaurant details below and click Generate. Your complete, copy-paste ready JSON-LD appears instantly. Replace all placeholder values before deploying.
The output always includes sample opening hours and four sample amenities, so edit them to match your restaurant or delete them. It writes your menu link as hasMenu; add a menu property with the same URL to match Google’s documentation.
Paste this inside your <head> tag or before your closing </body> tag. Validate at validator.schema.org before going live.
Where to place each schema type on your restaurant website
Notably, placement matters as much as the schema itself. Google recommends that JSON-LD lives in the <head> of your page, though it also accepts it in the <body>. The key rule is that the schema must appear on the same page as the content it describes. You can’t put your restaurant’s Menu schema on your homepage if the menu isn’t visible there.
| Schema type | Best page to place it | Also valid on |
|---|---|---|
| Restaurant (Core) | Homepage | Every page site-wide (via template) |
| AggregateRating | Homepage or Reviews page | Any page showing the star rating |
| Menu / MenuItem | Menu page | Homepage if menu is displayed there |
| Review (individual) | Reviews or testimonials page | Homepage if reviews displayed |
| Event | Individual event page, one event per URL | None for Google: its event experience only supports pages that focus on a single event |
| FAQPage | FAQ page | Any page with visible Q&A content |
| amenityFeature | Inside core Restaurant block on homepage | Location/about page |
| BreadcrumbList | Every interior page (via template) | Never on homepage |
Which restaurant rich results does Google support in 2027?
For a restaurant website, Google currently supports Local business, Event, Breadcrumb and Organization features, while review stars about your own restaurant, FAQ rich results and the restaurant carousel are not available to a typical restaurant site. Google’s structured data search gallery (last updated October 16, 2026) lists 25 features in total, and none of them is a menu feature.
| Markup | Google status (checked October 2026) | What a restaurant site can expect |
|---|---|---|
| Restaurant (a LocalBusiness type) | Supported as “Local business” in the search gallery | Eligible for business details in Google’s knowledge panel. Keep every value identical to your Google Business Profile |
| AggregateRating or Review about your own restaurant | Not eligible. Google treats reviews a business controls about itself as self-serving | No review stars from this markup, according to Google’s review snippet guidelines |
| Review on a site that reviews other restaurants | Supported for sites that capture reviews about other local businesses | A food guide or blog can qualify. Google added a guideline on fake and undisclosed incentivized reviews in July 2026 |
| Event | Supported as “Event” in the search gallery | Eligible for event features for dated public events such as tastings or live music nights |
| BreadcrumbList | Supported as “Breadcrumb” in the search gallery | Eligible for breadcrumb display on interior pages |
| Restaurant carousel | Limited. Google says it is currently limited to a small set of restaurant providers | Not something an individual restaurant site can opt into with markup |
| FAQPage | Removed. The FAQ rich result stopped appearing on May 7, 2026, and Google removed its documentation on June 15, 2026 | No visible feature. Keep the markup only where it matches a visible FAQ |
| Menu, MenuSection, MenuItem | No menu feature in the search gallery | Still valid schema.org. Google’s local business documentation covers only a menu URL |
| Organization | Supported as “Organization” in the search gallery | Useful on a restaurant group’s corporate homepage for its logo and business identity details |
| SpeakableSpecification | Listed in the search gallery | See the Speakable section above for why restaurants can skip it |
Two rules from Google’s structured data general guidelines sit above everything in this table. First, Google says “Using structured data enables a feature to be present, it does not guarantee that it will be present.” Second, do not mark up content that is not visible to readers of the page. Treat every rich result as possible, never promised.
You can follow these changes on Google’s Search documentation updates page, which logged both the FAQ deprecation and the July 2026 review guideline. For how these features fit a wider plan, see our structured data SEO guide, and for the FAQ change in detail, our guide to FAQ schema markup.
Can restaurant schema add a reservation or order button to Google?
No. Restaurant schema cannot add a Reserve or Order button to your Google listing. Google’s local business documentation says that to let people make a reservation or place an order directly in Search results, a business can use the Maps Booking API to enable bookings, payments and other actions. That runs outside your page markup. If you take orders through Toast, our guide to what Toast POS does explains how it handles online ordering and delivery.
The acceptsReservations property is still worth adding. schema.org accepts true, false or the URL of your booking page, and the verified block above uses the URL. Google’s local business property list does not include it, so treat it as a clear statement for any system that reads schema.org, not as a route to a button. If you want the button, check whether your reservation platform already connects to Google.
Does restaurant schema help you show up in AI answers?
No AI platform publishes a rule that schema markup earns citations, so treat any promise of AI visibility from markup alone with caution.
Google’s guide to its generative AI features, last updated July 10, 2026, says structured data is not required and there is no special schema.org markup to add, though it still helps pages qualify for rich results. The same guide says Google Business Profiles can help businesses show up in AI responses. Our AI search optimization guide covers what Google says you need.
What schema does reliably is state your facts (hours, address, cuisine, menu URL) in one consistent, machine-readable place that matches your page and your Google Business Profile.
The page content still has to answer the questions guests ask, such as whether you take reservations, have vegan dishes or offer private dining. Our guide to Google AI Overviews optimization covers the content side.
How to validate your restaurant schema before going live
Validation is mandatory, not optional
Specifically, a single missing comma, unclosed bracket, or mistyped property name breaks the entire JSON-LD block silently. Use validator.schema.org to check structural validity, and Google’s Rich Results Test (search.google.com/test/rich-results) to confirm which rich results your page qualifies for. Run both, fix every error, and re-check after deployment in Google Search Console under the Enhancements section.
Specifically, the three most common validation errors in restaurant schema markup are: missing commas between JSON properties, quotes used inconsistently (curly vs straight quotes cause parsing failures), and schema that describes content not visible on the page, for example, a dish in MenuItem markup that doesn’t appear on your published menu page. Google treats the third error as a spam signal and may ignore the markup entirely or issue a manual action.
How do you measure whether restaurant schema is working?
Measure restaurant schema in three layers: whether Google reads it (Rich Results Test and URL Inspection), whether it stays valid across the site (Search Console rich result reports), and whether the pages it describes earn clicks (the Performance report). Rankings alone will not tell you, because Google says structured data makes a feature possible but does not guarantee it.
Know one gap first. Search Console Help lists rich result reports for Breadcrumbs, Events and Review snippets, but none for local business markup (checked October 2026). Your Restaurant block has to be checked page by page.
This monthly routine covers every layer:
| What to check | Where | What good looks like | How often |
|---|---|---|---|
| The Restaurant block is read | Rich Results Test on the homepage and each location page | Local business detected with no critical issues | After every template, theme or plugin change |
| Google’s crawled version | URL Inspection in Search Console | The page is indexable and the structured data you expect is detected | After publishing changes |
| Breadcrumbs and events across the site | Search Console, Enhancements: the Breadcrumbs and Events reports | Valid items steady or rising, invalid items at zero | Monthly |
| Facts match everywhere | Your page, your JSON-LD and your Google Business Profile side by side | The same name, address, phone, hours and menu URL in all three | Monthly, and before every holiday |
| Clicks to the pages your schema describes | Performance report filtered to menu, location and event pages | Stable or rising clicks and impressions | Monthly |
| Visibility in AI features | Generative AI performance report in Search Console | How your restaurant pages appear in AI Overviews and AI Mode | Monthly |
Google’s local business documentation says to fix critical errors from the Rich Results Test, and that non-critical issues can improve quality but are not needed for eligibility. A warning about a missing recommended property is not a broken block. Between checks, our free schema checker tests markup against Google’s documented properties and flags duplicate markup from themes and plugins, and our technical SEO checklist covers the rest of the site.
Common restaurant schema mistakes that kill your rich results
With restaurant schema markup, one location means one schema block. Specifically, multi-location restaurants frequently make the mistake of placing a single global Restaurant schema block that covers all locations on every page. Google needs each location page to have its own unique Restaurant block with that location’s specific name, address, phone, hours, and a unique @id value. A schema block covering “all our locations” matches no location accurately and provides weaker local signals than none at all.
Stale hours, fake ratings, and markup-not-on-page: the three manual action triggers
Stale opening hours are the most common ongoing maintenance failure. When seasonal hours change, when a public holiday closure happens, or when a new late-night service starts, the schema must update to match. Google compares schema data to what it sees on your visible page and to your Google Business Profile. Discrepancies create trust conflicts that suppress your local rankings without any error appearing in Search Console.
AggregateRating from third-party platforms is not valid. You can only use reviews collected on your own website in your AggregateRating schema. Using your Google Maps rating count or your Yelp star average in your website schema violates Google’s guidelines. The penalty is a manual action, a human Google reviewer disabling your structured data enhancements.
Additionally, adding schema that isn’t on the page is a manual action risk. Every piece of information in your schema must correspond to content visible to any user on that page. This applies to everything: dish prices, dietary flags, opening hours, staff names. If it’s in the schema and a user can’t see it on the page, it’s ineligible and potentially penalized.
Restaurant schema for multi-location chains
Consequently, each physical location needs its own dedicated page with its own restaurant schema markup block. The parent brand gets an Organization schema block on the corporate homepage. Individual location pages inherit the brand’s identity via the parentOrganization property pointing back to the Organization entity. This structure tells Google that you’re a chain, what the parent brand is, and where each individual location sits in the entity graph.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Organization", "@id": "https://www.yourrestaurantchain.com/#organization", "name": "The Golden Fork Group", "url": "https://www.yourrestaurantchain.com/", "logo": "https://www.yourrestaurantchain.com/images/logo.png", "sameAs": [ "https://www.instagram.com/goldenforkgroup", "https://www.facebook.com/goldenforkgroup" ], "subOrganization": [ { "@id": "https://www.yourrestaurantchain.com/locations/manhattan/#restaurant" } ] } </script> <!-- On each individual location page: --> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://www.yourrestaurantchain.com/locations/manhattan/#restaurant", "name": "The Golden Fork Manhattan", "parentOrganization": { "@id": "https://www.yourrestaurantchain.com/#organization" }, "address": { "@type": "PostalAddress", "streetAddress": "123 Main Street", "addressLocality": "New York", "addressRegion": "NY", "postalCode": "10001", "addressCountry": "US" } } </script>
In the corporate block above, subOrganization lists each location. schema.org defines it as the inverse of parentOrganization, so the two blocks point at each other.
Each location page then carries its own hours, phone number and menu URL, matched to that location’s Google Business Profile. For how we run marketing for a restaurant group with several locations, see our multi-location restaurant marketing case study, and for the brand site around those pages, our guide to franchise SEO.
How do you add schema for a restaurant inside a hotel?
Mark up the hotel with the Hotel type and nest each restaurant or bar inside it with the department property, using Restaurant, BarOrPub or CafeOrCoffeeShop for each outlet. Google’s local business documentation recommends department for a business with separate departments, and schema.org describes a department as an organization in its own right, which allows a different URL, logo and opening hours.
Name each outlet the way Google asks: the main business name followed by the department name, for example “The Harbor Hotel Grill”. If the restaurant has its own brand, use that brand name on its own. Because department expects an Organization, and Restaurant is one through LocalBusiness, the outlet keeps every restaurant property, including servesCuisine, hasMenu and acceptsReservations.
| Setup | Markup on the hotel page | Restaurant markup |
|---|---|---|
| Hotel restaurant under the hotel brand | Hotel with a department entry | Restaurant named with the hotel name plus the restaurant name |
| Separately branded restaurant in the hotel | Hotel with a department entry, or containsPlace for the physical link | Restaurant under its own brand, with a full block on its own page |
| Lobby bar or cafe | Hotel with a department entry | BarOrPub or CafeOrCoffeeShop with its own hours |
| Hotel with several outlets | Hotel with a department array | One entry per outlet, each with its own hours and phone number |
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Hotel",
"@id": "https://www.yourhotel.com/#hotel",
"name": "The Harbor Hotel",
"url": "https://www.yourhotel.com/",
"telephone": "+13105550100",
"address": {
"@type": "PostalAddress",
"streetAddress": "500 Ocean Avenue",
"addressLocality": "Santa Monica",
"addressRegion": "CA",
"postalCode": "90401",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 34.01449,
"longitude": -118.49655
},
"department": [
{
"@type": "Restaurant",
"@id": "https://www.yourhotel.com/dining/#restaurant",
"name": "The Harbor Hotel Grill",
"url": "https://www.yourhotel.com/dining/",
"telephone": "+13105550101",
"servesCuisine": "Seafood",
"acceptsReservations": true,
"menu": "https://www.yourhotel.com/dining/menu/",
"hasMenu": "https://www.yourhotel.com/dining/menu/",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday",
"Saturday",
"Sunday"
],
"opens": "17:00",
"closes": "22:00"
}
]
},
{
"@type": "BarOrPub",
"@id": "https://www.yourhotel.com/lobby-bar/#bar",
"name": "The Harbor Hotel Lobby Bar",
"url": "https://www.yourhotel.com/lobby-bar/",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Thursday",
"Friday",
"Saturday"
],
"opens": "16:00",
"closes": "23:59"
}
]
}
]
}
</script>If the restaurant has its own page, add a full Restaurant block there as well and connect it to the hotel with containedInPlace. That property, and containsPlace on the hotel side, is the schema.org way to say one place sits inside another. Keep each outlet’s hours and phone number identical to its own Google Business Profile listing; our Google Business Profile optimization guide covers the profile side.
How do you add holiday hours and special closures to restaurant schema?
Holiday hours are the most common ongoing maintenance gap in restaurant schema. Most guides show regular weekly hours and stop there. Specifically, the correct pattern uses specialOpeningHoursSpecification, which schema.org defines as the property that overrides your standard openingHoursSpecification for specific dates. Google’s local business documentation does not list it, though.
Google’s own pattern for a closure is an openingHoursSpecification entry with validFrom and validThrough, used in the verified block above. Both patterns are valid schema.org, so pick one and use it consistently.
specialOpeningHoursSpecification vs openingHoursSpecification
Use openingHoursSpecification for your regular weekly hours. Use specialOpeningHoursSpecification for exceptions: holiday closures, reduced hours on public holidays, and seasonal shutdowns. The special property overrides the regular one for the specified date range. Never use specialOpeningHoursSpecification for standard hours.
For instance, to show a business as closed for a full day, set both opens and closes to "00:00". To show 24-hour operation, set opens to "00:00" and closes to "23:59".
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Tuesday","Wednesday","Thursday"], "opens": "12:00", "closes": "22:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Friday","Saturday"], "opens": "12:00", "closes": "23:00" } ], "specialOpeningHoursSpecification": [ { "@type": "OpeningHoursSpecification", "opens": "00:00", "closes": "00:00", "validFrom": "2026-12-25", "validThrough": "2026-12-25" }, { "@type": "OpeningHoursSpecification", "opens": "11:00", "closes": "17:00", "validFrom": "2026-11-26", "validThrough": "2026-11-26" } ] } </script>
How do you keep restaurant hours in sync across schema, your site and Google Business Profile?
Keep restaurant hours in sync by changing them in the same order every time: first the hours on your website, then the openingHoursSpecification in your JSON-LD, then your Google Business Profile. Google’s AI features guide asks for structured data that matches the visible text and for Business Profile details that are up to date, so all three must agree.
Use this table to decide what to change where. It covers the hours changes restaurants make most often.
| Situation | On your website | In your JSON-LD | In Google Business Profile |
|---|---|---|---|
| Regular weekly hours | Hours on the contact or location page | openingHoursSpecification with dayOfWeek, opens and closes | Regular business hours |
| Closed between lunch and dinner | Both time ranges for the day | Two openingHoursSpecification entries for the same days | Two entries for the same day, which Google calls business hour breaks |
| Open past midnight | Hours as guests read them, such as 6pm to 3am | One entry whose closes time is earlier than opens, as in Google’s late night example | Regular business hours for the day you open |
| Closed on a holiday | A dated notice on the page | An entry with validFrom and validThrough for that date, with opens and closes set to 00:00 | Special hours with the Closed box checked |
| Shorter hours on a holiday | A dated notice with the hours | An entry with validFrom, validThrough and the holiday hours | Special hours for that date |
| Open as usual on a public holiday | Nothing to change | Nothing to change | Confirm your hours for that holiday, which Google suggests even when they match your regular hours |
| Closed for more than 6 days, such as a renovation | A dated closure notice | An entry with validFrom and validThrough covering the closure | Special hours only cover up to 6 days in a row, so use the temporarily closed setting |
| Takeout, delivery or senior hours | The service hours as guests see them | Google documents no property for them, so keep them out of your opening hours | More hours for that service |
Before each holiday season, run this routine:
- List every date in the next two months when your hours differ from normal.
- Add a dated notice for each one to the page that shows your hours.
- Add the matching validFrom and validThrough entries to your JSON-LD and run the page through the Rich Results Test.
- Set the same dates as special hours in your Google Business Profile.
- After each date passes, remove the notice and the schema entry, so expired closures do not pile up in your markup.
Accurate hours also matter for Maps. Our guide to map pack SEO covers how hours affect the local 3-pack.
Three advanced schema properties every restaurant developer should implement
These three properties appear in zero restaurant schema guides currently ranking. They’re not optional extras, they’re the properties that separate a basic schema implementation from one that maximises AI citation accuracy and delivery-zone query matching.
1. ImageObject, structured photo markup
Typically, most restaurant schema uses a plain URL string for the image property. The structured ImageObject version is more precise, gives Google the exact dimensions for Knowledge Panel photo eligibility, and improves indexing accuracy for Google Images. Use it for your primary restaurant exterior or interior photo.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "image": { "@type": "ImageObject", "url": "https://www.yourrestaurant.com/images/exterior.jpg", "width": 1200, "height": 800, "caption": "The Golden Fork restaurant exterior, 123 Main Street New York" } } </script>
2. areaServed, delivery zone and service area markup
When and how to use areaServed for delivery zones
If your restaurant offers delivery, areaServed tells Google and AI systems exactly which neighborhoods, cities, or zones you serve. Without it, AI-powered delivery queries (“restaurants that deliver to [neighborhood]”) rely on inference. With it, you’re explicitly declared. Use a text array for named areas, or a GeoCircle with a midpoint and a radius in meters for precision delivery zones.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "areaServed": [ "Chelsea", "Hell's Kitchen", "Midtown Manhattan", "Murray Hill" ] } </script> <!-- OR, for a radius-based delivery zone, use a GeoCircle instead: --> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "The Golden Fork", "areaServed": { "@type": "GeoCircle", "geoMidpoint": { "@type": "GeoCoordinates", "latitude": 40.71278, "longitude": -74.00597 }, "geoRadius": 8047 } } </script> <!-- NOTE: Use EITHER the named areas OR the GeoCircle. Not both. --> <!-- geoRadius is in meters unless you give a Distance unit: 8047 meters is about 5 miles. -->
3. SpeakableSpecification, and why a restaurant can skip it
SpeakableSpecification is a Schema.org type that tags the sections of a page most suitable for text-to-speech delivery. Zero restaurant schema guides on the current SERP cover it, and that is defensible, because Google documents speakable for news publishers only. A restaurant is not eligible. It uses CSS selectors to point at specific page elements, and the code below is here so you can see what the type looks like rather than as a task to complete. Alexa and Siri do not read schema.org speakable at all. What actually answers a spoken question about your restaurant is the Restaurant block itself, with accurate opening hours and an accurate address.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "WebPage", "name": "The Golden Fork Italian Restaurant New York", "url": "https://www.yourrestaurant.com/", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".restaurant-name", ".opening-hours-summary", ".cuisine-type", ".hero-description" ] } } </script> <!-- Match CSS selectors to actual class names in your HTML --> <!-- These elements must be visible text on the page -->
How developers should implement restaurant schema in WordPress, Webflow, and custom builds
The implementation approach for restaurant schema markup matters as much as the content itself. A syntactically correct JSON-LD block that gets overwritten by a plugin, or that only fires on the homepage when it needs to fire on every location page, is as useless as no schema at all. Here’s the correct approach for each platform.
Which tools can add restaurant schema without code?
Three kinds of tools add restaurant schema without code: an SEO plugin’s schema module in WordPress, a page-level custom code field in a site builder such as Webflow, and a form-based generator like the one on this page. Each handles the core Restaurant block and leaves the advanced patterns in this guide to you.
| Tool type | Example | What it covers | What you still add by hand |
|---|---|---|---|
| WordPress SEO plugin | Rank Math’s Restaurant schema type | Name, description, phone, price range, address, geo coordinates, opening hours, cuisine and menu URL, according to Rank Math’s knowledge base | amenityFeature, areaServed, Menu and MenuItem, Event and multi-location links |
| Site builder custom code | Webflow page settings or a CMS Collection template | Any JSON-LD block you paste, including CMS-bound fields for each location | The JSON-LD itself, from the templates on this page |
| Form-based generator | The generator on this page | A Restaurant block with address, geo, cuisine, price range, menu URL and sameAs links | Your real hours and amenities, which it fills with samples |
| Validators | Google’s Rich Results Test, the Schema Markup Validator and our schema checker | Errors and warnings on the finished page | Fixes at the source, in the plugin or template that printed the markup |
Whichever tool you use, check the finished page for two business blocks. A plugin’s LocalBusiness block plus a hand-added Restaurant block on the same page gives Google two descriptions of one restaurant, so keep one and link everything else to its @id.
WordPress: three implementation tiers
Tier 1, Plugin (fastest, least control): RankMath or Yoast SEO generate basic Restaurant schema automatically from their LocalBusiness module. Generally, this is adequate for the core Restaurant block. Neither generates amenityFeature, areaServed, SpeakableSpecification, or multi-location parentOrganization patterns. Use this tier only if you won’t manually add the advanced blocks.
Tier 2, functions.php injection (recommended for custom control): Hook into wp_head and output JSON-LD programmatically. Consequently, this approach bypasses plugin interference, lets you conditionally fire different schema on different page types, and keeps schema decoupled from your template HTML.
<?php function hm_restaurant_schema() { if ( is_front_page() || is_page( 'about' ) ) { $schema = [ '@context' => 'https://schema.org', '@type' => 'Restaurant', '@id' => home_url( '/#restaurant' ), 'name' => get_bloginfo( 'name' ), 'url' => home_url( '/' ), 'telephone' => '+12125559876', 'servesCuisine' => [ 'Italian', 'Mediterranean' ], 'priceRange' => '$$', 'address' => [ '@type' => 'PostalAddress', 'streetAddress' => '123 Main Street', 'addressLocality' => 'New York', 'addressRegion' => 'NY', 'postalCode' => '10001', 'addressCountry' => 'US', ], 'geo' => [ '@type' => 'GeoCoordinates', 'latitude' => 40.71278, 'longitude' => -74.00597, ], ]; echo '<script type="application/ld+json">'; echo wp_json_encode( $schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE ); echo '</script>'; } } add_action( 'wp_head', 'hm_restaurant_schema' ); function hm_event_schema() { if ( is_singular( 'tribe_events' ) || is_page( 'events' ) ) { $event_schema = [ '@context' => 'https://schema.org', '@type' => 'Event', 'name' => get_the_title(), 'startDate' => '2027-07-15T19:00:00-04:00', 'location' => [ '@type' => 'Place', 'name' => get_bloginfo( 'name' ), ], ]; echo '<script type="application/ld+json">'; echo wp_json_encode( $event_schema, JSON_UNESCAPED_SLASHES ); echo '</script>'; } } add_action( 'wp_head', 'hm_event_schema' ); ?>
Tier 3, Elementor Custom HTML widget: For restaurants using Elementor where functions.php access isn’t available, paste each JSON-LD block into a Custom HTML widget placed in the page’s global header section or at the top of each relevant page. WordPress does not strip script tags from Custom HTML widgets. This is the method Curry Up Now and KHAKI use pending direct PHP access on those builds.
Webflow: Custom Code embed
Specifically, in Webflow, go to Page Settings for each page, scroll to Custom Code, and paste your JSON-LD blocks in the “Before </body> tag” field. For multi-location restaurant sites using Webflow CMS, use CMS Collection fields bound to schema properties and embed a JSON-LD template in the CMS Collection page template. The name, address, telephone, and geo values pull from CMS fields dynamically for each location.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Restaurant", "name": "{{wf {"path":"name"} }}", "telephone": "{{wf {"path":"phone"} }}", "address": { "@type": "PostalAddress", "streetAddress": "{{wf {"path":"street-address"} }}", "addressLocality": "{{wf {"path":"city"} }}", "addressRegion": "{{wf {"path":"state"} }}", "postalCode": "{{wf {"path":"postal-code"} }}", "addressCountry": "US" }, "servesCuisine": "{{wf {"path":"cuisine-type"} }}", "priceRange": "{{wf {"path":"price-range"} }}" } </script> <!-- CMS field names must match exactly. Create text fields in your CMS Collection for: name, phone, street-address, city, state, postal-code, cuisine-type, price-range -->
Custom builds (Next.js, Astro, vanilla HTML)
For custom-built restaurant sites, inject JSON-LD in the <head> element server-side for every page type. In Next.js, use the next/head component with dangerouslySetInnerHTML for each schema block. In Astro, output it directly in your layout’s <head>. The key principle across all frameworks: build a schema generation function that accepts restaurant data as a JavaScript object and returns the JSON-LD string. Never hardcode location-specific values in templates for multi-location builds.
function generateRestaurantSchema(restaurant) { const schema = { "@context": "https://schema.org", "@type": "Restaurant", "@id": `${restaurant.url}#restaurant`, "name": restaurant.name, "url": restaurant.url, "telephone": restaurant.phone, "servesCuisine": restaurant.cuisine, "priceRange": restaurant.priceRange, "address": { "@type": "PostalAddress", "streetAddress": restaurant.address.street, "addressLocality": restaurant.address.city, "addressRegion": restaurant.address.state, "postalCode": restaurant.address.postal, "addressCountry": restaurant.address.country, }, "geo": { "@type": "GeoCoordinates", "latitude": restaurant.lat, "longitude": restaurant.lng, }, }; if (restaurant.rating) { schema.aggregateRating = { "@type": "AggregateRating", "ratingValue": restaurant.rating.value, "reviewCount": restaurant.rating.count, "bestRating": 5, }; } if (restaurant.sameAs?.length) { schema.sameAs = restaurant.sameAs; } return `<script type="application/ld+json">${JSON.stringify(schema, null, 2)}</script>`; } const goldenFork = { name: "The Golden Fork", url: "https://www.yourrestaurant.com/", phone: "+12125559876", cuisine: ["Italian", "Mediterranean"], priceRange: "$$", lat: 40.71278, lng: -74.00597, address: { street: "123 Main Street", city: "New York", state: "NY", postal: "10001", country: "US" }, rating: { value: 4.7, count: 218 }, sameAs: ["https://www.yelp.com/biz/your-restaurant"], }; document.head.insertAdjacentHTML("beforeend", generateRestaurantSchema(goldenFork));
The @graph pattern for combining multiple schema types
When your page needs multiple schema types,, you can either use separate <script> blocks (the approach used throughout this guide) or combine them in a single @graph array. Google recommends the @graph pattern for connected entities because it explicitly links the Restaurant, WebPage, and Organization entities together through their @id values, which strengthens entity graph recognition.
<script type="application/ld+json"> { "@context": "https://schema.org", "@graph": [ { "@type": "Restaurant", "@id": "https://www.yourrestaurant.com/#restaurant", "name": "The Golden Fork", "url": "https://www.yourrestaurant.com/", "telephone": "+12125559876", "servesCuisine": "Italian", "priceRange": "$$", "address": { "@type": "PostalAddress", "streetAddress": "123 Main Street", "addressLocality": "New York", "addressRegion": "NY", "postalCode": "10001", "addressCountry": "US" } }, { "@type": "WebPage", "@id": "https://www.yourrestaurant.com/#webpage", "url": "https://www.yourrestaurant.com/", "name": "The Golden Fork Italian Restaurant New York", "about": { "@id": "https://www.yourrestaurant.com/#restaurant" }, "primaryImageOfPage": { "@type": "ImageObject", "url": "https://www.yourrestaurant.com/images/exterior.jpg", "width": 1200, "height": 800 } } ] } </script>
How does restaurant schema markup connect to your broader restaurant SEO strategy?
Specifically, schema markup is the technical foundation of restaurant SEO, not the whole strategy. It tells search engines what your restaurant is and where it sits. But visibility in local search, ranking in the map pack, appearing in AI recommendations, converting visits to reservations, requires the full SEO stack: schema-powered structured data, optimized Google Business Profile, on-page content targeting the right local keywords, review generation, citation consistency across directories, and content that builds topical authority in your cuisine and location.
If you’re implementing restaurant schema markup for the first time,, start there. Then audit whether your page content, GBP data, and directory listings all tell the same consistent story. Schema amplifies a well-built local SEO foundation. It doesn’t fix a weak one. For the full picture of what restaurant-specific SEO involves, our Restaurant SEO Agency page covers the complete service stack, and our broader SEO Agency page explains how technical SEO, content, and local signals work together for businesses in competitive markets.
Does schema markup replace Google Business Profile?
No, and that question matters because the two systems interact. Google Business Profile (GBP) is your primary data source for the local pack and Google Maps. Website schema is a secondary corroborating signal. When both agree, your schema address matches your GBP address exactly, Google’s confidence in your business data increases, which strengthens your local pack eligibility. When they conflict, neither performs well. The relationship isn’t GBP or schema. It’s GBP and schema, pointing at identical information.
Which are the best restaurant SEO agencies for schema and local search in 2027?
The best restaurant SEO agencies treat restaurant schema markup as a foundation, combining technical implementation (correct schema, structured data, site speed) with local authority building (GBP optimization, citation management, review strategy) and content that captures the specific search queries diners use. Generic SEO agencies that treat restaurants as just another local business miss the vertical-specific nuances: the menu page is your most important SEO asset, cuisine-type keywords behave differently from service-area keywords, and AI-powered dining discovery requires entity signals that standard local SEO doesn’t address. The five below have documented restaurant-specific work.
1. Hustle Marketers
Founded and led by Ishant Sharma, a performance marketer since 2013, Hustle Marketers is a Google Partner and Meta Business Partner agency with $780M+ in trackable client revenue across 2,500+ brands. The agency’s restaurant SEO practice runs the complete stack, schema implementation, GBP optimization, AI search visibility (structured data for ChatGPT, Perplexity, and Google AI Overviews), menu page SEO, local citation management, and content that targets cuisine-specific and location-specific queries. Active restaurant clients include Curry Up Now, a fast-casual Indian restaurant group operating across multiple US locations, and KHAKI Indian Bar & Canteen, where the work spans a 10-blog content plan, schema implementation, Google Business Profile audit, and landing pages for private dining and birthday events. The agency holds a Clutch-verified 5.0 rating and won six Clutch Global Awards in Spring 2026.
What separates the restaurant SEO work specifically: schema is treated as part of the entity architecture, every schema block uses @id to establish Knowledge Graph connections, sameAs arrays point to verified third-party profiles, and amenityFeature markup ensures the restaurant surfaces in AI-powered queries that generic schema implementations miss entirely. See the full Restaurant SEO service page for scope and process details.
2. Dine Rank
A restaurant-only SEO agency known for GBP management and local pack optimization across multi-location chains. Their narrow vertical focus means their keyword research, content templates, and link building strategies are built specifically around dining intent rather than adapted from generic local SEO playbooks.
3. UpCity-listed restaurant specialists
UpCity’s verified directory surfaces local SEO agencies with restaurant portfolio experience. For single-location independent restaurants with budgets under $1,500 per month, this is the right place to find regional specialists who understand the local dining competitive landscape in your specific market.
4. Thrive Agency
A full-service digital agency with a restaurant and hospitality practice covering SEO, paid search, and social media. Best suited for larger restaurant groups that want multiple channels managed under one roof with a dedicated account team rather than a specialist-first approach.
5. BrightLocal (for DIY restaurant SEO)
Not an agency but a platform worth naming for independent restaurant owners managing their own local SEO. BrightLocal’s citation builder, GBP audit tools, and rank tracking are the most restaurant-practical set of DIY tools available, and they integrate directly with schema validators to flag inconsistencies before they become ranking problems.
Why choose Hustle Marketers to implement restaurant schema markup and SEO?
We built this restaurant schema markup guide because restaurants consistently get schema wrong in the same ways: using LocalBusiness instead of Restaurant, skipping amenityFeature entirely, entering AggregateRating data from third-party platforms and triggering manual actions, and treating schema as a one-time setup rather than a living part of their technical SEO. Every JSON-LD block in this guide reflects the actual implementation standard we apply to restaurant clients.
With Curry Up Now, the schema implementation is part of a broader Webflow migration that required rebuilding URL inventory from scratch, creating location-specific schema blocks for each franchise location with unique @id values, and implementing GeoCoordinates that match GBP listings precisely. With KHAKI Indian Bar & Canteen, the schema build covers the Restaurant core block, Event schema for birthday and corporate dining landing pages, and FAQPage markup on a structured FAQ section, all validated in Search Console and matched against GBP data before any content campaign launched.
What correct schema implementation actually produces in search
In practice, the practical result of doing schema correctly before content: Google’s crawl budget goes to pages that return meaningful structured data, Knowledge Panel accuracy improves because schema and GBP are telling the same story, and AI dining recommendations start surfacing the restaurant for queries it was invisible to before, “Indian restaurant with private dining near [area]”, because amenityFeature and servesCuisine are now explicit declarations rather than inferences.
Hustle Marketers is a Google Partner, Meta Business Partner, and Microsoft Advertising Partner with a Clutch-verified 5.0 rating and six Clutch Global Awards in Spring 2026. Upwork Top Rated Plus, 100% Job Success Score, plus 591+ combined client reviews across platforms. If your restaurant’s schema is untested, inconsistent with your GBP data, or simply missing, request a free SEO audit. We’ll identify every structured data gap, flag inconsistencies between your schema and GBP, and show you exactly which rich results your pages qualify for, before you commit to anything.
Frequently asked questions about restaurant schema markup
Restaurant schema markup is structured JSON-LD code added to a restaurant website that describes the business to search engines and AI systems using the standardized Schema.org vocabulary. It tells Google your name, address, phone, hours, cuisine type, price range, and more in a machine-readable format, enabling rich results in search.
Yes. For restaurant schema markup specifically, Google explicitly recommends JSON-LD over Microdata and RDFa. JSON-LD sits in a script tag separate from your HTML, which means it doesn’t break when your design changes and is much easier to validate and maintain.
Use Restaurant. It’s the most specific type in the Schema.org hierarchy for a restaurant business, and Google’s local business documentation asks for the most specific LocalBusiness subtype. It does not unlock a special rich result, but LocalBusiness and FoodEstablishment describe your business less precisely. Restaurant inherits all the properties of both parent types, so you don’t lose anything by being more specific.
No. Only mark up reviews that are published and visible on your own page, never your Google Maps or Yelp totals. Even genuine reviews on your own site will not earn review stars, because Google treats reviews a business controls about itself as self-serving, so LocalBusiness and Organization pages are ineligible for the star review feature.
Maintenance and ongoing management questions
Any time your visible page content changes, your schema must update to match. This includes opening hours changes, seasonal menu updates, price changes, and any time you add or remove amenities. Stale schema that conflicts with your page content or Google Business Profile creates trust signal conflicts that suppress local rankings.
Schema, rankings, and AI visibility questions
Schema markup is not a direct ranking factor in Google’s algorithm the way backlinks or page speed are. What it does is qualify your pages for rich results (such as event features and breadcrumbs) that dramatically improve click-through rate, and higher CTR does correlate with improved rankings over time as a behavioral signal.
NAP stands for Name, Address, Phone, the three core data points in your Restaurant schema block. NAP consistency means those three values match exactly across your website schema, Google Business Profile, and every directory listing. Inconsistencies across sources reduce Google’s confidence in your business information and suppress local pack rankings.
The cleanest method is to add JSON-LD directly via a Custom HTML block or a child theme’s header.php file. Yoast SEO and Rank Math both generate basic LocalBusiness schema automatically, but neither produces the complete Restaurant-specific schema stack with Menu, amenityFeature, and Event types. For full control, implement JSON-LD manually and use Yoast’s custom schema field for blocks that don’t fit their standard generator.
It can help, but not on its own. Google says there is no special schema.org markup needed for its AI features, and that structured data should match the visible text on your page. A restaurant with complete schema, including amenityFeature, servesCuisine, openingHoursSpecification, and acceptsReservations, states those facts in one consistent place that assistants can check against your page and your Google Business Profile.
Syntax errors (missing commas, unclosed brackets) cause the entire JSON-LD block to fail silently, Google ignores it completely. Policy violations (fabricated ratings, schema describing content not on the page) risk manual actions that disable your structured data enhancements entirely. Always validate with both validator.schema.org and Google’s Rich Results Test before deploying.
Both approaches work. You can nest AggregateRating, amenityFeature, and Menu inside a single Restaurant block, which is the cleanest approach. Event schema and FAQPage schema are always separate blocks since they represent different entity types. BreadcrumbList is always its own block on each page it applies to.
No. A restaurant database schema is the table design behind an ordering, POS or reservation system, such as tables for menu items, orders and customers. Restaurant schema markup is schema.org vocabulary added to web pages as JSON-LD so search engines can read your business details. The two can share data, but they do different jobs.
LocalBusiness is the schema.org type for a business with a physical location, and Restaurant sits two levels below it, through FoodEstablishment. Restaurant schema is local business schema with food properties added, such as servesCuisine, hasMenu and acceptsReservations. Use the most specific type that fits, because it keeps every LocalBusiness property available.
Not on its own. Google’s local business documentation says the restaurant carousel is currently limited to a small set of restaurant providers, and providers register interest with Google. An individual restaurant site cannot opt in with markup, so focus on accurate Restaurant markup that matches your visible pages and your Google Business Profile.