Strukturierte Daten für lokale Unternehmen: JSON-LD Praxis
Vor einem vollen Ladenlokal: ein Kunde steht ratlos vor geschlossenen Türen, obwohl die Öffnungszeiten online anders angegeben sind. Solche Fehler kosten Vertrauen — und Kunden. Strukturierte Daten funktionieren wie ein digitales Schaufenster: Sie liefern Suchmaschinen präzise Fakten über Ihr Unternehmen (Adresse, Öffnungszeiten, Bewertungen) und erhöhen die Wahrscheinlichkeit für Rich Snippets in der Suche.
Gute strukturierte Daten helfen Suchmaschinen, Ihre Relevanz lokal einzuordnen. Sie verbessern Klick- und Sichtbarkeitsmetriken. Dieser Leitfaden begleitet Sie Schritt für Schritt: erklären, umsetzen, validieren — mit konkreten JSON‑LD‑Schnipseln für Einzel‑ und Mehr‑Standorte sowie Fehlerbehebungs‑Anleitungen. Außerdem zeigen wir praxisnah, wie Sie Rich Cards gezielt nutzen, um Ihre Treffer optisch aufzuwerten.
Jetzt kostenfreie Analyse sichern!
Wenn Sie direkt starten wollen, testen Sie eines der Beispiele anschließend mit dem Rich Results Test. Zur tiefergehenden Prüfung empfiehlt sich außerdem die Search Console (Enhancements) zur langfristigen Überwachung und die Dokumentation zu Suchfunktionen.
Was sind strukturierte Daten und warum sind sie für lokale Unternehmen wichtig?
Strukturierte Daten sind maschinenlesbare Angaben in standardisierten Formaten. JSON‑LD ist aktuell das gebräuchlichste Format. Sie beschreiben Entitäten wie LocalBusiness, Event oder Product so, dass Suchmaschinen zuverlässig interpretieren können. Das reduziert Missverständnisse — zum Beispiel, ob eine Telefonnummer zur Zentrale oder zu einer Filiale gehört.
Unternehmen mit korrekten lokalen Markups sehen häufiger erweiterte Darstellungen in der SERP. Daten aus Ihrem lokalen Markup werden für Karten‑Listings, Knowledge Panels und Rich Snippets verwendet. Das Markup fungiert praktisch als Verifizierungs‑Layer zwischen Ihrer Website und Google.
Nutzer finden Adresse und Öffnungszeiten auf einen Blick. Klicks werden gezielter. Die Absprungrate sinkt, weil Suchende unmittelbare Antworten erhalten. Für Händler, Dienstleister und Gastronomie sind diese Effekte oft messbar in lokalen Ranking‑Signalen und in mehr Kontaktanfragen.
Wichtig ist die Konsistenz: NAP (Name, Address, Phone) muss mit Google Business Profile und Branchenverzeichnissen übereinstimmen. Änderungen sollten gleichzeitig in allen Systemen aktualisiert werden, sonst entstehen widersprüchliche Signale.
Relevante Schema‑Typen für lokale Unternehmen (LocalBusiness, openingHours, address, geo, sameAs)
Viele denken zuerst an LocalBusiness — das ist korrekt, aber oft nicht ausreichend. Das Schema‑Ecosystem bietet Bausteine, die Sie kombinieren sollten. Adress‑ und Geo‑Informationen gehören in PostalAddress und GeoCoordinates; Öffnungszeiten in openingHoursSpecification; Social‑Profiles in sameAs. AggregateRating zeigt Bewertungen; Service und Offer listen konkrete Leistungen.
Eine kurze Liste relevanter Typen:
- LocalBusiness (Obertyp für Laden, Restaurant, Arzt etc.)
- PostalAddress (structured address)
- GeoCoordinates (latitude, longitude)
- OpeningHoursSpecification (präzise Öffnungszeiten, inklusive Ausnahmen)
- AggregateRating (Sternebewertungen, reviewCount)
- sameAs (Social Media, Branchenverzeichnisse)
Nicht jedes Feld ist immer erforderlich. Konzentrieren Sie sich zuerst auf NAP, URL, Öffnungszeiten und Geo‑Koordinaten. Sobald diese sauber sind, ergänzen Sie Angebote (Offer), Leistungen (Service) oder Events. Aus SEO‑Sicht wirkt eine schrittweise, geprüfte Erweiterung am nachhaltigsten.
Kleine Regel: Sichtbare Inhalte auf der Seite sollten mit dem Markup übereinstimmen. Versteckte, unbestätigte oder veraltete Daten können zu Abwertungen führen.
JSON‑LD: Komplettes Beispiel für ein einzelnes Standort‑Schema
Eine saubere Single‑Location‑Implementierung ist in 10–20 Minuten machbar. Unten finden Sie ein vollständiges, valides JSON‑LD‑Beispiel für ein lokales Geschäft. Es deckt die wichtigsten Felder ab: Name, Adresse, Telefon, Öffnungszeiten, Geo, Bewertungen und Social Links. Kopieren Sie das Skript in den Head oder direkt vor dem schließenden <body>-Tag Ihrer Seite.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Beispiel Bäckerei GmbH",
"image": "https://www.ihre-domain.de/images/shop-front.jpg",
"@id": "https://www.ihre-domain.de/",
"url": "https://www.ihre-domain.de/",
"telephone": "+49-30-1234567",
"priceRange": "€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Musterstraße 5",
"addressLocality": "Berlin",
"postalCode": "10115",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.5200,
"longitude": 13.4050
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday","Tuesday","Wednesday","Thursday","Friday"
],
"opens": "07:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday"],
"opens": "08:00",
"closes": "14:00"
}
],
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.5",
"reviewCount": "128"
},
"sameAs": [
"https://www.facebook.com/ihrebaeckerei",
"https://www.instagram.com/ihrebaeckerei"
]
}
</script>
Ersetzen Sie Platzhalter (Name, URL, Koordinaten) durch Ihre echten Daten. Achten Sie auf die korrekte ISO‑Schreibweise (z. B. addressCountry: „DE“).
Erklärte Felder im Beispiel
Ein Entwickler öffnet die Seite und findet sieben Felder, die er zuerst prüfen muss. Jedes hat eine klare Aufgabe:
- @context / @type: Definiert Schema.org‑Kontext und den Entitätstyp (LocalBusiness).
- name, url, @id: Identifikatoren Ihres Unternehmens; @id kann als permanente URL dienen.
- image: Ein repräsentatives Foto — wichtig für Rich Cards.
- telephone / priceRange: Schnelle Entscheidungsdaten für Nutzer.
- address / geo: PostalAddress und GeoCoordinates ermöglichen Karten‑Integration und lokale Zuordnung.
- openingHoursSpecification: Präzise Struktur für Tageszeiten und Ausnahmen (Feiertage separat behandeln).
- aggregateRating / sameAs: Signale für Vertrauen und Social‑Presence.
Technische Anmerkung: Verwenden Sie openingHoursSpecification statt des kompakten openingHours‑Strings, wenn Sie differenzierte Öffnungszeiten oder Ausnahmen abbilden möchten. Latitude und longitude sollten als Zahlen angegeben werden, nicht als Strings.
Ergänzen Sie zunächst Name, URL, Telefon und Adresse. Testen Sie danach jede Ergänzung mit dem Validator.
Einbau in HTML/WordPress
Es gibt drei pragmatische Einbau‑Methoden, die sich in fast jedem Setup bewähren. Wählen Sie basierend auf Zugriff und Wartbarkeit.
- Direkt im Template: Fügen Sie das JSON‑LD in header.php oder vor </body> ein. Vorteil: überall verfügbar. Nachteil: bei Multi‑Location nur bedingt flexibel.
- Seiten‑/Beitragsweise: Script direkt im Editor einfügen (Text/HTML‑Modus) oder über ein benutzerdefiniertes Feld. Gut für einzelne Filialseiten.
- Plugins / Data Layer: Verwenden Sie spezialisierte Plugins (z. B. Schema & Structured Data for WP, RankMath, Yoast) oder ein eigenes JSON‑LD‑Template im Theme. Vorteil: zentrale Verwaltung und Versionierung.
Vermeiden Sie doppelte Markups auf derselben URL. Wenn Google dieselben Angaben mehrfach unterschiedlich interpretiert, entstehen Warnungen. Setzen Sie canonical URLs konsistent und halten Sie das Markup synchron mit sichtbarem Content und Google Business Profile.
Führen Sie eine Testseite ein, fügen das Skript ein und prüfen das Ergebnis. So behalten Sie Änderungskontrolle und minimieren Fehler.
Jetzt kostenfreie Analyse sichern!
JSON‑LD für mehrere Standorte: Muster, Varianten und Best Practices
Mehrere Standorte sollten nie als unstrukturierter Block gepflegt werden. Für 2–10 Filialen ist ein einzelnes JSON‑LD mit einem @graph‑Array empfehlenswert; bei Dutzenden oder mehr ist ein automatisierter Export die bessere Wahl.
Variante A — @graph (kleine Ketten):
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"name": "Bäckerei Mitte",
"url": "https://www.ihre-domain.de/filiale-mitte",
"address": { "@type": "PostalAddress", "streetAddress": "Mitte 1", "addressLocality": "Berlin", "postalCode": "10115", "addressCountry": "DE" }
},
{
"@type": "LocalBusiness",
"name": "Bäckerei West",
"url": "https://www.ihre-domain.de/filiale-west",
"address": { "@type": "PostalAddress", "streetAddress": "West 2", "addressLocality": "Berlin", "postalCode": "10559", "addressCountry": "DE" }
}
]
}
</script>
Variante B — Separate Seiten (empfohlen bei mehreren Hundert Standorten): Jede Filiale hat eine eigene URL und eigenes JSON‑LD auf der jeweiligen Seite. Zentraler Index: eine Übersichtsseite mit Links und minimalem Markup pro Listeneintrag.
Best Practices:
- Jede Location braucht eine eindeutige URL (preferred).
- Vermeiden Sie das Bereitstellen aller Standorte auf einer einzelnen generischen „Alle Filialen“-Seite ohne individuelle Unterseiten.
- Synchronisieren Sie Öffnungszeiten mit Google Business Profile per API oder manuellem Update.
Denkpause: Betrachten Sie Standorte wie Leuchttürme; jeder muss einzeln sichtbar und gleichzeitig im Verbund steuerbar sein.
Skalierbare Datenverwaltung (CSV/Template/Automatisierung)
Manuelle Pflege mag bei wenigen Standorten genügen. Bei vielen Filialen führt sie jedoch schnell zu Inkonsistenzen. Automatisierung steigert die Wartbarkeit.
Technischer Ablauf für Skalierung (4 Schritte):
- Pflegen Sie eine Master‑CSV/Excel mit Spalten: id, name, url, street, city, postalCode, country, lat, lng, phone, opens, closes, image, rating.
- Nutzen Sie ein Template (z. B. Mustache, Handlebars oder ein PHP/Python‑Skript), das CSV‑Zeilen in JSON‑LD‑Blöcke rendert.
- Deployen Sie generierte JSON‑LD‑Dateien automatisiert in Ihre CMS‑Seiten (z. B. via API oder FTP‑Push).
- Automatisieren Sie Tests: Rich Results Test API oder Schema‑Validator in CI‑Pipeline einbinden.
Tools & Integrationen: Google Business Profile API (für Synchronisation), Skripte in Node/Python oder ein Headless CMS mit Datenmodellen. Bei mittlerer bis großer Filialzahl empfehlen sich regelmäßige Cron‑Jobs für Datenexport und Validierung.
Kleiner Tipp: Führen Sie ein Änderungslog (who/when), damit Sie bei Problemen schnell die verantwortliche Änderung zurückverfolgen können.
Rich Snippets & SERP‑Features: Was Sie erwarten können
Strukturierte Daten erhöhen die Chance auf Rich Snippets, garantieren sie aber nicht. Google entscheidet algorithmisch, ob und wann ein Rich Snippet ausgeliefert wird.
Typische SERP‑Features für lokale Unternehmen:
- Local Pack / Maps‑Einträge
- Knowledge Panel (bei eindeutigen Markenprofilen)
- Rich Snippets: Bewertungen, Preisangaben, Öffnungszeiten
- Event‑ oder Offer‑Cards für Aktionen
Was beeinflusst die Ausspielung? Relevanz, Vertrauenssignale (Reviews, Domainautorität), Konsistenz der NAP‑Daten und Nutzerabsicht. Ein korrektes Markup erhöht die Wahrscheinlichkeit deutlich, ist aber nur ein Faktor im Gesamtalgorithmus.
Praktischer Rat: Konzentrieren Sie sich zuerst auf Elemente mit dem größten Klick‑Impact — Öffnungszeiten, Telefonnummer und AggregateRating. Diese beeinflussen Nutzerentscheidungen direkt und sind relativ einfach zu implementieren.
Ergänzen Sie ein Rating‑Snippet, wenn echte Bewertungen vorliegen. Fälschen Sie nie Daten; das Risiko von Strafen ist real.
Validierung & Fehlerbehebung: Tools, typische Fehler und wie man sie behebt
Rund 60–70 % aller initialen Markups liefern Warnungen oder Fehler, typischerweise Format‑ oder Pflichtfeldprobleme. Daher ist Testen ein Muss.
Typische Fehler und schnelle Lösungen:
- Fehlerhafte JSON‑Syntax: Fehlendes Komma, falsche Anführungszeichen — Validieren mit JSONLint.
- Nicht übereinstimmende sichtbare Inhalte: Markup nennt andere Öffnungszeiten als die Seite — Korrigieren Sie sichtbare Inhalte zuerst.
- Falsche Datentypen: latitude/longitude als String — Ändern Sie zu Zahlen.
- Duplicate Entries: Mehrfaches Markup mit unterschiedlichen Angaben — Behalten Sie nur eine, eindeutigste Quelle.
- Unvollständige Öffnungszeiten: Nutzen Sie openingHoursSpecification für komplexe Zeiträume.
Fehlerbehebungsschritte (3‑Schritte‑Check):
- JSON‑Syntax mit JSONLint prüfen.
- Rich Results Test für Funktionsfähigkeit und Warnungen verwenden.
- In Google Search Console die betroffene URL neu indexieren und Enhancements überwachen.
Testen Sie jetzt Ihre wichtigsten Seiten und beheben Sie zunächst kritische Fehler (Syntax, NAP, Öffnungszeiten).
Testen mit Rich Results Test und Schema‑Validator
Zwei zentrale Tools erleichtern die Validierung — Googles Rich Results Test und der Schema Markup Validator (schema.org). Beide ergänzen sich; nutzen Sie sie sequentiell.
Schritt‑für‑Schritt (Rich Results Test):
- Öffnen Sie: https://search.google.com/test/rich-results
- Fügen Sie die URL oder den Quellcode ein.
- Starten Sie den Test und prüfen Sie Ergebnisliste (Errors, Warnings).
- Beheben Sie Errors zuerst; Warnungen prüfen und priorisieren.
- Nach Korrektur: URL erneut testen und in Search Console zur erneuten Indexierung einreichen.
Schema Markup Validator (schema.org):
- Prüft Validität in Bezug auf Schema.org‑Standards.
- Hilft, semantische Fehler zu finden, die Google möglicherweise anders bewertet.
- Nutzen Sie beide Tools, um doppelte Perspektiven zu erhalten.
Fehlerdiagnose‑Tipp: Falls ein Element als „nicht für Rich Results geeignet“ markiert ist, prüfen Sie, ob das Feld sichtbar auf der Seite steht. Google bevorzugt sichtbare Inhalte gegenüber reinem Backend‑Markup.
Praktische SEO‑Tipps zur Implementierung (internes Linking, strukturierte Daten vs. Content)
Strukturierte Daten sind kein Ersatz für guten Content. Sie sind ein Verstärker. Investieren Sie parallel in Seiteninhalte, die lokale Relevanz demonstrieren (z. B. standortspezifische Landingpages mit lokalem Content).
Konkrete Maßnahmen:
- Erstellen Sie für jede Filiale eine eigene Landingpage mit lokalem Text, Bildern und Kontaktinfos.
- Verlinken Sie Standortseiten intern von der Startseite und von relevanten Service‑Seiten (klare Navigation, Breadcrumbs).
- Nutzen Sie lokale Keywords natürlich im Content (z. B. „Friseur in Prenzlauer Berg“) — nicht im Markup allein.
- Passen Sie Title/Meta entsprechend an; Rich Snippets steigern CTR, Title bleibt aber entscheidend für Rankingtests.
Markups beantworten die Frage „Was sind die Fakten?“. Content beantwortet „Warum sollte ich hier kaufen?“. Beides zusammen steigert Vertrauen und Rankings.
Legen Sie eine Prioritätenliste an — beginnen Sie mit Top‑3 Standorten nach Umsatz oder Sichtbarkeit und rollen Sie das Markup dann aus.
FAQ: Häufige Fragen zu strukturierte daten für lokale unternehmen
Häufige Fragen und Antworten:
Muss jede Filiale eine eigene URL haben? Nicht zwingend, aber empfohlen. Jede Filiale als eigene URL erhöht die Chance auf individuelle Rich Results und lokale Indexierung. Bei wenigen Standorten kann ein @graph ausreichen.
Welches Format ist am besten — JSON‑LD oder Microdata? JSON‑LD ist aktuell die bevorzugte Methode (leichtere Wartung, Google‑Empfehlung). Microdata ist möglich, aber wartungsintensiver.
Kann falsches Markup zu Abstrafungen führen? Direkte Abstrafungen sind selten. Probleme entstehen durch inkonsistente oder irreführende Angaben, die Vertrauen reduzieren. Schlimmstenfalls werden Rich Snippets entfernt.
Wie oft sollte ich strukturierte Daten aktualisieren? Bei Änderungen (Öffnungszeiten, Telefonnummern, Filialöffnung/‑schließung) sofort. Ansonsten sind vierteljährliche Audits ein guter Standard.
Woher bekomme ich Bewertungen für aggregateRating? Sammeln Sie echte Kundenbewertungen (Google, Trustpilot, Branchenportale). Nur vertrauenswürdige Quellen verwenden; synthetische Bewertungen sind untersagt.
Gibt es eine API zur Synchronisation mit Google Business Profile? Ja, die Google Business Profile API erlaubt automatisierte Updates für Öffnungszeiten, Adresse und mehr — sinnvoll bei vielen Standorten.
Wie reagiere ich auf Fehler in der Search Console? Priorisieren Sie Errors über Warnings, beheben Sie die Ursache im Markup/Content und fordern Sie Reindexierung an.
Brauche ich einen SEO‑Partner? Vieles lässt sich intern lösen. Bei komplexen Multi‑Location‑Setups oder fehlender Ressourcen ist externe Expertise sinnvoll. Fordern Sie gern Unterstützung an, wenn Sie Hilfe brauchen.