Eric Hinzpeter
TOOL· seo · schema · json-ld· Live

JSON-LD Generator

JSON-LD per Formular erzeugen oder vorhandenes Markup auf fehlende Pflichtfelder prüfen. 17 Schema.org-Typen von Article bis VideoObject, im Browser.

Tool · JSON-LD-GeneratorSchema.org

Ausgabe

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article"
}
</script>

Der JSON-LD-Generator baut Schema.org-Markup zum Copy-paste, ohne dass du die Syntax auswendig kennen musst. Zwei Reiter: Erzeugen füllt ein Formular aus und liefert fertiges JSON-LD, Prüfen nimmt vorhandenes Markup und sagt dir, welches Pflichtfeld fehlt. Genau wie bei den anderen elf kostenlosen Tools läuft beides komplett im Browser, nichts geht an einen Server.

Gedacht ist das für alle, die strukturierte Daten selbst pflegen. WordPress ohne SEO-Plugin, ein selbst gebautes CMS, oder einfach der Fall, dass ein Plugin ein Feld nicht abdeckt, das du brauchst.

So funktioniert es

Im Reiter Erzeugen wählst du einen von 17 Typen, von Article über Product bis VideoObject. Das Formular passt sich dem Typ an. FAQPage und HowTo bekommen dynamische Zeilen für Frage und Antwort oder für einzelne Schritte, BreadcrumbList genauso für jede Krume im Pfad. Alle anderen Typen zeigen feste Felder, Pflichtfelder sind mit einem Stern markiert.

Was du leer lässt, taucht im Ergebnis gar nicht erst auf. Das Tool entfernt leere Felder aus dem JSON, bevor es sie ausgibt, damit du nie ein "image": "" live schaltest. Verschachtelte Strukturen baut es automatisch.

Trägt ein Product eine Bewertung ein, entsteht daraus ein sauberes AggregateRating-Objekt. Ein Event bekommt seinen Ort als Place verpackt, eine Person mit Arbeitgeber eine eingebettete Organization. Am Ende kopierst du das Ergebnis mit oder ohne <script type="application/ld+json">-Hülle, per Umschalter oben rechts im Ausgabefeld.

Der Reiter Prüfen geht den umgekehrten Weg. Du fügst rohes JSON-LD ein, ein Script-Tag oder gleich den kompletten Quelltext einer Seite. Sieht die Eingabe nach HTML aus, zieht das Tool jeden ld+json-Block heraus und prüft ihn einzeln. Das gilt auch, wenn er in einem @graph-Array steckt, wo viele SEO-Plugins ihr Markup verstecken.

Geprüft wird gegen dieselben 17 Typen plus die Entitäten, die meistens darin eingebettet sind: Offer, AggregateRating, Rating, ListItem, ItemList. Fehlt einem Product bei seinem Offer die Währungsangabe, meldet das Tool das, selbst wenn das Product selbst vollständig aussieht. Gängige Subtypen löst es automatisch auf.

Ein BlogPosting prüft es wie ein Article, ein Restaurant wie ein LocalBusiness. Kennt es einen Typ nicht, gibt es nur einen Syntax-Check, mit einem klaren Hinweis: mehr wurde nicht geprüft.

Wann du es brauchst

  • Du willst FAQ- oder Artikel-Markup auf eine Seite bringen, ohne JSON von Hand zu tippen.
  • Du willst wissen, was dein SEO-Plugin tatsächlich ausgibt. Quelltext der Seite reinkopieren, sehen, welche Entitäten drinstecken.
  • Ein Rich Result ist plötzlich weg, und du suchst den Grund. Ein fehlendes Pflichtfeld ist meistens die Antwort.

Was strukturierte Daten wirklich bringen

Strukturierte Daten ändern nicht, wie eine Seite rankt. Sie ändern, was Google mit einer Seite anstellen kann, die schon gut genug rankt, um in den Ergebnissen aufzutauchen. Ein FAQPage-Markup macht aus einem blauen Link ein aufklappbares Snippet mit den Fragen direkt im Suchergebnis.

Ein Product mit Offer und AggregateRating kann Preis und Sterne neben dem Titel zeigen. BreadcrumbList ersetzt die nackte URL durch eine lesbare Pfadangabe. Das sind zusätzliche Klickflächen, kein Rankingfaktor im klassischen Sinn.

Entscheidend ist der Unterschied zwischen valide und berechtigt. Valide heißt: Das JSON parst, die Pflichtfelder sind da, Google kann die Entität lesen. Berechtigt für ein Rich Result heißt zusätzlich, dass Google die Seite für diese Darstellung als geeignet einstuft. Das entscheidet Google nach eigenen Qualitätsrichtlinien, unabhängig davon, ob dein Markup technisch sauber ist.

Beides sind getrennte Prüfungen. Dieses Tool und die Google-Dokumentation, an der sich die Regeln im Prüfen-Reiter orientieren, decken nur die erste ab. Valides Markup ist die Eintrittskarte, keine Garantie, dass die Vorstellung auch stattfindet.

Google liest dabei nicht jedes Feld gleich streng. Bei Article reichen headline und ein author-Objekt für die Basis, image und datePublished sind empfohlen, aber nicht hart erforderlich.

Bei JobPosting dagegen ist Google ungewöhnlich strikt. Fehlen title, description, hiringOrganization, datePosted oder jobLocation, verschwindet die Stelle komplett aus Google for Jobs. Wer die Regeln pro Typ nicht auswendig kennt, findet sie im Prüfen-Reiter als konkrete Fehlermeldung statt als PDF zum Durchsuchen.

KI-Suchmaschinen parsen JSON-LD genauso wie Google, weil es die sauberste maschinenlesbare Aussage ist, wer du bist und was eine Seite behauptet. Ranking-Wunder würde ich davon nicht erwarten, aber kaputtes Markup lässt Information liegen, die nichts kostet zu reparieren. Ob sich das am Ende in messbarem Traffic zeigt, siehst du eher in den Search-Console-Zahlen als am Rich Result selbst.

JSON-LD statt Microdata: warum das Format zählt

Es gibt drei Wege, Schema.org-Daten in eine Seite zu bringen: JSON-LD, Microdata und RDFa. Google empfiehlt JSON-LD, und in der Praxis hat sich genau das durchgesetzt, aus einem einfachen Grund. Microdata verlangt itemscope- und itemprop-Attribute mitten im sichtbaren HTML, verwoben mit dem Layout.

Ändert sich das Template oder räumt jemand die CSS-Klassen auf, bricht die Struktur mit, ohne dass im Frontend irgendetwas anders aussieht. JSON-LD sitzt als eigener Script-Block, meistens im <head>, komplett getrennt vom sichtbaren Markup. Man kann die Daten ändern, ohne das Design anzufassen, und umgekehrt.

Das ist auch, warum praktisch jedes SEO-Plugin JSON-LD ausgibt statt Microdata. Die Daten kommen aus der Datenbank, der Script-Block wird bei jedem Request neu zusammengesetzt. Das Template merkt davon nichts.

Der Prüfen-Reiter dieses Tools geht deshalb von einem Script-Tag oder einem ganzen Seitenquelltext aus, nicht von einzelnen HTML-Attributen. Das ist, wo die Daten heute tatsächlich stehen.

Was es nicht kann

Der Prüfen-Reiter bewertet Struktur, nicht Wahrheit. Trägst du bei einer Review eine Bewertung von fünf Sternen ein, prüft das Tool nur, ob das Feld vorhanden und im richtigen Format ist. Ob die Bewertung echt ist, prüft es nicht. Das ist Absicht: Über Spam und Manipulation entscheidet Google mit eigenen, unabhängigen Signalen, die dieses Tool weder kennt noch ersetzen soll.

Es holt sich auch keine Seite selbst, du fügst HTML oder JSON manuell ein, gecrawlt wird nichts. Außerhalb der 17 Generator-Typen, ihrer gängigsten Subtypen und der fünf verschachtelten Entitäten (Offer, AggregateRating, Rating, ListItem, ItemList) gibt es nur einen Syntax-Check mit Hinweis. Eine echte Feldprüfung findet dort nicht statt.

Für den letzten verbindlichen Check vor dem Livegang bleibt Googles eigener Rich Results Test die Instanz. Den Meta Checker oder den KI-Floskeln-Checker kannst du für die restliche Seite gleich danach mitlaufen lassen.

FAQ

Verbessert JSON-LD mein Ranking?
Nein. Strukturierte Daten ändern nicht, wie eine Seite rankt, sondern was Google mit einer Seite anstellen kann, die ohnehin in den Ergebnissen auftaucht. FAQPage macht aus dem blauen Link ein aufklappbares Snippet, Product mit Offer und AggregateRating zeigt Preis und Sterne, BreadcrumbList ersetzt die nackte URL durch einen lesbaren Pfad. Das sind zusätzliche Klickflächen, kein Rankingfaktor.
Mein Markup ist valide, das Rich Result kommt trotzdem nicht. Warum?
Weil valide und berechtigt zwei verschiedene Prüfungen sind. Valide heißt: Das JSON parst, die Pflichtfelder stehen drin, Google kann die Entität lesen. Berechtigt heißt zusätzlich, dass Google die Seite für diese Darstellung als geeignet einstuft, und das entscheidet Google nach eigenen Qualitätsrichtlinien. Dieses Tool deckt nur die erste Hälfte ab.
Kann ich den kompletten Quelltext einer Seite einfügen?
Ja. Sieht die Eingabe nach HTML aus, zieht der Prüfen-Reiter jeden ld+json-Block einzeln heraus, auch wenn er in einem @graph-Array steckt, wo viele SEO-Plugins ihr Markup ablegen. So siehst du, was dein Plugin tatsächlich ausgibt, statt was es verspricht.
Welche Typen prüft der Prüfen-Reiter?
Dieselben 17 Typen wie der Generator, dazu die Entitäten, die meistens darin eingebettet sind: Offer, AggregateRating, Rating, ListItem und ItemList. Gängige Subtypen löst er auf, ein BlogPosting wird wie ein Article geprüft, ein Restaurant wie ein LocalBusiness. Kennt er einen Typ nicht, bleibt es beim Syntax-Check, und das steht dann auch so als Hinweis da.
Warum JSON-LD statt Microdata?
Microdata verlangt itemscope- und itemprop-Attribute mitten im sichtbaren HTML, verwoben mit dem Layout. Ändert jemand das Template oder räumt die CSS-Klassen auf, bricht die Struktur mit, ohne dass im Frontend etwas anders aussieht. JSON-LD sitzt als eigener Script-Block, meistens im head, getrennt vom Markup, und lässt sich ändern, ohne das Design anzufassen. Google empfiehlt es deshalb, und praktisch jedes SEO-Plugin gibt es so aus.