Structured data is code that explains what a page represents. For restaurants, it can identify the business, location, hours, cuisine, menu, and offers in a consistent machine-readable form.
Begin with the Restaurant entity
Use the most specific appropriate type—usually Restaurant, which is a kind of FoodEstablishment and LocalBusiness. Give it a stable identifier, often the canonical home URL plus an anchor such as #restaurant, so other page objects can point back to the same entity.
Mark up only visible, current facts
Include the official name, canonical URL, telephone, image, description, address, coordinates, servesCuisine, priceRange, and openingHoursSpecification when accurate. The page should visibly support each important claim.
Model the location precisely
Use PostalAddress for street address, city, region, postal code, and country. Add GeoCoordinates when verified. If the restaurant has multiple locations, treat each location as a distinct Restaurant entity with its own page and facts.
Represent hours rather than flattening them
OpeningHoursSpecification can express days and open/close times. Overnight hours need careful modeling. Temporary holiday hours change too often to leave unattended in static markup; connect them to a reliable update process or omit them from markup and keep the visible profile current.
Connect the menu
At minimum, hasMenu can point to the canonical menu page. A richer menu may use Menu, MenuSection, MenuItem, and Offer objects. Include price and priceCurrency together. Dietary suitability should reflect a clear kitchen policy and visible label.
Do not invent review aggregates
AggregateRating and Review markup have eligibility and content requirements. Never copy a rating from a third-party platform into first-party structured data as if it were the site’s own independently collected review set. If you are uncertain, omit it.
Add breadcrumb and article objects where appropriate
Supporting pages such as private dining, catering, or blog articles can have their own page types and BreadcrumbList markup. Keep every object tied to a canonical URL and the same restaurant identifier.
Validate in three passes
- Check that the JSON parses and uses valid Schema.org properties.
- Compare every fact against the visible page and current business record.
- Use Google’s Rich Results Test and Search Console URL Inspection where relevant, then monitor warnings after deployment.
Restaurant schema handoff
- One stable Restaurant identifier
- Canonical URL, name, phone, image, and description
- Complete PostalAddress and verified coordinates
- Cuisine and honest price range
- Accurate regular hours
- Menu URL or structured Menu hierarchy
- No unsupported awards, ratings, or claims
- Visible content matches the code
- Validated after every meaningful change
Explore the official Restaurant and Menu vocabularies before implementation.