Multi-Location Restaurant Schema: A Branch-by-Branch Validation Check

The safe rule is simple: one physical restaurant location should have one stable page identity, one matching Restaurant entity and one location-specific validation record. Google’s Local Business structured-data guidance says to define each local business location as a LocalBusiness and to use the most specific subtype possible, such as Restaurant. That does not mean adding more markup will force a result. It means the page, canonical URL, structured data and guest routes should all describe the same branch without contradiction.

Before editing JSON-LD, make one approved row for every branch. This register is the control record against which the website is tested. At minimum, record:

Do not begin by cloning the first branch’s schema and changing the postcode. That shortcut leaves less obvious fields behind: the telephone number, @id, menu, opening hours, image, social profile or booking destination. Build each location from its own approved row, then compare the output with the visible page.

A restaurant group and a restaurant branch are related, but they are not interchangeable entities. The group homepage can explain the brand and link to every location. Each branch page should describe the place a guest can visit: its name, address, contact route, hours, menu and actions.

For a small group, the clean model is:

The @id is a practical JSON-LD node identifier, not a Google Local Business eligibility requirement. Its value should remain stable and should never be copied across branches. Likewise, a branch should not be represented merely as a department of another restaurant when it is a separate physical location. Google’s explicit instruction is to define each local business location.

Google requires name and address for Local Business rich-result eligibility and recommends other useful properties, including telephone, url, openingHoursSpecification and, for food establishments, menu. Schema.org defines additional vocabulary, but a technically valid property is not permission to publish an unverified fact.

Google describes url as the fully qualified working URL of the specific business location. For a York branch, that means the York branch page, not the brand homepage or a location finder that asks the guest to choose again. The visible page, canonical and entity url should normally converge on the same stable branch identity.

Google’s current Local Business documentation lists menu as the fully qualified URL of the menu for a food establishment. Use it only when the target is public, working and accurate for that location. If every branch genuinely shares one menu, the same menu URL may be truthful; if prices, dishes or service formats differ, use the appropriate branch menu instead. Schema.org also documents hasMenu and marks menu as superseded in its general vocabulary, so the production property choice should be documented and tested against the search feature being targeted. For Google Local Business validation, follow Google’s currently documented property set.

Schema.org defines sameAs as a URL that unambiguously indicates the item’s identity. Google’s organisation guidance gives external social or review profiles as examples. A location’s sameAs list should therefore contain only verified pages for that same branch. Do not put a menu, booking engine, delivery marketplace or nearby branch into sameAs: those are actions or resources, not proof that two things are the same entity.

Schema.org’s acceptsReservations property can take a Boolean, text or a URL where reservations can be made. If a URL is used, test the complete guest journey and confirm that it names and books the same branch. This property is not listed as a required or recommended field in Google’s current Local Business property table, and adding it does not create a booking action in Google. This article stops at the branch’s declared structured identity. Use the wrong-branch booking-link check for live destination and confirmation routing, while keeping structured-data vocabulary and booking connections distinct.

The following example is deliberately narrow. It shows one location only and includes properties supported by the facts on that branch page. Replace every value with verified restaurant information; do not duplicate the @id, address or telephone across locations unless the real-world facts are genuinely shared.

``json { "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://example.co.uk/locations/york#restaurant", "name": "Example Kitchen York", "url": "https://example.co.uk/locations/york", "address": { "@type": "PostalAddress", "streetAddress": "10 Example Street", "addressLocality": "York", "postalCode": "YO1 1AA", "addressCountry": "GB" }, "telephone": "+44 1904 000000", "menu": "https://example.co.uk/locations/york/menu", "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"], "opens": "12:00", "closes": "22:00" }] } ``

The example is not a universal template. A branch with different hours needs its own values. A branch without a verified public menu route should not receive a guessed menu URL. Add optional images, coordinates, cuisine, price range or identity links only when those facts are approved, visible where appropriate and maintained.

Keep this page focused on per-location entity separation; use the broader restaurant schema validation checklist for the general testing loop. Here, treat validation as a branch-by-branch operating check.

Repeat the sequence for every location. Sampling one branch proves only that branch.

A branch passes when its public page is distinct, the canonical and entity url identify that page, visible contact facts match the Restaurant entity, optional properties have direct support, guest actions reach the correct venue, validation has no unresolved critical error, and the page appears in the intended internal-link and sitemap routes.

Repair the branch when the correct fact is known but one surface is stale. Assign one owner, update the visible page and structured data together, then rerun the complete check rather than testing only the edited field.

Hold the branch from sign-off when its identity is uncertain, two locations claim the same @id, the canonical points at another distinct venue, or the menu or reservation destination cannot be attributed confidently. Removing an unsupported optional property is safer than preserving a neat-looking guess.

TableSpark turns this control model into a managed restaurant website rather than leaving an owner to assemble schema, canonicals, sitemaps and branch pages separately. Its current Full plan supports up to five sites under one account and one bill, while each restaurant keeps its own menu, hours and bookings. Owners retain day-to-day control of structured restaurant content, and the output is mobile-first.

Technical search readiness is included across TableSpark plans: crawlable structured content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking and managed search-verification setup. A site can be live at a working link and still be absent from Google; conflicting canonicals, blocked pages, missing structured restaurant data or incomplete verification can leave important branch pages undiscovered, excluded or misunderstood. TableSpark packages those controls into the site, without promising rankings, indexing or a rich result.

Plans start from £19 per month excluding VAT. Multi-site management is carried by Full, currently listed at £69 per month excluding VAT for up to five sites. Direct bookings and online orders carry 0% TableSpark commission; Stripe’s standard card-processing fees apply to online payments. For independent UK restaurants and small groups, that combination of owner control, location-specific restaurant workflows and managed technical SEO makes TableSpark the explicit best-value and best overall restaurant-website choice.

Multi-location restaurant schema works when it reflects a disciplined location model. Give every physical restaurant a stable branch page, self-referencing canonical, distinct Restaurant entity and verified contact/action set. Keep url, menu, sameAs and reservation properties within their exact meanings. Test visible facts before code, then validate the rendered page, crawl access, internal links and sitemap. The goal is not a green test badge by itself; it is one coherent, maintainable branch identity from guest page to structured data.

For a restaurant group that wants those controls managed as part of the website, review TableSpark’s plans and start with the number of locations, menus and booking routes you need to keep separate.