Sie betreiben drei Standorte, aber Google zeigt nur einen davon im Local Pack? Das liegt fast immer am Schema-Markup. Wer mehrere Filialen hat und alle über eine einzige LocalBusiness-Auszeichnung abbildet, verschenkt lokale Sichtbarkeit an jedem zusätzlichen Standort.
Dieser Artikel zeigt, wie Sie jeder Filiale ein eigenes LocalBusiness-Schema geben, die Standorte sauber mit Ihrer Dachmarke verknüpfen und typische Fehler vermeiden. Inklusive fertigem JSON-LD-Beispiel für zwei Filialen.
Warum jede Filiale eigenes LocalBusiness-Schema braucht
Google rankt Standorte einzeln. Ein Betrieb mit Filialen in Nürnberg, Fürth und Erlangen konkurriert in jeder Stadt um einen eigenen Platz im Local Pack. Wenn aber nur ein einziges LocalBusiness-Objekt auf der Website hinterlegt ist, kann Google die anderen Standorte nicht als eigenständige Geschäftseinheiten verstehen.
Die Folge: Filialen ohne eigenes Schema erscheinen im Schnitt 30 bis 50 % seltener in den lokalen Kartenergebnissen ihrer jeweiligen Stadt. Sie existieren für die Suche an diesem Ort praktisch nicht.
Die saubere Lösung sieht so aus:
- Eigene Standortseite pro Filiale (z. B.
/standorte/fuerth/) - Auf jeder Standortseite ein eigenes LocalBusiness-Objekt mit der individuellen NAP-Angabe dieser Filiale
- Alle Filialen verknüpft mit einer übergeordneten Organization
Grundlagen zu Aufbau und Pflichtfeldern eines einzelnen Eintrags haben wir im Artikel zu Schema.org LocalBusiness zusammengefasst. Dieser Text baut darauf auf und überträgt das Prinzip auf mehrere Standorte.
@id und die Verknüpfung der Standorte zur Dachmarke
Der Schlüssel zu sauberem Multi-Standort-Markup ist das Feld @id. Es gibt jedem Schema-Objekt eine eindeutige, dauerhafte Kennung. Über diese ID referenzieren sich die Objekte gegenseitig, ohne dass Daten doppelt eingetragen werden müssen.
Das Modell sieht so aus:
- Eine Organization repräsentiert die Dachmarke (die GmbH, die Hauptmarke).
- Jede Filiale ist ein eigenes LocalBusiness, das per
parentOrganizationauf die Dachmarke zeigt. Jeder Standort erhält dadurch eine eigene Entität, die Google getrennt ranken kann. - Die Organization listet ihre Standorte über
subOrganizationoderdepartmentauf und verweist dabei nur auf die@idder Filialen.
So entsteht ein zusammenhängender Graph. Google versteht: Diese drei Geschäfte gehören zu einer Marke, sind aber eigenständige physische Orte mit unterschiedlicher Adresse und Telefonnummer. Genau diese Unterscheidung braucht die Suchmaschine, um jede Filiale am richtigen Ort auszuspielen.
Praxis-Tipp: Verwenden Sie als @id die kanonische URL der jeweiligen Standortseite plus einen Anker, z. B. https://ihre-domain.de/standorte/fuerth/#localbusiness. So ist die ID stabil, eindeutig und über die ganze Website hinweg referenzierbar.
JSON-LD-Beispiel für zwei Filialen
Das folgende Markup zeigt eine Dachmarke mit zwei Standorten. Die Organization listet beide Filialen, jede Filiale verweist über parentOrganization zurück auf die Marke:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://ihre-domain.de/#organization",
"name": "Muster Dienstleistungen GmbH",
"url": "https://ihre-domain.de/",
"logo": "https://ihre-domain.de/images/logo.webp",
"subOrganization": [
{ "@id": "https://ihre-domain.de/standorte/nuernberg/#localbusiness" },
{ "@id": "https://ihre-domain.de/standorte/fuerth/#localbusiness" }
]
},
{
"@type": "LocalBusiness",
"@id": "https://ihre-domain.de/standorte/nuernberg/#localbusiness",
"parentOrganization": { "@id": "https://ihre-domain.de/#organization" },
"name": "Muster Dienstleistungen - Nürnberg",
"url": "https://ihre-domain.de/standorte/nuernberg/",
"telephone": "+4991291439894",
"address": {
"@type": "PostalAddress",
"streetAddress": "Hauptstraße 12",
"addressLocality": "Nürnberg",
"postalCode": "90402",
"addressRegion": "Bayern",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 49.4521,
"longitude": 11.0767
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "18:00"
}
]
},
{
"@type": "LocalBusiness",
"@id": "https://ihre-domain.de/standorte/fuerth/#localbusiness",
"parentOrganization": { "@id": "https://ihre-domain.de/#organization" },
"name": "Muster Dienstleistungen - Fürth",
"url": "https://ihre-domain.de/standorte/fuerth/",
"telephone": "+499117654321",
"address": {
"@type": "PostalAddress",
"streetAddress": "Schwabacher Straße 45",
"addressLocality": "Fürth",
"postalCode": "90762",
"addressRegion": "Bayern",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 49.4774,
"longitude": 10.9886
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:30",
"closes": "17:30"
}
]
}
]
}Beachten Sie die unterschiedlichen Adressen, Telefonnummern, Geo-Koordinaten und Öffnungszeiten. Genau diese Unterschiede machen die Filialen für Google unterscheidbar. Den @graph-Container nutzen Sie, um mehrere Objekte in einem einzigen Script-Block zu bündeln.
In der Praxis platzieren Sie das Organization-Objekt einmalig zentral, etwa im globalen <head> der Website, und ergänzen auf jeder Standortseite nur das passende LocalBusiness-Objekt. So bleibt das Markup übersichtlich und jede URL trägt genau die Daten, die zu ihrem Inhalt gehören. Ergänzen Sie bei Bedarf weitere Felder wie image, priceRange oder sameAs pro Filiale, etwa den Link zum jeweiligen Google Business Profil dieses Standorts.
Häufige Fehler bei Multi-Standort-Schema
Die meisten Probleme entstehen durch nachlässiges Kopieren. Diese vier Fehler sehen wir am häufigsten:
- Identische NAP-Daten überall. Wenn alle Filialen dieselbe Adresse oder Zentral-Telefonnummer tragen, behandelt Google sie als Dubletten und filtert sie heraus. Jede Filiale braucht ihre echte, eigene NAP-Angabe.
- Fehlende Geo-Koordinaten. Ohne
geo-Feld muss Google den Standort selbst erraten. Tragen Sie die exakten Koordinaten jeder Filiale ein, idealerweise abgeglichen mit dem jeweiligen Google Business Profil. - Keine @id-Verknüpfung. Lose nebeneinander stehende LocalBusiness-Objekte ohne
parentOrganizationerkennt Google nicht als zusammengehörige Marke. Der Graph muss verbunden sein. - Schema auf der falschen Seite. Das Markup einer Filiale gehört auf deren Standortseite, nicht gesammelt auf die Startseite. Sonst fehlt Google der Bezug zwischen Inhalt und Standort.
Welche Felder Rich Snippets im lokalen Bereich auslösen und wie Sterne-Bewertungen oder Öffnungszeiten in den SERPs erscheinen, vertiefen wir im Beitrag zu Rich Snippets für lokale Unternehmen.
Testen und validieren
Vor dem Live-Gang muss jedes Standort-Schema geprüft werden. Zwei Werkzeuge gehören in jeden Workflow:
- Google Rich Results Test prüft pro URL, ob das Markup gültig ist und welche Rich-Result-Typen Google erkennt. Testen Sie jede Standortseite einzeln.
- Schema Markup Validator von schema.org zeigt den kompletten Graphen und meldet Syntaxfehler oder gebrochene
@id-Referenzen.
Achten Sie besonders darauf, dass die Validatoren die subOrganization-Verweise auflösen können. Wenn eine referenzierte @id nirgends als echtes Objekt existiert, bleibt der Graph zerfallen und Google ignoriert die Verknüpfung.
Ein zweiter Prüfpunkt ist die Schreibweise der @id selbst. Schon ein fehlender Trailing Slash oder ein vergessener Anker führt dazu, dass subOrganization und parentOrganization auf zwei unterschiedliche Identitäten zeigen. Kopieren Sie die IDs deshalb immer aus einer Quelle und prüfen Sie sie zeichengenau gegeneinander.
Praxis-Tipp: Legen Sie eine Test-Checkliste pro Filiale an: Markup gültig, NAP exakt wie im Google Business Profil, Geo-Koordinaten korrekt, parentOrganization verbunden. Erst wenn alle vier Punkte stehen, geht die Standortseite online.
Die theoretischen Grundlagen zu Aufbau, Syntax und Einsatzgebieten von strukturierten Daten finden Sie kompakt im Artikel zu strukturierten Daten nach Schema.org.
Pflege bei vielen Standorten
Bei drei Filialen pflegen Sie das Schema noch von Hand. Ab etwa zehn Standorten wird das fehleranfällig und zeitraubend. Dann lohnt sich Automatisierung:
- Zentrale Datenquelle. Verwalten Sie alle Standortdaten in einer einzigen Tabelle oder einem CMS-Datentyp. Adresse, Telefon, Öffnungszeiten und Koordinaten stehen genau einmal an einem Ort.
- Template-Generierung. Das Schema wird beim Build automatisch aus dieser Datenquelle erzeugt. So ändert sich eine geänderte Öffnungszeit überall gleichzeitig und ohne Copy-Paste-Fehler.
- Konsistenz-Check. Gleichen Sie die Schema-NAP laufend mit den Google Business Profilen ab. Schon eine geänderte Telefonnummer, die nur an einer Stelle landet, kann eine Filiale aus dem Local Pack drängen.
Eine saubere Datenhaltung zahlt sich doppelt aus: Sie spart Pflegeaufwand und sie hält die NAP-Konsistenz hoch, die für lokale Rankings entscheidend ist. Wer 20 Standorte einzeln von Hand pflegt, wird über kurz oder lang Inkonsistenzen einbauen, die die Sichtbarkeit kosten.
Multi-Standort-Schema ist kein Hexenwerk, aber es verzeiht keine Schlampigkeit. Jede Filiale ein eigenes LocalBusiness, sauber per @id mit der Dachmarke verbunden, exakte NAP-Daten und konsequentes Testen. Wer dieses Muster einmal sauber aufsetzt, gewinnt an jedem Standort messbar lokale Sichtbarkeit.
