Restaurant Schema Markup: Complete 2026 Guide (With Copy-Paste Code)
Ishant
Published : June 13, 2026 at 6:19 am
Updated : June 13, 2026 at 6:30 am
Ishant
Ishant Sharma is the Founder and CEO of Hustle Marketers, a Google Partner digital marketing agency. With 12+ years of experience in Google Ads, Meta Ads, SEO, and e-commerce PPC, he has helped 2500+ brands generate $780M+ in trackable revenue. Upwork Top Rated Plus with 99% Job Success Score. Ishant Sharma is the digital marketing specialist, not the Indian cricketer of the same name.
Summarize this blog post with:
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 8 schema types: Restaurant (NAP core), AggregateRating, Menu/MenuItem, Review, Event, FAQPage, amenityFeature, and BreadcrumbList. 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 2026. 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 2026, voice search answers, and Knowledge Panel entries. Restaurants without restaurant schema markup are invisible to the matching systems that now power the majority of dining discovery. 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.
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.
What is restaurant schema markup and why does it matter in 2026?
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, the star ratings, price range indicators, cuisine types, and hours that appear directly in search results, are driven by schema, not by text content alone.
In 2026 specifically, the stakes are higher because schema now feeds systems beyond Google’s traditional index. ChatGPT, Perplexity, Google AI Overviews, Gemini, and Apple Intelligence all pull from structured data when making restaurant recommendations. A restaurant without schema is invisible to those recommendation systems regardless of how good its website content is.
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” unlocks restaurant-specific rich results that the parent types don’t qualify for. 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.
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 uses this block to populate your Knowledge Panel, your Google Maps listing, the local pack in search results, and AI recommendation responses.
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.7128, "longitude": -74.0060 }, "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 displays star ratings in your Google search listing. Consequently, it’s the single highest-impact schema type for click-through rate. Research consistently shows rich results with star ratings receive around 58% of all clicks on a page, compared to 41% for plain blue-link results. When your search listing shows 4.6 stars alongside your result, it stands out visually from every other plain-text competitor on the same page.
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.
Higher click-through rate
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 |
| 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 can display menu items directly in search results for queries like “best pasta near me” or “vegan options downtown Austin.” In AI-powered search, menu schema is what allows systems like Google AI Overviews and ChatGPT to 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 rich results would be most valuable.
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, HalalFood, KosherFood, 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", "hasMenu": "https://www.yourrestaurant.com/menu/", "menu": { "@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>
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 in restaurant schema markup can also appear as rich results in certain contexts, showing a specific review excerpt alongside your search listing. 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 |
<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, or use eventSchedule for recurring patterns. Google Events is indexed separately from your web pages, giving you a second organic presence for every event you mark up.
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 timezone offset, e.g. 2026-07-15T19:00:00-05:00 |
| 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, EventPostponed, EventCancelled, EventMovedOnline |
| eventAttendanceMode | EventAttendanceModeEnumeration | Recommended | 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": "2026-07-17T19:00:00-05:00", "endDate": "2026-07-17T23:00:00-05: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 2026
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. More importantly, FAQ schema is now primarily valuable for AI citation. When someone asks ChatGPT, Perplexity, Google AI Overviews, or Apple Intelligence a question about your restaurant (“Does [restaurant] have outdoor seating?”), well-structured FAQPage schema gives those AI systems explicit question-answer pairs to cite accurately. The rich result is gone. The AI citation value is higher than ever. 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>
Dynamic Restaurant Schema Generator
Fill in your restaurant details below and click Generate. Your complete, copy-paste ready JSON-LD appears instantly. Replace all placeholder values before deploying.
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 or Events listing page | Homepage if upcoming events shown |
| 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 |
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.
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" ], "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Restaurant Locations" } } </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>
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 Google explicitly defines as the property that overrides your standard openingHoursSpecification for specific dates. This is the PAA question with zero clean answers in the current SERP.
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>
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 neighbourhoods, cities, or zones you serve. Without it, AI-powered delivery queries (“restaurants that deliver to [neighbourhood]”) rely on inference. With it, you’re explicitly declared. Use a text array for named areas, or a GeoShape with a circle radius 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" ], "areaServed_GeoShape_example_use_one_not_both": { "@type": "GeoShape", "circle": "40.7128 -74.0060 5" } } </script> <!-- NOTE: Use EITHER the text array OR the GeoShape circle. Not both. --> <!-- GeoShape circle format: "latitude longitude radiusInMiles" -->
3. SpeakableSpecification, voice assistant optimisation
SpeakableSpecification is a newer Schema.org type that explicitly tags the sections of your page most suitable for text-to-speech delivery by voice assistants. Zero restaurant schema guides on the current SERP cover it. It uses CSS selectors to point at specific page elements, your restaurant name, cuisine type, and opening hours summary are the ideal targets. Specifically, when Google Assistant, Alexa, or Siri reads your restaurant information aloud, SpeakableSpecification is the markup that guides what gets read and how.
<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.
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.7128, 'longitude' => -74.0060, ], ]; 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' => '2026-07-17T19:00:00-05: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.7128, lng: -74.0060, 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, optimised 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 2026?
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 optimisation, 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 optimisation, 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 optimisation 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, 99% Job Success Score across 591+ reviews. 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 unlocks restaurant-specific rich results that LocalBusiness and FoodEstablishment don’t qualify for. Restaurant inherits all the properties of both parent types, so you don’t lose anything by being more specific.
No. Google’s guidelines allow AggregateRating only for reviews collected on your own website. Using third-party platform ratings violates Google’s structured data policies and risks a manual action that disables your rich results. Only mark up reviews that are verifiably published and visible on your own domain.
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 (star ratings, price ranges, event carousels) 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.
Yes, significantly. Voice search answers and AI assistant responses (ChatGPT, Perplexity, Google AI Overviews, Apple Intelligence) pull heavily from structured data. A restaurant with complete schema, including amenityFeature, servesCuisine, openingHoursSpecification, and acceptsReservations, gets matched to far more query types than one that relies on text content alone.
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.