LocalBusiness Schema: A Copy-Paste Example for Restaurants and Cafés

Main Street Cited · Updated September 23, 2026

This is a working example you can copy, edit and paste into your own site. It's built directly from schema.org's own type definitions and Google's structured data documentation, not guesswork, and we'll flag the small mistakes that make this kind of markup silently useless.

Which type to use

Restaurants and cafés both sit under FoodEstablishment, which is itself a type of LocalBusiness. Schema.org's own reference traces the chain as Thing → Organization/Place → LocalBusiness → FoodEstablishment → Restaurant, and lists food-specific properties like servesCuisine, acceptsReservations and hasMenu that plain LocalBusiness doesn't have (schema.org/Restaurant). If you're a coffee shop rather than a full restaurant, use CafeOrCoffeeShop instead of Restaurant; everything else below stays the same.

Why bother? Restaurants and cafés live or die on questions like "is it open now," "do they take reservations," and "what's on the menu" — exactly the questions a search engine or an AI assistant has to answer from whatever's on your page. Plain paragraph text technically contains that information, but a labeled, structured field removes the guesswork. That's the whole point of schema: it's the same facts, written once, in a shape machines don't have to interpret.

What's required versus what's recommended

According to Google's own LocalBusiness structured data documentation, only name and address are required for eligibility. Google recommends adding openingHoursSpecification (as a structured object with dayOfWeek, opens and closes, not a sentence of text), telephone with country and area code, geo coordinates, priceRange, and a working url — noting plainly that "the more properties you provide, the higher quality the result is to users" (Google Search Central).

The example

Paste this inside your homepage's <head>, and replace every value with your own real information:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Name Restaurant",
  "url": "https://www.example-restaurant.com",
  "telephone": "+1-555-123-4567",
  "priceRange": "$$",
  "servesCuisine": ["Italian", "Pizza"],
  "acceptsReservations": "True",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Springfield",
    "addressRegion": "CA",
    "postalCode": "94000",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.7749,
    "longitude": -122.4194
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Sunday"],
      "opens": "11:00",
      "closes": "21:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "11:00",
      "closes": "22:00"
    }
  ]
}
</script>

For a café, change "@type": "Restaurant" to "@type": "CafeOrCoffeeShop" and drop acceptsReservations if it doesn't apply.

Mistakes that quietly break this

We've read a lot of real restaurant sites' markup while building our free checker, and the same handful of mistakes show up again and again:

Address as a plain string instead of a PostalAddress object. "address": "123 Main St, Springfield, CA" validates as JSON, but it's much harder for machines to reliably pull a street, city or ZIP code out of a sentence than out of labeled fields. Use the nested object shown above.
Hours as a loose string. "openingHours": "Mon-Fri 9-5" is technically a valid schema.org property, but Google's documentation recommends the structured openingHoursSpecification form instead, precisely because day and time abbreviations are inconsistent and hard to parse reliably.
Phone number on the wrong node. On sites built from multiple JSON-LD blocks (common with page builders and some POS-provided widgets), we've seen the phone number sit on a separate Organization block while the Restaurant/LocalBusiness block that actually describes the business has no telephone field at all. A tool reading the business listing itself won't find it.
Copy-pasting another business's schema and forgetting to change every field. Double-check the address, phone and geo coordinates before you publish; a template's placeholder values are worse than having none.

How to check your work

Two quick checks before you publish. First, confirm it's valid JSON: paste the block between the <script> tags into any JSON validator, or just view your live page's source and make sure nothing got mangled by your page builder (a stray smart quote or trailing comma is enough to break the whole block). Second, confirm the fields are actually populated the way you intend, not left as placeholders. Our own free checker does both: it parses JSON-LD and microdata the same way this guide describes and tells you in plain English exactly which fields, if any, are missing. Google's structured data documentation pages also link out to their own testing tools if you want a second opinion.

One honest caveat, straight from Google: valid markup "enables a feature to be present" in search results, but "does not guarantee that it will be present" (Google Search Central). Correct schema makes you easier to read, for search engines and AI assistants alike. It isn't a lever that forces a placement, and anyone who tells you otherwise is guessing.

Not sure if your markup is right?

Our free checker parses your homepage's JSON-LD and microdata and tells you exactly what's there and what's missing. If you'd rather we just write it for you, the AI Visibility Kit is a flat $149.

Run the free check Get it fixed: AI Visibility Kit, $149