A diner in Austin asks Perplexity, "best Neapolitan pizza near downtown for a Wednesday date night." Three seconds later, the AI returns four restaurants with cuisine, price band, hours, and a one-line summary. One of them is the new pizzeria that opened six weeks ago. Two of them are not the local favorites the owner knows about. Why? The AI did not crawl Yelp or Google's local pack to build that answer. It read the schema markup on each restaurant's website, pieced together the structured facts, and cited the sites whose Restaurant JSON-LD answered the question cleanly. The owner of the local favorite that did not appear has no idea what schema markup is.
Key Takeaways
- Google explicitly recommends JSON-LD over Microdata or RDFa as the easiest structured-data format to maintain (Google Search Central, updated December 2025).
- The schema.orgRestauranttype is aLocalBusinesssubtype that inherits properties formenu,servesCuisine,acceptsReservations,aggregateRating, andopeningHoursSpecification(Schema.org v30.0, March 2026).
- AI Overviews fired on 15.69% of US queries in November 2025 (peaking at 24.61% in July) across a 10-million-keyword sample (Semrush AI Overviews Study, 2025).
- "Food near me open now" Google searches grew 875% year over year, and overall restaurant queries climbed 33% YoY (Search Engine Land, 2025).
- Pages withFAQPageschema appear approximately 3.2Γ more often in Google AI Overviews than pages without it, per industry analysis (Frase, citing Search Engine Land 2024 content analysis).
What Is Restaurant Schema Markup, In Plain Terms?
Restaurant schema markup is a block of structured-data code that tells search engines and AI systems the discrete facts about your restaurant: name, address, hours, cuisine, menu items, reservation URL, price band, and rating. It is written in JSON-LD and pasted in the <head> of each page. When ChatGPT, Perplexity, Google AI Overviews, or Gemini build an answer about restaurants in your city, they look for this structured data because it is faster and more reliable than parsing your homepage prose.
Three formats exist β JSON-LD, Microdata, and RDFa. Google supports all three but states plainly that "JSON-LD (Recommended)" is the easiest "to implement and maintain at scale" (Google Search Central, 2025). Most modern restaurant website builders default to JSON-LD. The vocabulary itself comes from schema.org, the cross-engine standard (Schema.org, 2026).
Citation Capsule: Google recommends JSON-LD for structured data because it is the easiest format to maintain at scale, and the schema.org
Restauranttype (aLocalBusinesssubtype) is the canonical vocabulary search engines and AI systems read to extract restaurant facts (Google Search Central, 2025; Schema.org, 2026).
Why Does Schema Markup Matter For AI Search Specifically?
Because AI Overviews and chat answers cite differently than the classic blue links. They want clean, parseable facts. A page with Restaurant JSON-LD plus an FAQPage block hands the AI a ready-made answer. A page that buries those facts in prose forces the AI to guess, and the AI's tolerance for ambiguity is low.
The traffic stakes have shifted hard. Across a 10-million-keyword sample tracked by Semrush, AI Overviews appeared in 6.49% of US queries in January 2025, peaked at 24.61% in July, and settled at 15.69% by November (Semrush, 2025). For restaurants, the demand-side numbers are louder still: "food near me open now" was up 875% year over year, "food near me" up 99%, and total restaurant-related Google searches up 33% YoY in 2025 (Search Engine Land, 2025). The volume is moving to discovery surfaces that prefer structured data.
Schema markup feeds three different AI surfaces
Each surface reads schema slightly differently:
- Google AI Overviews. Synthesises an answer from Google's index. Prefers pages with clean schema, often quotes them, and cites a small set of source URLs.
- Perplexity, ChatGPT Search, and Gemini. Crawl the open web (often via Bing or Common Crawl), pull schema where present, and link directly to source pages.
- Knowledge panels and Google rich results. Display structured data as visual cards in classic search.
The same Restaurant block helps all three. The same FAQPage block helps all three. Building the schema once unlocks every downstream surface. (For the parallel Google-side optimisation that lives off your website, see the Google Business Profile checklist.)
The FAQPage edge
Pages with FAQPage markup appear about 3.2 times more often in Google AI Overviews than pages without it, per industry analysis (Frase, citing Search Engine Land's 2024 content analysis). The mechanism is that Q&A pairs are pre-formatted answers; the AI treats them as drop-in citations. Most restaurant sites have no FAQ schema at all.
What Properties Does The Schema.org Restaurant Type Include?
The Restaurant type sits at the bottom of two parallel chains: Thing β Organization β LocalBusiness β FoodEstablishment β Restaurant and Thing β Place β LocalBusiness β FoodEstablishment β Restaurant (Schema.org, 2026). Inheriting from both means every property on those parents is available on Restaurant.
Google's LocalBusiness documentation calls out two required and ten recommended properties for the Restaurant subtype (Google Search Central, 2025):
| Property | Required? | What it does |
|---|---|---|
@type (Restaurant) |
required | Tells search engines this is a restaurant, not a generic business |
name |
required | Display name in rich results |
address (PostalAddress) |
required | Drives map results, knowledge panel, and AI location matching |
aggregateRating |
recommended | Star rating in rich results and AI cards |
geo (latitude / longitude) |
recommended | Improves "near me" matching |
menu |
recommended | URL to the menu page; the AI follows this to extract items |
openingHoursSpecification |
recommended | Powers the "Open until 11" badge and "open now" filters |
priceRange |
recommended | Shown as "$$", "$$$" in cards and AI summaries |
servesCuisine |
recommended | Critical for cuisine-based AI queries |
telephone |
recommended | Click-to-call in mobile rich results |
url |
recommended | Canonical website URL |
acceptsReservations |
recommended | Boolean or URL; surfaces "Reserve a table" buttons |
Restaurant also inherits properties Google does not explicitly call out but AI systems read: hasMenu (linking to a Menu object with MenuSection and MenuItem children), starRating (for Michelin-style awards), paymentAccepted, currenciesAccepted, and smokingAllowed. The schema.org page documents all of them (Schema.org, 2026).
How Do You Write Restaurant JSON-LD That Validates?
Paste this block in the <head> of your homepage. Replace the placeholder strings with your real values. It validates against Google's Rich Results Test and covers every required and recommended property.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "Olmo Pizzeria",
"url": "https://www.olmopizzeria.com",
"image": "https://www.olmopizzeria.com/images/storefront.jpg",
"telephone": "+1-512-555-0142",
"priceRange": "$$",
"servesCuisine": ["Italian", "Neapolitan Pizza"],
"acceptsReservations": "https://www.olmopizzeria.com/reserve",
"menu": "https://www.olmopizzeria.com/menu",
"address": {
"@type": "PostalAddress",
"streetAddress": "1418 East 6th Street",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78702",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.2640,
"longitude": -97.7245
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Tuesday","Wednesday","Thursday"],
"opens": "17:00",
"closes": "22:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Friday","Saturday"],
"opens": "17:00",
"closes": "23:00"
}
],
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "284"
}
}
</script>
A few things worth pointing out. The address is a nested PostalAddress object, not a free-text string β the AI uses every component for matching. openingHoursSpecification is an array of objects per shift, not one string with commas. aggregateRating requires both ratingValue and reviewCount; if you fake either, Google will throw a structured-data error and may demote the page. Use real numbers from your real reviews.
A separate Menu block for granular AI citations
If you want AI systems to cite individual dishes ("the carbonara at Olmo is $24"), add a Menu object referenced from hasMenu. This is heavier but pays back on niche queries:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Menu",
"name": "Olmo Pizzeria Dinner Menu",
"hasMenuSection": [
{
"@type": "MenuSection",
"name": "Pizzas",
"hasMenuItem": [
{
"@type": "MenuItem",
"name": "Margherita",
"description": "San Marzano tomato, fior di latte, basil, extra-virgin olive oil",
"offers": {
"@type": "Offer",
"price": "18.00",
"priceCurrency": "USD"
}
},
{
"@type": "MenuItem",
"name": "Carbonara Pizza",
"description": "Guanciale, pecorino, egg yolk, black pepper",
"offers": {
"@type": "Offer",
"price": "24.00",
"priceCurrency": "USD"
}
}
]
}
]
}
</script>
Menu schema is best maintained as a separate block on a dedicated /menu page, not inlined on the homepage. That way you only update one place when prices change.
A FAQPage block to triple your AI Overview odds
Industry analysis suggests FAQPage markup correlates with roughly 3.2Γ higher AI Overview presence (Frase, citing 2024 Search Engine Land data). Treat your most-asked questions as a paste-ready answer the AI can quote:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does Olmo Pizzeria take reservations?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Reserve up to 30 days ahead at olmopizzeria.com/reserve. Walk-ins are accepted at the bar."
}
},
{
"@type": "Question",
"name": "What is Olmo Pizzeria's price range?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most pizzas are $18 to $24. A two-person dinner with a glass of wine averages $70 before tip."
}
}
]
}
</script>
The text answer must match what is visible elsewhere on the page. Google's structured-data guidelines require the answer to be on the same URL β hidden FAQ schema gets penalised. Keep the answers under 200 words each.
How Do You Audit A Restaurant Site For Schema Errors?
A live audit is the fastest way to spot what is missing. Take any restaurant URL and run it through three tools, in this order:
- Google Rich Results Test β paste the URL, see which rich-result types are detected, and read the error and warning panel.
- Schema.org Validator β broader syntax check; catches schema.org-valid blocks that Google ignores.
- Search Console Enhancements report β once the site is verified, this surfaces the historical error rate and which URLs are affected.
Three categories of issue dominate restaurant sites:
Category 1: Missing Restaurant block entirely
The site uses generic LocalBusiness or no schema at all. Symptom: no rich results detected, AI Overview citations go to competitors. Fix: paste the homepage Restaurant block above.
Category 2: Schema present but invalid
address written as a free-text string instead of a PostalAddress object. openingHoursSpecification malformed. aggregateRating missing reviewCount. priceRange set to "moderate" instead of "$$". Fix: rewrite the offending property to match Google's example syntax exactly, then re-test.
Category 3: Schema valid but thin
Only the required name and address fields populated. No menu, no servesCuisine, no aggregateRating. Symptom: knowledge panel exists but is sparse, and AI summaries skip your restaurant for ones with richer markup. Fix: add the recommended properties one at a time, retest after each.
A useful benchmark: when auditing the top three results in your local pack for a "[cuisine] near me" query, you will usually find one with a complete Restaurant block, one with partial markup, and one with none. The gap is the opportunity.
Which Schema Errors Should You Fix First?
Use this decision tree to triage. Work top to bottom; fix the first issue, retest, then move on.
| Symptom in Rich Results Test | Likely cause | Fix |
|---|---|---|
| "Required field 'name' or 'address' missing" | Block fails the minimum schema requirement | Add both fields; re-test |
| "Field 'address' is the wrong type" | address written as a string |
Convert to nested PostalAddress |
| "Invalid value in field 'openingHoursSpecification'" | Single-string opening hours instead of array of objects | Restructure as array of OpeningHoursSpecification objects |
| "Field 'aggregateRating' missing required field 'reviewCount'" | Rating present without count | Add reviewCount from your real review platform |
| "Field 'priceRange' has an invalid value" | Free text like "moderate" or "expensive" | Use "$", "$$", "$$$", or "$$$$" |
| Page loads but no rich result detected | JSON-LD inside body or commented-out | Move script to <head>; remove HTML comments |
| FAQ block detected but ineligible | Answer not visible on page | Add the FAQ to the visible HTML, not just JSON-LD |
The Rich Results Test treats unfixed warnings as a quiet vote against you. A clean pass on every page is the realistic target.
How Should You Structure Schema Across A Multi-Page Restaurant Site?
Restaurants typically have a homepage, a menu page, a reservations page, an about page, and sometimes a private-events page. Each gets a different schema mix:
- Homepage:
Restaurantblock (complete, withaggregateRating,menu,acceptsReservations). - Menu page:
Menublock referenced byhasMenufrom the homepageRestaurant. List every section and every dish withoffersif prices are stable. - Reservations page: Add a
ReservationActionto the homepageRestaurantblock pointing here. The page itself does not need its own block. (Choosing reservation software is its own decision; either way the schema URL stays the same.) - About page: Add
Personschema for the chef or owner, withjobTitleandworksForlinking to the homepage Restaurant. AI cites named people more often than anonymous brands. - Blog or recipe content: Use
ArticleorRecipeschema per page. Both feed AI Overviews on long-tail content queries.
The whole site ends up as a small graph: each page has a block, blocks reference each other via @id. AI systems traverse the graph, which is why a coherent set of blocks beats a single bloated homepage block.
What Common Mistakes Sink Restaurant Schema?
A short list of issues that cost real visibility:
- Stuffing the same block into every page. Duplicate
Restaurantblocks on every URL confuses search engines about which page is canonical. Use one homepage block, then page-specific schema (Menu, Article, Person) on the rest. - Faking the
aggregateRating. Google compares schema-claimed ratings against the live review platforms it crawls. A claimed 4.9 with a real 4.1 triggers a structured-data demotion. - Leaving
priceRangeblank. AI systems use this to filter "casual," "mid-range," and "fine dining" queries. No price band means you do not appear in any of them. - Ignoring
openingHoursSpecification. "Open now" is the single highest-conversion search modifier (Search Engine Land, 2025). Without correct hours, you are invisible to it. - Missing FAQs. The 3.2Γ AI Overview lift is the single largest schema multiplier available, and most restaurant sites skip it.
- Not retesting after a redesign. Theme changes routinely break schema. Run the Rich Results Test the day after every site update β and pair it with a Core Web Vitals check since heavy JavaScript redesigns often degrade both at once.
If a builder generates schema for you, ask the vendor which properties it populates by default. DineHere's website builder, for example, auto-generates Restaurant, Menu, LocalBusiness, and FAQPage JSON-LD with the operator's real menu items, hours, and reservations URL β but whichever tool you use, the validation steps above still apply.
How Do You Measure Schema's Impact?
Schema does not show up in conventional analytics. The signals are downstream:
- Search Console β Performance report. Filter by query containing "near me" or "[your cuisine]" and watch impressions month over month after a schema fix.
- Search Console β Enhancements. Tracks every schema type detected, with errors and warnings split per URL. Aim for green across the board.
- Brand search lift. Search for
[your restaurant name]and check if a knowledge panel appears. If yes, yourRestaurantblock is being read. - AI surface checks. Quarterly, ask Perplexity, ChatGPT, and Google AI Overviews a query you should rank for ("best [cuisine] near [neighbourhood]") and see whether you are cited.
- Reservation referral lift. A bigger schema block usually drives more direct reservation traffic. Track
/reservepage entrances by source in GA4.
The fastest meaningful signal is the Search Console Enhancements report; it usually moves within ten days of a schema deployment.
Frequently Asked Questions
What schema type should restaurants use β LocalBusiness or Restaurant?
Restaurant is a subtype of LocalBusiness. Use Restaurant because it inherits all LocalBusiness properties and adds restaurant-specific ones like servesCuisine and acceptsReservations. Google's documentation explicitly recommends using "the most specific LocalBusiness sub-type possible" (Google Search Central, 2025).
Where do you put restaurant schema markup on a page?
In a <script type="application/ld+json"> tag inside the <head> of the HTML. Google supports schema in the body too, but <head> is the convention and avoids issues with body-rendering JavaScript stripping the block.
Will schema markup directly improve my Google ranking?
Schema is not a direct ranking factor in classic blue-link results, but it controls eligibility for rich results, knowledge panels, and AI Overview citations β all of which drive traffic. Indirectly, the visibility lift is real.
How do I add FAQ schema for my restaurant?
Pick the 6 to 10 questions guests ask most (reservations, price, dietary, parking, dress code), write a 1 to 3 sentence answer for each, paste the JSON-LD FAQPage block in the <head>, and add the same Q&A as visible HTML on the page. Test in Google's Rich Results Test before publishing.
Does Google still show menu rich results for restaurants?
Google has continued to show restaurant cards with embedded menu data in some queries, particularly for "menu" and "[restaurant name]" searches. Even when no rich result fires, AI systems use Menu JSON-LD to answer dish-specific queries. Maintain the markup either way.
How often should I update restaurant schema?
Update the moment any underlying fact changes β new hours, a moved address, a price increase across the menu, a fresh aggregate review count. Beyond that, audit quarterly for schema.org spec changes and yearly for Google guidance changes.
Can schema markup hurt my site if it is wrong?
Yes. Misleading or invalid schema (faked ratings, hidden FAQ answers, mismatched address) can trigger manual or algorithmic penalties. Google's structured-data spam policy is explicit. The fix is accuracy, not omission.
What is the difference between schema markup and Google Business Profile?
Schema lives on your website and feeds search engines and AI. Google Business Profile lives on Google's servers and feeds Google Maps and the local pack. They overlap in some fields (name, address, hours) and complement in others (schema includes menu items; GBP includes Q&A). Both need to be accurate. The GBP-side checklist is a separate exercise; the website speed pillar covers the technical-SEO angle that schema slots into.
Do AI Overviews always cite the highest-ranked Google result?
No. AI Overviews cite a small set of sources chosen for answer-fit, not for blue-link rank. Pages with cleaner schema and tighter Q&A blocks often get cited above pages that rank higher in classic search.
How long until schema changes show up in Google's results?
Search Console usually detects new structured data within 7 to 10 days of crawling the page. Rich result eligibility follows immediately after detection. AI Overview citations are fuzzier β typically 2 to 6 weeks before noticeable change.
