Restaurant vs LocalBusiness Schema for Ghost Kitchens and Multi-Brand Virtual Concepts

Direct answer: Under Schema.org's own hierarchy, Restaurant is a subtype of FoodEstablishment, which is itself a subtype of LocalBusiness. Use Restaurant when a virtual brand's public-facing content is genuinely food-service content (menu, cuisine, reservations), and use it once per brand, not once per address. Use the broader LocalBusiness type only when a brand or facility doesn't fit food-specific properties, or when you need to describe the physical kitchen itself separately from the brands that operate out of it. The address field should always describe where the food is actually prepared and, if applicable, where it can be picked up — never a location implying dine-in service that doesn't exist.

Why the type choice matters for multi-brand kitchens

A single commissary or ghost kitchen may host several virtual brands: different names, different menus, sometimes different opening hours, all coming from one set of ovens and one delivery exit. Schema.org's Restaurant definition inherits properties from LocalBusiness, including address, openingHoursSpecification, and telephone, and adds food-service-specific properties such as servesCuisine, menu, and acceptsReservations. Google's LocalBusiness structured data guidance documents required and recommended properties for the broader type, but it does not address the specific case of several brand names sharing one production address. That gap is exactly where operators need a deliberate, documented decision process rather than a copy-pasted template.

The Shared-Kitchen Schema Decision Path

The following framework — the Shared-Kitchen Schema Decision Path — is a sequence of questions to run for each virtual brand before publishing any markup. It does

Implementation Checklist Before Publishing Markup

Before adding or editing JSON-LD for any virtual brand, walk through this checklist. It is designed to catch the most common representation errors in shared-kitchen setups before they reach a live page.

Confirm which physical address the brand's orders are actually prepared and dispatched from, and verify that address matches what appears in address for every brand sharing that kitchen.
Confirm whether the brand offers any form of walk-in pickup at that address. If it does not, do not include language or properties that imply a storefront experience.
List the brand's actual operating hours separately from the kitchen facility's operating hours — these can differ if the facility runs multiple shifts for different brands.
Check whether the brand has its own phone number, ordering URL, or menu page distinct from other brands at the same address. If two brands share a phone number or URL, decide how that will be represented rather than duplicating identical values silently.
Confirm the brand has a distinct name value in markup even when the underlying business entity is the same across brands.
Verify that no single physical address is described more than once as a full Restaurant entity in a way that could suggest two separate customer-facing dining locations at the same street address.

Decision Tree: Selecting and Implementing Schema Type Per Brand

Apply the following sequence for each virtual brand individually. Do not apply one answer to all brands automatically, since brands sharing a kitchen can still differ in how they should be marked up.

Does the brand present a menu, cuisine type, or reservation option to the public?
- Yes → proceed to Step 2 using Restaurant as the candidate type, per Schema.org's Restaurant definition.
- No, it is a facility-only listing (e.g., the commissary itself, not a customer-facing brand) → use LocalBusiness or a more specific non-food subtype if one applies, and stop here.
Does the brand allow any form of customer pickup at the kitchen's physical address?
- Yes → set address to the kitchen's physical address and represent pickup availability using available order/delivery-related properties rather than implying a dine-in room.
- No, delivery-only → still set address to the location where food is prepared, since Schema.org's property definitions tie address to the business location, not to a customer-visitable storefront. Do not omit or fabricate an address to avoid disclosing the kitchen location; instead, decide with legal/compliance staff whether reduced address detail is appropriate.
Do the brand's public hours differ from the kitchen facility's total operating hours?
- Yes → set openingHoursSpecification to the brand's own service hours, not the facility's full shift schedule.
- No → the brand's hours may mirror the facility's hours, but confirm this is still accurate rather than assumed.
Does more than one brand share this same address in your markup set?
- Yes → assign each brand its own Restaurant (or LocalBusiness) entity with a distinct name, and cross-check that address duplication reflects a genuine shared-kitchen fact, not a copy-paste error.
- No → proceed to publish, then log the review date for future audits.

Edge Cases That Do Not Fit the Standard Path

Scenario	Representation approach
Brand paused or delisted from delivery platforms but the schema page still exists	Update hours or availability-related fields to reflect the paused state rather than leaving stale data live; Google's structured data guidance treats inaccurate markup as a data-quality issue for the underlying page.
Kitchen relocates but brand names stay the same	Update `address` for every brand entity tied to that kitchen at the same time; a partial update leaves some brands pointing to a location that no longer prepares their food.
Two brands share one phone number or ordering link	Decide explicitly whether to repeat the same value across both entities or omit the property for one; document the choice so future edits stay consistent.
Brand exists only inside a third-party delivery app with no owned web page	Structured data on a page you do not control cannot be added by you; focus verification efforts on pages your team actually publishes.
Facility itself needs a public-facing listing (e.g., for supplier or press inquiries)	Represent the facility as its own `LocalBusiness` entity, separate from any brand-level `Restaurant` entities operating inside it.

Measurement and Ongoing Validation

Treat schema markup as data that requires periodic review, not a one-time task. Google's structured data documentation describes testing tools for checking whether markup is structurally valid; use those tools after any change to address, hours, or brand names, and review Search Console for reported structured data errors on a regular schedule. Testing confirms that markup is well-formed and matches Schema.org's property definitions — it does not confirm how, or whether, any search product will display that data. Keep a simple internal log of what changed, when, and which brand it applied to, so that an audit months later can trace why a given field holds its current value.

Limitations of This Framework

This decision path addresses type selection and property accuracy as defined by Schema.org and described in Google's structured data guidance. It does not address, and should not be read as addressing, whether structured data affects visibility, ranking, or inclusion in any specific search feature — Google's own documentation describes structured data as informational markup for eligible display treatments, not a guarantee of any particular outcome. Legal questions such as disclosure requirements for delivery-only kitchens, food-safety signage, or local business licensing are outside the scope of Schema.org or Google's technical documentation and should be reviewed with qualified legal counsel familiar with the relevant jurisdiction.

Where ChefNet Fits

ChefNet is developing restaurant discovery and operations products, including tools that may relate to how multi-brand and ghost-kitchen listings are managed. Because product capabilities change during development, operators should verify directly with ChefNet which structured-data-related features, if any, are currently live before assuming a given workflow step described above is automated on their behalf. General schema guidance in this article applies regardless of which platform or tooling an operator uses to publish it.

Primary sources

FAQ

Can two virtual brands at the same address both use Restaurant schema?

Schema.org's vocabulary does not prohibit this, since Restaurant is a type, not a limited-use identifier. However, each brand's markup should describe only that brand's actual name, menu, and hours, and operators should be careful that identical address fields do not imply two separate customer-facing dine-in locations if only one physical premises exists.

Is LocalBusiness always the safer choice for a delivery-only brand?

Not necessarily. Schema.org allows Restaurant for any food-service business regardless of whether it accepts walk-ins, since the type describes the nature of the business rather than its service model. The more relevant question is which properties (such as acceptsReservations or menu) accurately apply, not which parent type sounds more conservative.

Does adding structured data make a virtual brand appear in search results or booking widgets?

Structured data provides machine-readable vocabulary that search engines and other services may or may not use to generate a given feature. Google's own documentation for LocalBusiness structured data does not guarantee that any specific markup produces a rich result, ranking change, or booking link, so operators should verify appearance directly rather than assume it from markup alone.

Editorial disclosure: ChefNet publishes this guide and develops products for restaurant discovery and operations. General operating guidance is separated from product claims. Capabilities can change as pilots progress. Published 2026-08-12.