Restaurant Schema Markup Guide: LocalBusiness JSON-LD Without Fake SEO

Structured data is a way to describe restaurant facts in a machine-readable format. It is not a secret keyword layer. For a restaurant, Google supports LocalBusiness structured data and recommends using the most specific subtype available. In most restaurant cases, that means using Schema.org's Restaurant type rather than stopping at a generic LocalBusiness. The restaurant website grader checks the initial HTML for Restaurant, FoodEstablishment or LocalBusiness structured-data signals. This guide explains what good implementation is trying to achieve. ## Use JSON-LD unless your architecture requires another supported format Google supports JSON-LD, Microdata and RDFa for structured data, and generally recommends JSON-LD because it is easier to maintain separately from visible markup. A simplified restaurant example: ```json { "@context": "https://schema.org", "@type": "Restaurant", "name": "Example Restaurant", "url": "https://example.com/", "telephone": "+1-416-555-0100", "servesCuisine": "Italian", "address": { "@type": "PostalAddress", "streetAddress": "123 King St W", "addressLocality": "Toronto", "addressRegion": "ON", "postalCode": "M5V 1J5", "addressCountry": "CA" } }

- do not publish hours in schema that contradict visible hours;
- do not mark up a Toronto location on a Vancouver page;
- do not add services the restaurant does not provide;
- do not create menu/pricing information only for crawlers. Structured data should reduce ambiguity, not manufacture relevance. ## Core Restaurant properties The right property set depends on the page, but useful restaurant facts often include: ### Name
Use the actual public restaurant name. ### URL
Point to the canonical restaurant/location URL. ### Address
Use a `PostalAddress` with accurate street, locality, region, postal code and country where applicable. ### Telephone
Use the location's actual customer-facing phone number in an international-friendly format where possible. ### Opening hours
Represent opening hours accurately. If hours change temporarily, the visible customer information still needs to be correct. ### Cuisine
`servesCuisine` can help identify the restaurant's actual cuisine. Use meaningful descriptions rather than keyword lists. ### Image
Use representative images that users can access. ### Menu
Schema.org Restaurant supports menu-related properties/URLs. Keep the linked menu current and canonical. ### Geo coordinates
For physical locations, geographic coordinates can remove location ambiguity when accurate. ## Multiple restaurant locations Each physical location should have its own correct facts. A strong location implementation has: - a unique canonical location URL;
- that location's name where brand/location naming differs;
- street address;
- phone;
- hours;
- geo coordinates;
- menu/order/reservation links relevant to the location;
- `Restaurant` structured data that matches the visible location content. Do not put one corporate address into every location's Restaurant object. ## Hours need special care Restaurant hours are one of the most volatile business facts. If the website has schema hours generated from a different system than the visible hours, drift becomes possible. Ideally both are rendered from the same canonical operating data. JSON-LD that updates automatically while the visible footer stays wrong is not a successful implementation. The guest experience still loses. ## Menu URL versus menu content A Restaurant object can point users/search engines toward a menu, but that does not replace a useful menu page. The menu URL should lead to a real, crawlable menu experience where possible. If every location has a different menu, point each location to its correct menu. See [restaurant menu SEO](/blog/restaurant-menu-seo). ## Price range Schema.org supports `priceRange`. If you use it, keep it meaningful and aligned with the customer experience. A vague or stale price-range string is not worth maintaining just to fill another property. ## Aggregate ratings are easy to misuse Do not scrape third-party review-platform ratings and mark them up as though the restaurant's page owns an eligible review aggregate without understanding Google's review-snippet policies. Self-serving review markup for LocalBusiness/Organization entities has restrictions. Structured-data eligibility changes over time, so check Google's current documentation before adding review markup solely to chase stars in search. ## Organization versus Restaurant A multi-location restaurant group may have organization-level data for the brand and Restaurant data for each physical venue. Those concepts can coexist. Avoid merging every entity into one overloaded object where addresses/hours from several locations become ambiguous. Use stable `@id` values if your graph architecture links entities together. The goal is a coherent graph, not the largest graph. ## Validate the markup Before publishing: 1. test the live page with Google's Rich Results Test where the type is supported;
2. validate the JSON syntax;
3. inspect the rendered HTML to ensure the script is present;
4. compare every important schema fact with the visible page;
5. monitor Search Console after rollout for structured-data errors. Google recommends monitoring Search Console after deploying structured data or changing templates. ## Structured data is not a ranking guarantee Valid schema can help Google understand a page and can make pages eligible for supported search features. It does not guarantee a rich result and does not replace content, links, reputation or usefulness. If a restaurant has a slow, stale website with hidden hours and a broken menu, adding a large JSON-LD object does not solve the customer problem. ## A Restaurant schema maintenance checklist - Type is `Restaurant` when appropriate.
- Name matches the public business.
- URL is canonical.
- Address belongs to this location.
- Phone belongs to this location.
- Hours match the visible site.
- Cuisine is accurate.
- Menu URL works.
- Images are accessible.
- No fabricated ratings/offers.
- Multi-location entities are not mixed together.
- Markup remains present after frontend/template changes. ## Sources and further reading - [Google Search Central: LocalBusiness structured data](https://developers.google.com/search/docs/appearance/structured-data/local-business)
- [Google Search Central: General structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [Schema.org Restaurant](https://schema.org/Restaurant)
- [Restaurant website SEO checklist](/blog/restaurant-website-seo-checklist)
- [Restaurant website grader](/blog/restaurant-website-grader) ## FAQs ### Should a restaurant use Restaurant or LocalBusiness schema?
`Restaurant` is a more specific subtype of LocalBusiness and is generally the appropriate type when the entity is a restaurant. Use the most specific accurate type for the page/entity. ### Can structured data include information that is not shown to users?
Structured data should accurately represent the page and entity. Do not use machine-only facts to mislead search engines or contradict what users can see. ### Does valid Restaurant schema guarantee a rich result?
No. Valid structured data can create eligibility for supported features, but Google does not guarantee that a rich result will appear.