Restaurant Structured Data: What Should Owners Mark Up?

Know what structured data does before adding it

Structured data is a machine readable description of the business and the page. It gives search systems a consistent way to read details such as the venue name, address, hours, phone number, menu, cuisine, and price range. It should clarify information that is already true, not create a second version of the restaurant behind the visible page.

This is a narrower job than general local search work. Your Google Business Profile, location page, menu, reviews, mobile experience, and links still need attention. Our broader restaurant SEO guide explains that full picture. Here, the goal is one clean business record that can be maintained and tested.

Search appearance can change, and valid markup may still produce no special display. Treat structured data as a technical description of the venue, not a shortcut to a higher position or a promise that Google will show every field.

Choose one specific business type for each real location

Use the most specific LocalBusiness subtype that truthfully describes the place. For a restaurant, that is usually Restaurant. A cafe or boutique stay should use the relevant subtype for its actual business rather than calling every hospitality venue a restaurant or using only the broad LocalBusiness type.

Define one real location at a time. If a restaurant group has three branches, each branch should have its own location page, address, telephone, hours, menu destination, and structured data entity. Do not combine several addresses and sets of hours into one vague record for the group home page.

The visible location page should support the markup. A guest should be able to read the same name, street address, primary phone number, current hours, menu link, and venue description without opening the page source. If a field is uncertain or not maintained, fix the source information before marking it up.

Mark up the practical core, not every available property

Start with the details that identify the venue and help a guest confirm the visit. Google currently requires the business name and physical address for Local Business rich result eligibility. For a useful restaurant record, the practical core is:

• name: the real public name of this location, without extra search phrases.
• address: a complete PostalAddress, including country and the local fields guests need.
• telephone: the primary customer phone number, including country and area code.
• url: the working, fully qualified URL for this specific location.
• menu: the fully qualified URL of the current menu. A stable web menu is easier to keep useful than an unexplained file link. See our guide to restaurant menu pages and PDFs for the guest facing decision.
• openingHoursSpecification: the days and exact opening and closing times for this location.
• priceRange: a short, honest description such as a relative currency sign range or a compact numerical range.
• servesCuisine: a clear description of the cuisine the restaurant actually serves.
• geo: latitude and longitude only when the coordinates have been verified for the correct entrance or venue location.

More fields do not automatically make better markup. A small accurate record is more useful than a large block copied from a generator and left to drift. Add a property because the venue can verify and maintain it, not because it appears in a long schema list.

Handle hours, late service, and separate locations carefully

Use OpeningHoursSpecification to group days that share the same hours, then give each group an opens and closes time. If Saturday service starts at 18:00 and ends at 03:00 on Sunday, Google's example keeps that late service in one Saturday specification. Seasonal closures can use validFrom and validThrough when both dates are known.

The markup must still agree with the visible hours and the hours guests see elsewhere. If the kitchen stops taking orders before the venue closes, explain that distinction on the page rather than forcing one ambiguous time to carry both meanings. When holiday hours change, update the guest facing page, the business profile, and the structured data through the same operating checklist.

Do not guess coordinates from a neighbourhood name or reuse one branch's map pin for another. Confirm the latitude and longitude against the real location before including geo. For a multi location business, this is another reason to keep one entity and one location page per branch.

Avoid self serving reviews and invented action markup

Do not copy a restaurant's Google rating into aggregateRating on its own website and expect review stars. Google's current Local Business guidance recommends that property only for sites that capture reviews about other local businesses. A restaurant marking up reviews of itself is the self serving case owners should avoid.

Keep genuine testimonials visible when they are useful to guests, but do not turn an external platform score into unsupported local business review markup. Review eligibility has its own rules, and structured data should never make a claim the page and the venue cannot substantiate.

Booking and ordering actions need the same restraint. Google says direct reservations, payments, and other actions in Search use the Maps Booking API. Do not invent an action property or paste a booking button URL into unrelated markup and assume it will create a Search action. Keep the normal website booking path clear, then use an eligible booking or ordering integration where appropriate. Our guide to restaurant booking links on the website and Google explains the channel decision.

Use a short implementation and validation checklist

1. Confirm the source facts. Check the public name, full address, primary phone, location URL, menu URL, standard and seasonal hours, price range, cuisine, and any coordinates with the owner or venue manager.
2. Match the visible page. Put the same useful facts on the location page. Do not hide a different business record only inside the markup.
3. Create one entity for the location. Use the most specific truthful subtype, usually Restaurant for a restaurant, and connect only the fields that belong to that branch.
4. Test before launch. Run the page through Google's Rich Results Test. Fix critical errors and review warnings against the real venue information.
5. Inspect the live URL. After deployment, use Search Console's URL Inspection tool to confirm that Google can access the page and see the current version.
6. Submit the sitemap. Make sure the canonical location URL is present in the XML sitemap, then submit or resubmit that sitemap in Search Console.
7. Check the result without making promises. A passing test confirms the code can be understood. It does not guarantee ranking movement, a knowledge panel change, or a rich result.

Keep the record current after launch

Give one person responsibility for the visible location details and their structured data. Review them whenever the phone number, address, menu destination, regular hours, holiday schedule, booking provider, cuisine description, or location page changes. The markup should be part of the update, not a separate technical task remembered months later.

Add the check to the venue's normal website routine. Our restaurant website maintenance checklist covers the wider monthly review. After an important location or template change, rerun the Rich Results Test and inspect the live URL again.

If you want to see whether the guest facing basics are clear before touching code, start with the free Restaurant Website Quick Score. It checks the menu, booking path, contact details, location clarity, and other essentials that the structured record should support rather than contradict.

The useful owner decision is accuracy you can maintain

A good Restaurant record is not SEO magic. It is a compact, truthful description of one venue, supported by a page guests can read and a team process that keeps both versions aligned. Choose the specific type, publish the practical core, leave out uncertain coordinates and risky review claims, use the proper route for direct actions, and test the live result.

If nobody knows who updates the markup when the Christmas hours or menu URL changes, the implementation is not finished. Ownership and maintenance are part of the technical work.

Sources

• Google Search Central, Local Business structured data
• Schema.org, Restaurant
• Schema.org, OpeningHoursSpecification
• Schema.org, servesCuisine