JSON-LD-Grundlagen.

JSON-LD ist das Format für strukturierte Daten, das die Bedeutung einer Seite maschinenlesbar mitteilt, ohne ein einziges Pixel der Seite zu verändern.

Ein Mensch, der eine Seite liest, erschließt aus Überschriften und Text, was was ist: Das ist eine Leistungsbeschreibung, das ein Preis, das ein Autorenname. Für eine Maschine ist derselbe Schluss Rätselraten und fehleranfällig. Strukturierte Daten beseitigen das Raten: Ein in die Seite eingebetteter Block sagt „das ist eine Organisation, ihr Name ist X, ihr Gründer Y, das ist die angebotene Leistung“. Der Block ist auf dem Bildschirm unsichtbar — und doch die Schicht, die Maschinen am aufmerksamsten lesen.

Es gibt drei Formate, aber in der Praxis wird eines bevorzugt. Die anderen beiden streuen das Markup ins HTML; dieser Ansatz ist schwer zu warten und bricht leicht, wenn sich das Layout ändert. JSON-LD steht dagegen als eigener Block, unabhängig vom HTML, und bleibt gleich, selbst wenn sich die visuelle Struktur der Seite völlig ändert. Es ist auch das Format, das Google ausdrücklich empfiehlt.

Die Grundstruktur

Ein JSON-LD-Block beginnt mit einem Feld, das den Kontext angibt, danach folgen die Knoten. Jeder Knoten hat einen Typ — Organisation, Person, Artikel, Dienst — und die auf schema.org für diesen Typ definierten Felder werden gefüllt. Eine einzelne Seite kann mehrere Knoten tragen, und das wird auch erwartet; der eigentliche Wert liegt darin, die Knoten miteinander zu verbinden.

Verbunden wird über Identitäten. Jeder Knoten erhält eine feste Kennung, und andere Knoten verweisen auf sie. So wird die Organisation einmal definiert, die Person einmal definiert, und der Seitenknoten zeigt auf beide. Ohne dieses Muster ist der Graph eine verstreute Halde: zehn verschiedene Organisationsangaben oder zehn Wiederholungen derselben — nicht zu unterscheiden.

1. Ein Block, viele Knoten — alle Knoten der Seite sammeln sich in einem einzigen Graphen.
2. Feste Identitäten — Organisation, Person und Website werden einmal definiert und von überall referenziert.
3. Der eigene Knoten der Seite — jede Seite trägt ihre Identität und bindet sich an die Website.
4. Der Brotkrumenpfad — die Position der Seite in der Hierarchie, auch im Suchergebnis sichtbar.
5. Der Inhaltsknoten — je nach Seitentyp Artikel, Dienst, Produkt oder Definition.

Der häufigste Fehler

Die gefährlichste Verwendung strukturierter Daten ist, etwas anzugeben, das nicht auf dem Bildschirm steht. Eine nicht sichtbare Bewertung, ein nicht gelistetes Frage-Antwort-Paar oder ein nicht geschriebener Preis im Schema erzeugt zwei Probleme zugleich: Es ist ein klarer Verstoß gegen die Suchmaschinenregeln und kann Sanktionen tragen, und die Seite gerät in Widerspruch zu sich selbst. Findet das Modell im Text nicht, was das Schema sagt, steigt das Vertrauen nicht — es sinkt.

Das richtige Muster ist einfach: Das Schema übersetzt die ohnehin auf dem Bildschirm stehende Information in Maschinensprache. Es fügt keine neue Information hinzu, es strukturiert die vorhandene. Auf dieser Website wird die Regel vom Code geschützt — die häufig gestellten Fragen der Leistungsseiten stehen sowohl im Schema als auch auf dem Bildschirm, und die Prüfsuite misst bei jedem Lauf, dass beide übereinstimmen.

Das Schema fügt keine neue Information hinzu; es übersetzt die vorhandene in Maschinensprache.

Wo man anfängt

Einen Graphen von null aufzubauen kann einschüchtern, aber die Reihenfolge steht fest, und jeder Schritt stützt sich auf den vorigen. Zuerst die Identität: der Organisations- oder Personenknoten, mit fester Kennung. Dann der Website-Knoten und der eigene Knoten jeder Seite. Dann der Brotkrumenpfad — er speist sowohl die Navigationsstruktur als auch die Darstellung im Suchergebnis. Zuletzt die seitentypischen Knoten: Artikel, Dienst, Definition, Frage-Antwort.

Diese Reihenfolge lässt sich überspringen, aber dann laufen die oberen Schichten ins Leere. Ein Artikelknoten ohne Identitätsknoten kann seinen Autor nicht zeigen; ein Seitenknoten ohne Website-Knoten kann nicht sagen, zu welcher Website er gehört. Der Wert des Graphen liegt in den Verknüpfungen, und die werden vom Zentrum nach außen gebaut.

Auch die Wartungsseite darf nicht vergessen werden: Von Hand geschriebene Schemata trennen sich binnen weniger Monate von der Wirklichkeit. Die Seite ändert sich, das Schema bleibt. Deshalb sollte das Schema vom Generator aus den Daten der Seite selbst erzeugt werden — so wird die Abweichung strukturell unmöglich.

Validierung und häufige Brüche

Statt anzunehmen, dass ein geschriebenes Schema wirklich gelesen werden kann, muss man es validieren, und das hat zwei Schichten. Die erste ist die Syntax: Ist der Block eine gültige Datenstruktur, lässt er sich parsen? Ein einziges fehlendes Komma macht den ganzen Block ungültig, und sämtliche strukturierten Daten dieser Seite werden ignoriert. Die zweite ist die Bedeutung: Erzählt die entstandene Knotenliste, was die Website wirklich ist? Ein fehlerfreier, aber bedeutungsloser Graph ist technisch gültig und nützt nichts.

Die häufigsten Bruchstellen sind bekannt. Formlos geschriebene Datumsfelder — ein maschinenlesbares Datum verlangt ein Standardformat, freier Text wird nicht akzeptiert. Ins Leere zeigende Identitätsverweise — zeigt ein Knoten auf eine nicht existierende Kennung, kommt die Verbindung nicht zustande. Und leergelassene Pflichtfelder — manche Typen erzeugen ohne bestimmte Felder kein Rich-Ergebnis.

Diese Kontrollen von Hand zu machen hilft genau einmal; die dauerhafte Lösung ist die Automatisierung. Eine kurze Prüfung, die bei jedem Deployment die Schemablöcke aller Seiten parst und die Knotentypen berichtet, macht den Bruch sofort sichtbar. Auf dieser Website lebt diese Prüfung in der Prüfsuite und misst auf jeder Route, dass der Schemagraph die erwarteten Knoten trägt.

Schließlich die Frage des gemeinsamen Alterns von Schema und Inhalt. Wird der Text einer Seite aktualisiert, muss auch das Datumsfeld im Schema aktualisiert werden; sonst trennen sich die maschinenlesbare und die sichtbare Schicht, und das Frischesignal wird falsch. Auf dieser Website hängen die Datumsfelder an einem Verzeichnis, und das Verzeichnis schreitet nur voran, wenn sich die AUSGABE der Seite wirklich ändert — ein Datum, das bei jedem Build auf heute springt, würde mit der Zeit zu einem Signal, das niemand mehr beachtet. Die richtige Frischeangabe ist die, die auf die wirklich geänderte Seite zeigt.

Welche Typen wirklich nützen

Schema.org definiert Hunderte Typen, und alle verwenden zu wollen ist ein Fehler; die meisten werden von keiner Such- oder Antwortmaschine gesondert verarbeitet. In der Praxis sind die Typen, die den Unterschied machen, wenige — und sie hängen vom Typ der Website ab. Für eine Beratungswebsite liefern Organisation, Person, Dienst, Artikel und Frage-Antwort fast den gesamten Nutzen; der Rest ist Rauschen.

Das Auswahlkriterium muss lauten: Beschreibt dieser Typ etwas, das auf der Seite wirklich existiert? Für den Produkttyp braucht es ein echtes Produkt, für das Produktschema einen echten Preis. Einen Typ zu wählen, um etwas nicht Existierendes anzugeben, heißt von Anfang an den falschen Weg zu gehen. Auf dieser Website wird kein Preis angegeben, weil die Website keine Preise veröffentlicht — und die Prüfsuite kontrolliert, dass kein erfundenes Preisfeld hinzugekommen ist.

Dazu die Frage des Umfangs: Statt jeden Typ auf jede Seite zu setzen, genügt pro Seite ein einziger, dem Seitentyp entsprechender Hauptknoten mit den ihn umgebenden Identitätsknoten. Auf einer Beitragsseite ist der Artikelknoten der Hauptknoten, auf einer Leistungsseite der Dienstknoten; beide auf dieselbe Seite zu setzen trübt die Struktur.