Free Restaurant Schema Generator

Why many restaurant pages underperform

How SwiftSchema helps

How it works

When to use Restaurant schema (and when not to)

• Use it on location-specific pages that show the restaurant’s name, address, phone, hours, cuisine, and menu. One page per location is best.
• If you have a group/chain homepage, pair Organization/LocalBusiness with links to each location; apply Restaurant on each location page.
• Avoid using Restaurant on blog posts, general landing pages, or pages without the full address and operating info visible.
• If the location is closed permanently, remove or update the page and schema; for temporary closures, note it on-page and in openingHoursSpecification.

Key properties to get right

• Name: Match the storefront/brand exactly. Avoid keyword stuffing (“Best Italian Restaurant Austin”) in name.
• Address: Provide a full PostalAddress with street, locality (city), region (state), postal code, and country. Keep it identical to what users see on the page and maps listings.
• Telephone: Use a reachable, local-format phone where possible.
• Opening hours: Use 24-hour format strings like Mo-Fr 11:00-22:00. List separate blocks for weekend or split shifts (e.g., Sa 10:00-14:00, Sa 17:00-23:00).
• ServesCuisine: Add 1–3 primary cuisines. Avoid huge lists.
• Menu: Link to an HTML menu you control; PDFs are acceptable but less crawlable.
• Price range: Use $, $$, $$$ to set expectations.
• AggregateRating (optional): Only if you collect genuine, policy-compliant reviews. Include both ratingValue and ratingCount.
• Reservations: If you support reservations, add a ReserveAction via potentialAction or set acceptsReservations: true.

On-page parity checklist

• The same NAP (name, address, phone) appears in the page body and footer.
• Hours on-page match openingHours exactly. If special hours exist, surface them visibly and in JSON-LD.
• Menu link in schema matches the visible menu link.
• Any ratings displayed to users match the values in aggregateRating (no self-serving or third-party scraped reviews).
• If you list delivery partners, ensure URLs are correct and consistent with on-page mentions.

JSON-LD examples

Minimal single-location

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Pasta Palace",
  "url": "https://www.pastapalace.example/locations/downtown",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "telephone": "+1-512-555-0100",
  "servesCuisine": ["Italian"],
  "openingHours": ["Mo-Fr 11:00-22:00", "Sa-Su 10:00-23:00"],
  "priceRange": "$$",
  "hasMenu": "https://www.pastapalace.example/menu"
}

With AggregateRating, menu, and reservations

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Pasta Palace",
  "image": [
    "https://www.pastapalace.example/images/dining-room.jpg",
    "https://www.pastapalace.example/images/lasagna.jpg"
  ],
  "url": "https://www.pastapalace.example/locations/downtown",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "telephone": "+1-512-555-0100",
  "servesCuisine": ["Italian", "Seafood"],
  "openingHours": [
    "Mo-Fr 11:00-22:00",
    "Sa 10:00-23:00",
    "Su 10:00-21:00"
  ],
  "priceRange": "$$",
  "hasMenu": "https://www.pastapalace.example/menu",
  "acceptsReservations": true,
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "ratingCount": "287"
  },
  "potentialAction": {
    "@type": "ReserveAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://www.pastapalace.example/reserve?location=downtown&date={date}&party={partySize}"
    }
  }
}

Multi-location guidance

Create a dedicated page per location and place Restaurant JSON-LD on each. On the parent locations page, you can include an ItemList of LocalBusiness/Restaurant entries or link to each child page without duplicating full details.

Implementation steps (detailed)

1. Prepare inputs: Name, canonical URL, images, full address, local phone, hours, cuisines, menu URL, optional rating counts, reservation URL.\n2) Check on-page parity: Ensure all the above appear on the page and match what users see.\n3) Generate JSON-LD: Use this guide’s generator with Restaurant selected. Paste accurate values.\n4) Add branding: Include a logo via Organization/LocalBusiness on the page or globally so knowledge panels can associate brand assets.\n5) Place schema once per page: Put the Restaurant JSON-LD in the <head> or before closing </body> on the location page.\n6) Validate: Run the page through Rich Results Test and ensure no errors or unexpected warnings.\n7) Publish and re-crawl: Request indexing in Search Console after material updates.\n8) Monitor: Track impressions/clicks for brand queries and map-like surfaces; update hours and menu promptly.

Common mistakes to avoid

• Incomplete address: Omitting postal code or country leads to ambiguity. Always provide all address fields.
• Mismatched hours: Schema hours differ from the visible hours or Google Business Profile — update all three together.
• Menu URLs that 404 or require login: Keep menu public and crawlable; avoid heavy PDF sizes where possible.
• Self-serving reviews: Only include ratings you are allowed to publish and that reflect real customer feedback.
• Using a single page for multiple locations: This dilutes relevance. Create one page per location, each with unique NAP and schema.
• Keyword stuffing in name: Stick to the real business name.

Troubleshooting

• Warnings about openingHours: Ensure the 24-hour format with day abbreviations (Mo, Tu, We, Th, Fr, Sa, Su) and ranges like 11:00-22:00. Separate distinct ranges with semicolons in the UI; in JSON-LD, use multiple strings in the array.
• Mixed address formats: Use consistent casing and abbreviations (e.g., “St” vs “Street”) across site, schema, and listings.
• Platform constraints: If your CMS strips script tags, use a server-rendered or head component to inject JSON-LD.
• Multiple reservation providers: Point potentialAction to your primary reservation flow to avoid confusion.
• No rich results appearing: Restaurant is a contextual/local type; focus on completeness, accuracy, and consistent NAP across the web rather than expecting an immediate card.

Validation and QA

• Run the published URL through the Rich Results Test and confirm Restaurant is detected without errors.
• Use URL Inspection to verify the page is indexable (no noindex, no robots disallow, correct canonical).
• Spot-check mobile friendliness and LCP/CLS budgets — avoid layout shifts from large hero images by reserving height.
• Ensure alt text on food and storefront images so the experience is accessible and clear.
• Click every link in the schema (menu, reservations) to confirm they resolve and match on-page destinations.

Maintenance routine

• Update hours seasonally and whenever you change service models (e.g., temporary closures, holiday hours, delivery-only periods).
• Refresh menu URLs and featured images when dishes change materially.
• Review ratings quarterly; if you turn off on-site reviews, remove aggregateRating.
• Keep lastReviewed current in metadata after each content or schema refresh.