Restaurant schema markup: menus and opening hours explained
A customer can read your menu and still leave because the branch identity, hours or dish availability is unclear to search and AI systems. The fix starts with accurate, consistent facts.
Nexara gives restaurants Restaurant, Menu and MenuItem structured data with real availability through its restaurant order and operations platform, built in Amman, Jordan. It sits beside the till and provides Arabic and English storefronts for restaurants in Jordan and the Arabic-speaking Middle East. Markup cannot secure recommendations; keep your published facts accurate.
Figures in this post are illustrative examples, not a client's actual results.
Which structured data does a restaurant website need?
Structured data labels facts on a website with a shared vocabulary. Schema.org supplies types such as Restaurant and MenuItem, while JSON-LD is a common publishing format. The practical test is whether the facts describe the branch a customer can actually order from.
| Type or field | What it describes | What an assistant can understand |
|---|---|---|
| Restaurant | The restaurant or individual branch | Which business and location the page describes |
| name, alternateName | The public name and another established name | How Arabic and English references identify the same restaurant |
| address, telephone, url | The branch location, contact number and website | Where the restaurant is and how to reach it |
| openingHoursSpecification | Days and opening and closing times | The published hours for that location |
| Menu, MenuSection, MenuItem | The menu, sections and individual dishes | Which dishes belong to which menu |
| offers | A dish's price, currency and availability | What an item costs and whether it is available |
Restaurant connects to a menu through hasMenu. A Menu can contain MenuSection entries, and each section can contain MenuItem entries. This makes a dish's name and price readable as separate facts. A photographed menu needs equivalent readable information on the page.
Schema.org uses openingHours for a text schedule and openingHoursSpecification for a detailed schedule. Capitalisation matters when preparing the markup.
What does a small schema.org Restaurant example look like?
This compact JSON-LD example describes one branch, one daily schedule and one menu item. The .example address is a placeholder. Publish the information as JSON-LD alongside matching visible restaurant details.
{ "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://weibdehkitchen.example/#restaurant", "name": "Weibdeh Kitchen", "alternateName": "مطبخ اللويبدة", "url": "https://weibdehkitchen.example/", "address": {"@type": "PostalAddress", "streetAddress": "12 Example Street, Jabal Al-Weibdeh", "addressLocality": "Amman", "addressCountry": "JO"}, "openingHoursSpecification": {"@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"], "opens": "12:00", "closes": "23:00"}, "hasMenu": {"@type": "Menu", "name": "Main menu", "hasMenuSection": {"@type": "MenuSection", "name": "Main dishes", "hasMenuItem": {"@type": "MenuItem", "name": "Chicken musakhan meal", "alternateName": "وجبة مسخن دجاج", "offers": {"@type": "Offer", "price": "6.50", "priceCurrency": "JOD", "availability": "https://schema.org/InStock"}}}} }
The @id gives the restaurant a stable reference. The address identifies its location, while priceCurrency makes the dinar price explicit. Availability belongs to the item's Offer. Add the real telephone number and keep the listed price consistent with the portion shown to customers.
How should Arabic names, branches and hours be handled?
Use the restaurant name customers see on the sign and Google Business Profile. In the example, name carries the English name and alternateName carries the Arabic name. Language-specific pages can lead with their own language while referring to the same branch identity.
Avoid adding search phrases to the business name. If the sign says Weibdeh Kitchen, inserting “best delivery restaurant Amman” creates a different name to reconcile. Translate dish descriptions carefully so a meal and a sandwich remain distinguishable in both languages.
Give each physical branch its own Restaurant entry and stable @id, preferably on a dedicated branch page. Put that branch's address and hours on the same page. A shared brand can have different closing times and item availability at different locations.
Use separate openingHoursSpecification entries when days have different schedules. Use specialOpeningHoursSpecification for date-specific exceptions such as public holidays or Ramadan changes. Check any service that crosses midnight.
A branch's opening time and delivery ordering window can differ. Make both visible and label them clearly. The ordering path should check whether that branch can accept a delivery order near closing time.
How does readable information become an agent order?
An AI assistant can search for a suitable restaurant, compare dishes or submit an order with the customer's permission. Structured data helps it read the published facts. An ordering path supplies the steps needed to finish the purchase.
Every Nexara restaurant storefront is orderable by AI agents that speak ACP (2026-04-17), UCP or MCP: live menu, delivery quote, cash-on-delivery or pay-at-counter order into the kitchen queue, server-side pricing; anonymous agents verify the customer's Jordanian phone by SMS code, trusted platforms complete with a key.
The order prints in the kitchen and appears on the order board with an AI agent badge. The Nexara agent ordering page explains this path.
Nexara storefronts publish Restaurant, Menu and MenuItem structured data with real availability alongside agent discovery files and bilingual llms.txt. The restaurant llms.txt guide explains how that reference directs an agent to relevant pages.
What should you check before publishing?
Check the information as an owner before validating its format. A validator can identify vocabulary or formatting errors, but it cannot tell whether the kitchen stopped serving a dish yesterday.
- Write one clear entity sentence: restaurant name, cuisine, neighbourhood and city. Use the same facts on the website and Google Business Profile.
- Open each branch page. Compare its address and contact number with the public listing, and confirm that the phone reaches someone who can help.
- Compare the readable menu with the structured menu. Check portion names, modifier choices and JOD prices against what customers can order.
- Check availability at branch level. A dish sold out in one location should have the correct status wherever that location's menu is published.
- Review normal hours and dated exceptions. Confirm delivery cutoffs with the person accepting orders.
- Ask your website provider to run Schema Markup Validator. Use Google's Rich Results Test for supported Google features.
- Review the published page after corrections. Keep Google profile details, public hours and review responses current.
Keep one person responsible for these checks when prices or hours change. The restaurant AI discovery guide covers wider preparation, including a clear business identity and consistent public listings.
What does Nexara handle, and what should you prepare?
Prepare established Arabic and English names, accurate branch details, current menus and public hours. Maintain your Google Business Profile, answer reviews and make sure the published phone reaches a person. These facts remain the restaurant team's responsibility.
Nexara's storefront can publish the menu, modifiers and per-branch availability in Arabic and English. It is built in Amman for restaurants in Jordan and the Arabic-speaking Middle East; live deployments are in Jordan. Learn more on the Nexara features page and about Nexara.
To discuss your restaurant with Nexara at nexaratech.io, send your website or menu link and branch details through WhatsApp. Founder Issa Al-Dalu answers support and can discuss how your menu and ordering path would fit a Nexara storefront.
What to remember
- Use Restaurant to identify each branch and MenuItem to describe individual dishes.
- Publish consistent Arabic and English names, accurate hours and JOD prices.
- Check structured availability against what the branch can actually serve.
- Nexara storefronts connect readable menus with an agent ordering path.
Questions people ask
Which schema should I use for a restaurant website?
Use Restaurant for the branch identity and Menu with MenuItem entries for dishes. Include accurate contact details, opening hours and item offers with prices, currency and availability.
Is OpeningHours a separate schema type?
The relevant properties are openingHours and openingHoursSpecification. The latter uses OpeningHoursSpecification entries to describe days and opening and closing times.
Can I put Arabic and English names in restaurant schema markup?
Yes. name and alternateName can express established names, while Arabic and English pages can present their corresponding language. Keep both connected to the same branch identity.
Does every restaurant branch need separate structured data?
Each physical branch should have its own Restaurant entry with a distinct identity and accurate local details. That lets its address, hours and menu describe the correct location.
Is a PDF menu enough for AI to understand my dishes?
A text-based PDF may be readable, but a web menu with MenuItem entries gives each dish explicit fields for its name and offer. Keep those fields consistent with the customer-facing menu.
How do I show that a dish is available at one branch?
Use the branch's own Restaurant and MenuItem data, then set the item's Offer availability to match that branch. Check the structured status against what the kitchen can actually sell.