← Blog
· Restaurant websites· 5 min read

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

A practical Restaurant structured data guide covering LocalBusiness subtype choice, name, address, phone, hours, menu, images, location markup, visible-content consistency and common JSON-LD mistakes.

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:

{
  "@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 copy that example literally. Replace every fact with the restaurant's real visible information.

The markup must match the restaurant users see

Google's structured-data policies require the markup to describe the page and content accurately.

That means:

  • do not mark up a fake five-star rating;
  • 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.

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

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.

Tell Kitch what needs to happen.

Start Kitch →
Restaurant Schema Markup Guide: LocalBusiness JSON-LD Without Fake SEO | Kitch