Website-Inhalte für Suchmaschinen beschreiben: JSON-LD richtig einbauen und prüfen

JSON-LD beschreibt Seiteninhalte in einer maschinenlesbaren Form. Ein Rich Result ist ein Suchergebnis mit zusätzlichen Angaben, beispielsweise einem Produktpreis oder einer Bewertung. Ein syntaktisch gültiger Block ist jedoch noch kein Nachweis für ein passendes Google-Rich-Result. Vier Prüfungen gehören zusammen: gültiges JSON, richtig verwendetes Vokabular, Anforderungen der jeweiligen Suchfunktion und Übereinstimmung mit der sichtbaren Seite.

Fehler bleiben im normalen Seitenbild oft unsichtbar, lassen sich aber durchaus mit Prüfwerkzeugen erkennen. Umgekehrt beweist ein fehlendes Rich Result keinen Fehler. Selbst korrekte und geeignete Auszeichnung garantiert keine bestimmte Darstellung oder Platzierung.

1. Format, Vokabular und Suchfunktion trennen

@context legt fest, wie kurze Begriffe interpretiert werden. Für gewöhnliche Schema.org-Auszeichnung ist "@context": "https://schema.org" eine klare Standardform. JSON-LD erlaubt aber auch Kontextobjekte und vollständig ausgeschriebene Kennungen. Damit sind mehrere technisch gültige Darstellungen möglich.

Typnamen behalten die Schreibweise des Vokabulars: Article bezeichnet den Schema.org-Artikeltyp, article nicht. Ein JSON-Parser prüft lediglich den formalen Aufbau, etwa Kommas und Anführungszeichen; die Erkennung eines bekannten Typs benötigt eine zusätzliche Vokabularprüfung. Mehrere zusammengehörige Objekte können in @graph oder in getrennten Skriptblöcken stehen.

Schema.org beschreibt mehr Eigenschaften als einzelne Google-Suchfunktionen nutzen. Deshalb sind eine erfolgreiche JSON-Prüfung, eine Schema.org-Prüfung und die Eignung für eine Google-Darstellung verschiedene Ergebnisse. Die aktuelle Dokumentation der gewünschten Suchfunktion bestimmt deren Pflicht- und Empfehlungsfelder.

2. Werte passend zur Bedeutung ausgeben

Vorlagen sollten Veröffentlichungszeitpunkt, aktuellen Preis und Bildadresse aus den fachlichen Ausgangswerten erzeugen. Eine bereits lokalisierte Preiszeichenfolge ist keine geeignete Rechengrundlage. Dezimalstellen richten sich nach Währung und Preismodell; zwei Stellen passen zum gezeigten EUR-Beispiel, nicht pauschal zu jeder Währung.

3. Article: hilfreiche Angaben ohne erfundene Pflichtfelder

Die aktuelle Google-Dokumentation nennt für Article keine verpflichtenden Eigenschaften. headline gehört zu den empfohlenen Angaben. Ein sinnvoller Datensatz beschreibt dennoch den tatsächlichen Titel, Autor, Veröffentlichungs- und Änderungszeitpunkt sowie repräsentative Bilder.

Das folgende Beispiel ist ausschließlich eine Vorlage für eine passende Artikelseite. Domain, Bilder, Autorprofil und Zeitpunkte sind Beispieldaten und müssen den tatsächlichen sichtbaren Angaben entsprechen. Die Produktvorlage im späteren Abschnitt gehört auf eine Produktseite; beide Beispiele sind keine zusätzliche Auszeichnung dieses Tutorials.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.example.com/blog/json-ld/#article",
  "headline": "JSON-LD: verlässliche Werte und klare Prüfung",
  "image": [
    "https://www.example.com/images/json-ld-16x9.jpg",
    "https://www.example.com/images/json-ld-4x3.jpg",
    "https://www.example.com/images/json-ld-1x1.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "Lukas Wojcik",
    "url": "https://www.example.com/about/"
  },
  "datePublished": "2026-08-26T10:00:00+02:00",
  "dateModified": "2026-09-02T14:30:00+02:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.example.com/blog/json-ld/"
  }
}
</script>

Für headline besteht keine starre Google-Grenze von 110 Zeichen. Lange Titel können abhängig von der Darstellung gekürzt werden. Autorenobjekte mit Person oder Organization und einer passenden Profiladresse erleichtern eine eindeutige Zuordnung. Änderungsdaten sollten tatsächliche Änderungen wiedergeben statt bei jedem Abruf neu gesetzt zu werden. Veröffentlichungs- und Änderungszeitpunkt müssen zeitlich plausibel sein.

Google empfiehlt für Artikel mehrere hochauflösende, passende Bilder in 16:9, 4:3 und 1:1. Die drei Beispieladressen dürfen nur übernommen werden, wenn solche Bildfassungen tatsächlich existieren. Ein Logo oder ein rein dekoratives Symbol ersetzt kein repräsentatives Artikelbild.

4. FAQPage: Vokabular bleibt, Google-Darstellung entfällt

Seit dem 7. Mai 2026 zeigt Google keine FAQ-Rich-Results mehr. Die frühere Beschränkung auf bekannte Behörden- und Gesundheitsseiten beschreibt daher nicht mehr den aktuellen Stand. Im Juni 2026 wurde auch die Dokumentation der Google-Funktion entfernt. Der Schema.org-Typ FAQPage besteht unabhängig davon weiter.

Frage-Antwort-Auszeichnung kann für eine interne Suche oder eine ausdrücklich dafür gebaute Anwendung nützlich sein. Daraus folgt kein zugesicherter Vorteil bei KI-Assistenten oder anderen Suchdiensten. Die Anwendung muss das Format tatsächlich auswerten.

Die Übereinstimmung mit zugänglichen Seiteninhalten ist keine Besonderheit von FAQ. Auch Artikel-, Produkt- und Bewertungsdaten dürfen keine erfundenen oder irreführenden Angaben enthalten. Ein funktionierender aufklappbarer Antwortbereich ist etwas anderes als eine Antwort, die ausschließlich im JSON steht. Verstöße können Maßnahmen auslösen. Nicht jeder Darstellungsfehler führt automatisch zu einer manuellen Maßnahme.

5. Product: Produktsnippets und Händlerangebote unterscheiden

Für ein Google-Produktsnippet nennt die Dokumentation name und mindestens eine der Eigenschaften review, aggregateRating oder offers. Ein Angebotsblock ist also nicht für jedes Produktsnippet zwingend. Händlerdarstellungen haben eigene Anforderungen; ein einfaches Beispiel erfüllt nicht automatisch jede Shopping-Funktion.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.example.com/switch/#product",
  "name": "Kompakter PoE-Switch, 8 Anschlüsse",
  "image": [
    "https://www.example.com/images/switch.png"
  ],
  "brand": {
    "@type": "Brand",
    "name": "Example"
  },
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.example.com/switch/"
  }
}
</script>

Das Beispiel beschreibt ein sichtbares Angebot über 149,00 EUR. priceCurrency verwendet den dreistelligen ISO-4217-Code. Für availability ist die vollständige Schema.org-Adresse eindeutig; Google unterstützt bei Produktsnippets auch Kurzformen wie InStock. Beide Formen müssen zum tatsächlich verfügbaren Produkt passen.

Zusätzliche Bewertungen brauchen echte, zur Seite passende Grundlagen. Für ein AggregateRating gehören neben ratingValue eine passende Anzahl über ratingCount oder reviewCount sowie gegebenenfalls die abweichende Skala in die Auszeichnung. Ohne echte Bewertungen werden keine Sterne ergänzt, nur um eine Testwarnung zu beseitigen.

6. Prüfung als Teil der Vorlage

1. JSON-Syntax prüfen: doppelte Anführungszeichen, korrekte Kommas und gültige Zeichenkodierung.
2. Typen und Eigenschaften mit einem Schema.org-Prüfer kontrollieren. Das prüft noch keine Google-Darstellung.
3. Für aktuell unterstützte Suchfunktionen den Rich Results Test verwenden und Fehler von Empfehlungen unterscheiden.
4. Die ausgelieferte beziehungsweise gerenderte Seite samt Bildern, tatsächlichen Inhalten und Zugänglichkeit prüfen. Search Console und gegebenenfalls verfügbare Verbesserungsberichte helfen nach der Veröffentlichung.

Auch mehrere bestandene Prüfungen belegen keine garantierte Ausspielung. Automatisierte Tests können zudem nicht jede inhaltlich falsche Bewertung oder irreführende Preisangabe erkennen. Nach Änderungen an Theme, Plugin oder Datenquelle gehört eine erneute Stichprobe zur Wartung.