Strukturierte Daten helfen Suchmaschinen, bestimmte Informationen einer Website einzuordnen: Welches Unternehmen steht hinter einer Seite? Welche Dienstleistung wird beschrieben? Wo liegt eine Seite innerhalb der Navigation? Für solche Angaben wird häufig JSON-LD verwendet – ein Datenformat, das getrennt vom sichtbaren HTML eingebunden werden kann.
Das reine Vorhandensein eines <script type="application/ld+json">-Blocks sagt allerdings wenig über seine Qualität aus. Ein guter Check untersucht mehrere Ebenen: korrekte Syntax, plausible Aussagen, Beziehungen zwischen den Objekten und die Anforderungen der jeweiligen Suchmaschine.
1. Ist das JSON-LD syntaktisch gültig?
Als Erstes muss der Inhalt jedes JSON-LD-Scriptblocks korrektes JSON sein. Häufige Ursachen für Fehler sind fehlende Anführungszeichen, ein überflüssiges Komma am Ende einer Liste oder ungültige Zeichen.
Ein sehr kleines Beispiel:
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Beispielunternehmen",
"url": "https://www.beispiel.de/"
}Diese Grundstruktur lässt sich mit einem JSON-Parser prüfen. Aber: Syntaktisch gültiges JSON bedeutet noch nicht, dass alle Schema.org-Angaben sinnvoll sind.
2. Stimmen die verwendeten Schema.org-Typen?
WebSite beschreibt die gesamte Website, WebPage eine einzelne Unterseite, Service eine Dienstleistung und BreadcrumbList die hierarchische Navigation. Ein Unternehmen kann etwa über Organization oder – wenn passend – einen spezifischeren Typ wie ProfessionalService beschrieben werden.
Ein Validator sollte erkennen, welche Typen im Dokument vorkommen. Anschließend muss er prüfen, ob die genutzten Eigenschaften zu diesen Typen passen. Nicht jeder fehlende Wert ist automatisch ein Fehler: Schema.org kennt zahlreiche optionale Angaben.
3. Sind die Objekte über @id miteinander verbunden?
Sobald mehrere strukturierte Objekte auf einer Seite stehen, ist eine konsistente Identität wichtig. Mit @id kann ein Unternehmen über viele Unterseiten hinweg eindeutig referenziert werden.
Ein beispielhafter Service-Verweis sieht so aus:
{
"@type": "Service",
"@id": "https://www.beispiel.de/leistungen/#service",
"name": "Website-Entwicklung",
"provider": {
"@id": "https://www.beispiel.de/#unternehmen"
}
}Der provider sollte auf ein tatsächlich definiertes Unternehmensobjekt verweisen. Ohne eine solche Prüfung können doppelte oder widersprüchliche Unternehmensangaben unbemerkt bleiben.
4. Passen URL und tatsächlicher Seiteninhalt zusammen?
Ein Service-Schema für Webdesign gehört auf eine Seite, die wirklich diese Leistung behandelt – nicht auf eine beliebige Seite, die zufällig dasselbe Skript einbindet.
Auch die kanonische URL verdient Aufmerksamkeit. Wenn die Seite unter /leistungen/webdesign/ erreichbar ist, sollten ihre seitenbezogenen strukturierten Daten nicht unbeabsichtigt auf /leistungen/shopify/ zeigen.
Dabei sind Weiterleitungen und Canonical-Angaben zu berücksichtigen. Eine identische Vorlage auf allen URLs ohne passenden Seitenbezug ist keine saubere Lösung.
5. Werden Unternehmen und Standort korrekt beschrieben?
Gerade im lokalen SEO passieren Copy-and-Paste-Fehler: Eine Kundenadresse landet im Unternehmensschema der Agentur, eine Telefonnummer ist veraltet oder mehrere widersprüchliche Standorte werden angegeben.
Die Angaben sollten mit den echten Unternehmensdaten übereinstimmen. Mehrere regionale Leistungsseiten bedeuten nicht automatisch mehrere Niederlassungen.
Für lokale Dienstleistungen lohnt sich außerdem die Unterscheidung zwischen Geschäftsstandort und Einsatzgebiet. Die Eigenschaft areaServed kann ein Tätigkeitsgebiet beschreiben, ohne dort eine zusätzliche Geschäftsadresse zu behaupten.
6. Ist das Schema für ein Google-Rich-Result geeignet?
Hier muss man zwei unterschiedliche Fragen auseinanderhalten:
- Ist eine Angabe nach Schema.org sinnvoll und technisch korrekt?
- Unterstützt Google für diesen konkreten Inhalt überhaupt ein besonderes Suchergebnis, und sind dessen Anforderungen erfüllt?
Nicht jeder Schema.org-Typ erzeugt eine hervorgehobene Darstellung bei Google. Auch ein vollständig korrektes Markup ist keine Garantie für Rich Results, bessere Rankings oder mehr Klicks.
Für Googles unterstützte Funktionen ist der Rich Results Test ein wichtiger zusätzlicher Prüfschritt. Er ersetzt nicht die allgemeine Prüfung der Schema.org-Struktur.
7. Werden Änderungen wiederholt getestet?
Ein besonders häufiger Fehler entsteht nicht beim ersten Einbau, sondern später: Eine Komponente wird umgebaut, Seiten werden umbenannt oder URLs geändert. Bestehende Verweise zeigen anschließend ins Leere.
Bei Digitalhaus Kunze setzen wir deshalb nicht nur JSON-LD ein, sondern kontrollieren die Struktur auch beim technischen Website-Build. Automatisierte Tests prüfen dabei unter anderem, ob die IDs für WebSite, WebPage, Service und Breadcrumbs zueinanderpassen.
Das ist ein gutes Beispiel dafür, wie technisches SEO und kontinuierliche Qualitätssicherung zusammenarbeiten können.
Eine sinnvolle Reihenfolge für deine Website
- JSON-LD-Blöcke auf der betroffenen URL finden und die Syntax validieren.
- Die verwendeten Typen und ihre Eigenschaften gegen Schema.org prüfen.
@id-Referenzen sowie Canonical- und Seiten-URLs vergleichen.- Kontrollieren, ob die Aussagen durch den sichtbaren Seiteninhalt gedeckt sind.
- Google-Anforderungen nur für tatsächlich unterstützte Rich-Result-Typen testen.
- Nach Änderungen erneut prüfen – idealerweise automatisiert.
Zum ersten Überblick kannst du deine Website mit unserem kostenlosen SEO-Checker prüfen. Das Tool erkennt unter anderem, ob auf den geprüften Seiten JSON-LD vorhanden ist; eine vollständige Schema.org- oder Rich-Result-Validierung ersetzt es ausdrücklich nicht.
Fazit: Strukturierte Daten sollten kein einmaliger SEO-Haken auf einer Checkliste sein. Sie sind Teil einer konsistenten technischen Website-Struktur.
Wenn du deine Website systematisch verbessern möchtest, findest du weitere Informationen auf unserer Seite zu technischem SEO und Performance. Für die technische Umsetzung unterstützen wir dich auch direkt bei deiner Website.
War dieser Artikel hilfreich?
Dein Feedback hilft uns, unsere Ratgeber zu verbessern.
Mit Digitalhaus Kunze gearbeitet?
Dann freuen wir uns über deine ehrliche Erfahrung auf Google – unabhängig davon, ob sie positiv oder kritisch war.
Auf Google bewerten