Restaurant- oder LocalBusiness-Schema für Ghost Kitchens und Multi-Brand-Konzepte

Warum diese Entscheidung bei Ghost Kitchens komplizierter ist

Bei einem klassischen Restaurant mit einer Marke und einem Standort ist die Zuordnung zu Schema.org-Typen meist unstrittig: Ein Betrieb, eine Adresse, ein Markup. Sobald jedoch mehrere virtuelle Marken aus derselben Küche operieren – etwa eine Burger-Marke, eine Bowl-Marke und eine Dessert-Marke, die alle über dieselbe Produktionsstätte liefern – stellt sich die Frage, wie viele "Standorte" strukturiert beschrieben werden sollen und mit welchem Typ.

Schema.org selbst trifft keine Aussage darüber, wie Ghost Kitchens oder Multi-Brand-Setups abzubilden sind; das Vokabular beschreibt Eigenschaften eines Geschäfts, nicht organisatorische Realitäten wie geteilte Küchen. Genau deshalb braucht es einen praktischen Entscheidungsrahmen, der die vorhandenen Typdefinitionen konsequent auf die tatsächliche Betriebsstruktur anwendet, ohne über die Dokumentation hinauszugehen.

Das Premise-First-Framework

Der folgende Entscheidungsbaum orientiert sich an einem einfachen Prinzip: Zuerst die physische Betriebsstätte korrekt beschreiben, danach jede virtuelle Marke als eigenständige Entität mit eigenen, korrekt zugeordneten Eigenschaften ergänzen.

1. Schritt 1 – Physische Betriebsstätte identifizieren: Erfassen Sie Adresse, Öffnungszeiten der Küche und alle Eigenschaften, die für den Produktionsstandort selbst gelten, unabhängig davon, wie viele Marken dort produzieren.
2. Schritt 2 – Jede virtuelle Marke einzeln betrachten: Für jede Marke prüfen, ob sie einen eigenen Namen, eine eigene Speisekarte (menu), eigene Öffnungszeiten für Bestellungen und eigene Kontaktinformationen hat.
3. Schritt 3 – Typ wählen: Wenn die Marke als Lebensmittelbetrieb mit eigener Speisekarte auftritt, ist Restaurant laut Schema.org-Definition anwendbar. Wenn nur allgemeine Geschäftsdaten ohne gastronomiespezifische Eigenschaften relevant sind, genügt LocalBusiness.
4. Schritt 4 – Adressfelder prüfen: Stellen Sie sicher, dass identische Adressangaben mehrerer Marken nicht so dargestellt werden, dass sie separate, für Gäste zugängliche Vor-Ort-Standorte suggerieren, wenn nur eine physische Betriebsstätte existiert.
5. Schritt 5 – Eigenschaften markenspezifisch zuordnen: Eigenschaften wie acceptsReservations, servesCuisine oder menu sollten je Marke einzeln gesetzt werden, nicht pauschal für die gesamte Küche.
6. Schritt 6 – Testen und dokumentieren: Markup mit den verfügbaren Testwerkzeugen prüfen und intern dokumentieren, welche Marke welches Markup trägt.

Entscheidungstabelle nach Konstellation

Was das Framework nicht leisten kann

Dieser Entscheidungsbaum ersetzt keine rechtliche oder plattformspezifische Prüfung. Schema.org definiert Vokabular, keine verbindlichen Regeln dafür, wie viele Marken an einer Adresse zulässig sind oder wie Lieferplattformen solche Daten interpretieren. Die Dokumentation zu Restaurant beschreibt Eigenschaften wie menu, acceptsReservations oder servesCuisine, trifft aber keine Aussage darüber, ob mehrere Restaurant-Entitäten an identischer Adresse von Suchmaschinen als plausibel oder als potenziell irreführend eingestuft werden.

Ebenso wichtig: Strukturierte Daten sind eine Beschreibung, keine Garantie für eine bestimmte Darstellung. Googles Dokumentation zu LocalBusiness-Strukturdaten macht deutlich, dass korrektes Markup eine Voraussetzung für bestimmte Suchfunktionen sein kann, aber keine automatische Folge hat. Ob eine Marke in einem Rich-Result, einem Buchungswidget oder überhaupt prominenter erscheint, hängt von zusätzlichen, nicht durch Markup allein kontrollierbaren Faktoren ab.

• Schema.org macht keine Aussage darüber, wie viele virtuelle Marken pro physischem Standort "üblich" oder "korrekt" sind.
• Es gibt keine dokumentierte Obergrenze für Restaurant-Entitäten an einer Adresse.
• Strukturierte Daten allein erzeugen keine Sichtbarkeit in Suchergebnissen, Rankings oder Buchungslinks.
• Testwerkzeuge prüfen Syntax und Vokabularkonformität, nicht die geschäftliche Richtigkeit der Angaben.

Praktische Checkliste vor der Implementierung

• Liste aller virtuellen Marken erstellen, die aus derselben Küche operieren.
• Für jede Marke prüfen: eigener Name, eigene Speisekarte, eigene Bestellzeiten?
• Adressfeld einheitlich, aber Beschreibung so formulieren, dass keine getrennten Vor-Ort-Standorte suggeriert werden.
• Restaurant- oder LocalBusiness-Typ je Marke einzeln festlegen, basierend auf tatsächlich vorhandenen Eigenschaften.
• acceptsReservations nur setzen, wenn die Marke tatsächlich Reservierungen entgegennimmt.
• Markup mit einem Structured-Data-Testtool prüfen, bevor es live geschaltet wird.
• Intern dokumentieren, welches Markup zu welcher Marke gehört, für spätere Audits.

Messung: Wie Sie die Umsetzung überprüfen

Nach der Implementierung lässt sich technisch nur prüfen, ob das Markup syntaktisch korrekt ist und den Schema.org-Typdefinitionen entspricht – nicht, ob es zu mehr Sichtbarkeit, Traffic oder Buchungen führt. Ein sinnvoller Messansatz umfasst:

1. Validierung jeder Marken-Markup-Instanz einzeln mit einem Structured-Data-Testtool.
2. Regelmäßige Kontrolle in der Search Console auf gemeldete Strukturdatenfehler pro URL.
3. Manuelle Stichprobenprüfung, ob Adress- und Öffnungszeitenangaben je Marke weiterhin der Realität entsprechen, besonders nach Änderungen an Küchenzeiten oder Markenportfolio.
4. Dokumentation von Änderungen am Markenportfolio, damit veraltete virtuelle Marken nicht weiterhin im Markup erscheinen.

Eine belastbare Aussage darüber, ob bestimmtes Markup zu einer bestimmten Suchdarstellung führt, lässt sich nur durch direkte Beobachtung der tatsächlichen Suchergebnisse treffen, nicht durch die Analyse des Markups allein.

Wo ChefNet in diesen Prozess passen kann

ChefNet entwickelt Produkte im Bereich Restaurant-Discovery und -Betrieb, unter anderem für Fragen rund um Standort- und Markendarstellung. Für Betreiber von Ghost Kitchens und Multi-Brand-Konzepten kann ein Tool, das beim Zuordnen von Marken zu physischen Standorten unterstützt, grundsätzlich relevant sein. Da sich der Funktionsumfang laufend weiterentwickelt, sollten Betreiber direkt bei ChefNet prüfen, welche Funktionen zum jeweiligen Zeitpunkt tatsächlich verfügbar sind, bevor sie Entscheidungen zur Markup-Strategie darauf stützen.

Edge Cases, die im Standardfall übersehen werden

Die Zuordnung von Marke zu Standort wird komplizierter, sobald sich Betriebsstruktur oder Portfolio ändern. Vier Situationen verdienen besondere Aufmerksamkeit, weil Schema.org und Googles Dokumentation dafür kein fertiges Muster liefern, sondern nur die zugrunde liegenden Eigenschaften definieren:

• Eine Marke, mehrere Ghost-Kitchen-Standorte: Wenn dieselbe virtuelle Marke aus mehreren physischen Küchen in unterschiedlichen Stadtteilen operiert, entsteht kein einzelnes Restaurant-Objekt, sondern mehrere Restaurant-Entitäten mit identischem Markennamen, aber unterschiedlicher Adresse und ggf. unterschiedlicher Speisekarte oder Öffnungszeit je Standort.
• Marke ausschließlich auf Aggregator-Plattformen: Existiert für eine virtuelle Marke keine eigene, von ChefNet oder dem Betreiber kontrollierte Webpräsenz, sondern nur ein Eintrag bei einer Lieferplattform, lässt sich eigenes Markup unter Umständen gar nicht sinnvoll einbetten – die Darstellung liegt dann vollständig im Ermessen der Plattform.
• Unterschiedliche Öffnungszeiten trotz gemeinsamer Küche: Nimmt Marke A ab 11 Uhr, Marke B aber erst ab 17 Uhr Bestellungen an, muss openingHours markenspezifisch gepflegt werden; eine gemeinsame Küchenöffnungszeit für alle Marken zu übernehmen, würde die tatsächliche Bestellbarkeit falsch darstellen.
• Marke wird eingestellt oder umbenannt: Bleibt veraltetes Markup nach Einstellung einer virtuellen Marke online, beschreibt es ein nicht mehr existierendes Angebot an einer weiterhin aktiven Adresse – ein Risiko, das eher organisatorisch als technisch zu lösen ist.

Ergänzender Entscheidungspunkt: branchOf

Für Betreiber, die mehrere physische Küchenstandorte unter einer Betreiberorganisation führen, stellt sich zusätzlich die Frage, wie der Bezug zwischen einzelnem Standort und übergeordnetem Unternehmen abgebildet wird. LocalBusiness verfügt über die Eigenschaft branchOf, mit der ein Standort als Zweigstelle einer größeren Organisation ausgewiesen werden kann. Das ist verfügbares Vokabular, keine Pflichtangabe: Ob und wie sinnvoll dessen Einsatz ist, hängt davon ab, ob eine übergeordnete Organisationsentität überhaupt separat gepflegt wird.

Grenzen der Fehlerprüfung

Testwerkzeuge und Search-Console-Meldungen zeigen syntaktische Konformität mit dem Schema.org-Vokabular an, treffen aber keine Aussage darüber, ob die inhaltliche Zuordnung – etwa welche Speisekarte zu welcher Marke gehört – korrekt ist. Ein fehlerfrei validiertes Markup kann trotzdem eine nicht mehr existierende Marke oder eine falsche Öffnungszeit beschreiben. Ebenso liefert kein Testwerkzeug eine Aussage darüber, ob Google oder eine Lieferplattform mehrere Restaurant-Entitäten an derselben Adresse als plausibel einstuft; das bleibt außerhalb des durch die Dokumentation abgedeckten Prüfumfangs.

Ergänzte Prüfschritte für Multi-Marken-Setups

1. Nach jeder Änderung am Markenportfolio: Abgleich, ob alle aktiven Marken-Markups noch einer tatsächlich bestellbaren Speisekarte entsprechen.
2. Bei mehreren Küchenstandorten derselben Marke: Prüfen, ob Adresse und Öffnungszeiten je Standort korrekt getrennt gepflegt sind, statt eine zentrale Angabe für alle Standorte zu verwenden.
3. Bei Einsatz von branchOf: Sicherstellen, dass die referenzierte Organisation-Entität selbst konsistent und aktuell beschrieben ist.
4. Regelmäßige Stichprobe auf verwaiste Markup-Instanzen für eingestellte virtuelle Marken.

Primärquellen

• Schema.org Restaurant
• Google: LocalBusiness structured data

FAQ

Redaktioneller Hinweis: ChefNet veröffentlicht diesen Leitfaden und entwickelt Produkte für Restaurantsuche und -betrieb. Allgemeine Betriebshinweise sind von Produktaussagen getrennt. Funktionen können sich im Verlauf der Pilotphase ändern. Veröffentlicht 2026-08-12.