JSON-LD vs. Microdata vs. RDFa: Structured Data Formate für SEO im Vergleich

Structured Data — auf Deutsch strukturierte Daten — ist eine der mächtigsten, aber am häufigsten falsch genutzten SEO-Techniken. Wer seine Website mit Schema.org-Markup ausstattet, kann in Google Rich Snippets erscheinen: Sternebewertungen, FAQs direkt in den Suchergebnissen, Rezept-Informationen, Veranstaltungsdetails und vieles mehr. Der Klick-Boost durch Rich Snippets kann bis zu 30 % betragen — ein erheblicher Vorteil gegenüber normalen Suchergebnissen.

Das Problem: Es gibt drei verschiedene Wege, Structured Data zu implementieren — JSON-LD, Microdata und RDFa. Welches Format soll man wählen? Welches bevorzugt Google? Und welches ist am einfachsten zu pflegen? Dieser Artikel beantwortet alle drei Fragen mit konkreten Codebeispielen, einer direkten Vergleichstabelle und einer klaren Empfehlung.

Kurze Antwort für Eilige: Google empfiehlt JSON-LD als bevorzugtes Format. Es ist am einfachsten zu implementieren, zu pflegen und von HTML zu trennen. Wenn du neu mit Structured Data anfängst, nutze immer JSON-LD. Die ausführliche Begründung findest du weiter unten.

Was sind Structured Data überhaupt?

Suchmaschinen "lesen" Webseiten, können aber nicht immer verstehen, was der Inhalt bedeutet. Der Text "50 €" könnte ein Preis sein, eine Bewertung, eine Jahreszeit oder eine beliebige Zahl. Structured Data fügt dem HTML-Code maschinenlesbare Metadaten hinzu, die Suchmaschinen sagen: "Dieser Wert ist ein Preis", "Diese Zahl ist eine Bewertung von 1 bis 5", "Dieser Text ist der Name eines Unternehmens".

Das gemeinsame Vokabular dafür liefert Schema.org — ein Gemeinschaftsprojekt von Google, Bing, Yahoo und Yandex. Schema.org definiert hunderte von Typen (Article, LocalBusiness, Product, Event, Recipe, FAQPage, usw.) mit jeweils spezifischen Eigenschaften.

Die Frage ist nur: Wie bindest du dieses Schema.org-Vokabular in deine Website ein? Genau hier kommen JSON-LD, Microdata und RDFa ins Spiel — drei verschiedene technische Implementierungsformate für dasselbe Konzept. Lies dazu auch unseren Grundlagen-Artikel über Strukturierte Daten für SEO: Schema Markup einfach erklärt.

Format 1: JSON-LD — der Goldstandard

JSON-LD steht für "JavaScript Object Notation for Linked Data". Es ist ein eigenständiges <script>-Block im HTML, der strukturierte Daten als JSON-Objekt enthält — vollständig getrennt vom sichtbaren Seiteninhalt.

Wie sieht JSON-LD aus?

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Friseursalon Müller",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Hauptstraße 5",
    "addressLocality": "Berlin",
    "postalCode": "10117",
    "addressCountry": "DE"
  },
  "telephone": "+49 30 12345678",
  "openingHours": "Mo-Fr 09:00-18:00",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  }
}
</script>

Der entscheidende Vorteil: Dieser <script>-Block kann im <head> oder am Ende des <body> stehen — er beeinflusst die sichtbare Darstellung der Seite kein bisschen. Du kannst ihn jederzeit hinzufügen, entfernen oder ändern, ohne das Layout anzufassen.

Vorteile von JSON-LD

Von Google empfohlen — Google nennt JSON-LD explizit als bevorzugtes Format in seiner offiziellen Dokumentation
Vollständig vom HTML getrennt — kein Eingriff in das bestehende Markup nötig
Leicht zu pflegen — Änderungen an einem zentralen Ort, kein Durchsuchen des gesamten HTML
Dynamisch generierbar — Content-Management-Systeme wie WordPress können JSON-LD automatisch aus Datenbankfeldern generieren
Kopierbar und wiederverwendbar — Blöcke lassen sich von Seite zu Seite übertragen und anpassen
Verschachtelung möglich — komplexe Datenstrukturen wie AggregateRating innerhalb von LocalBusiness sind einfach umzusetzen

Nachteile von JSON-LD

Inhalt und Markup können auseinanderlaufen (wenn z.B. der angezeigte Preis im HTML geändert wird, aber das JSON-LD vergessen wird zu aktualisieren)
Setzt JavaScript-Kenntnisse voraus (aber nur grundlegende)

Format 2: Microdata — tief im HTML verwurzelt

Microdata ist ein HTML5-Standard, der Schema.org-Informationen direkt als HTML-Attribute in den sichtbaren Seiteninhalt einbettet. Die strukturierten Daten "kleben" am Content — jedes Datenelement ist mit dem entsprechenden sichtbaren Element im HTML verbunden.

Wie sieht Microdata aus?

<div itemscope itemtype="https://schema.org/LocalBusiness">
  <span itemprop="name">Friseursalon Müller</span>
  <div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
    <span itemprop="streetAddress">Hauptstraße 5</span>,
    <span itemprop="addressLocality">Berlin</span>
    <span itemprop="postalCode">10117</span>
  </div>
  <span itemprop="telephone">+49 30 12345678</span>
  <div itemprop="aggregateRating" itemscope itemtype="https://schema.org/AggregateRating">
    Bewertung: <span itemprop="ratingValue">4.8</span>/5
    (<span itemprop="reviewCount">127</span> Bewertungen)
  </div>
</div>

Man sieht sofort: Microdata verändert die HTML-Struktur erheblich. Jedes Element bekommt itemscope, itemtype und itemprop Attribute. Das macht das HTML deutlich länger und schwerer lesbar.

Vorteile von Microdata

Daten und Inhalt sind synchron — wenn du den sichtbaren Preis änderst, ändert sich automatisch der strukturierte Datenwert
Kein separates Datenblock-Management — es gibt kein zweites Dokument, das aktuell gehalten werden muss
Breit unterstützt — alle großen Suchmaschinen verstehen Microdata

Nachteile von Microdata

HTML wird massiv aufgebläht — ein einfaches Produktlisting kann dreimal so groß werden
Schwer nachträglich einzubauen — das bestehende HTML muss umstrukturiert werden
Schlechte Lesbarkeit — Entwickler und Content-Autoren verlieren schnell den Überblick
Wartungsintensiv — bei Template-Änderungen müssen alle Attribute geprüft werden
Kompliziert für verschachtelte Typen — mehrfach verschachtelte itemscope-Blöcke werden unübersichtlich

Format 3: RDFa — der Vollständige, aber Komplexe

RDFa (Resource Description Framework in Attributes) kommt aus dem Semantic-Web-Umfeld und ist das älteste der drei Formate. Wie Microdata bettet es strukturierte Daten als HTML-Attribute ein, nutzt aber eine abweichende Syntax, die auf dem RDF-Standard basiert.

Wie sieht RDFa aus?

<div vocab="https://schema.org/" typeof="LocalBusiness">
  <span property="name">Friseursalon Müller</span>
  <div property="address" typeof="PostalAddress">
    <span property="streetAddress">Hauptstraße 5</span>,
    <span property="addressLocality">Berlin</span>
    <span property="postalCode">10117</span>
  </div>
  <span property="telephone">+49 30 12345678</span>
</div>

RDFa verwendet statt itemscope/itemtype/itemprop die Attribute vocab, typeof und property. Die Grundidee ist dieselbe wie bei Microdata, aber die Syntax unterscheidet sich. RDFa Lite (die vereinfachte Version) ist etwas leichter einzusetzen als vollständiges RDFa.

Vorteile von RDFa

Mächtiger als Microdata — unterstützt mehr Semantic-Web-Konzepte und externe Ontologien
Gut für komplexe, verknüpfte Daten — etwa akademische oder wissenschaftliche Websites
Weit verbreitet im öffentlichen Sektor — viele Regierungs- und Institutionswebsites nutzen RDFa

Nachteile von RDFa

Steilste Lernkurve der drei Formate — RDF-Konzepte sind für Webentwickler ungewohnt
Dieselben HTML-Nachteile wie Microdata — aufgeblähtes, schwer lesbares HTML
Für normales SEO überdimensioniert — die Zusatzfunktionen von RDFa braucht die Mehrheit der Websites nie

Direkter Vergleich: JSON-LD vs. Microdata vs. RDFa

Kriterium	JSON-LD	Microdata	RDFa
Google-Empfehlung	Empfohlen	Unterstützt	Unterstützt
HTML-Trennung	Vollständig getrennt	Direkt eingebettet	Direkt eingebettet
Lesbarkeit des HTMLs	Hoch	Niedrig	Niedrig
Implementierungsaufwand	Gering	Hoch	Sehr hoch
Wartungsaufwand	Gering	Mittel	Mittel
CMS-Integration	Einfach	Komplex	Komplex
Dynamisch generierbar	Ja	Ja, aber aufwändig	Ja, aber aufwändig
Geeignet für Einsteiger	Ja	Bedingt	Nein
Rich Snippet Support	Vollständig	Vollständig	Vollständig

Welches Format verwendet Google selbst?

Google nutzt auf seinen eigenen Produktseiten, in der Google Search Console-Dokumentation und in den offiziellen Developer-Guides konsequent JSON-LD. In der Google-Dokumentation steht wörtlich: "Google empfiehlt die Verwendung von JSON-LD für strukturierte Daten."

Das bedeutet nicht, dass Microdata oder RDFa nicht funktionieren — alle drei Formate werden korrekt ausgelesen und verarbeitet. Aber wenn Googles eigene Ingenieure JSON-LD für die internen Beispiele wählen und es offiziell empfehlen, ist das ein klares Signal.

Ein praktischer Grund: JavaScript-gerenderte Inhalte. Google rendert JavaScript-Seiten mittlerweile zuverlässig, aber nicht sofort — es kann Stunden oder Tage dauern. JSON-LD im <head> wird beim ersten Crawl verarbeitet, noch bevor JavaScript ausgeführt wird. Das ist besonders für Single-Page-Applications (SPAs) relevant, bei denen Microdata und RDFa möglicherweise erst nach dem JavaScript-Rendering vorhanden sind.

Wann sollte ich trotzdem Microdata oder RDFa verwenden?

Es gibt Szenarien, in denen Microdata oder RDFa Sinn ergibt:

Microdata — sinnvoll wenn:

Du ein Legacy-System pflegst, das bereits vollständig mit Microdata ausgestattet ist (dann lohnt sich eine Migration erst bei größerer Überarbeitung)
Du ein CMS nutzt, das Microdata nativ generiert (z.B. ältere Drupal-Versionen)
Die Synchronität zwischen sichtbarem Preis/Bewertung und strukturierten Daten kritisch ist und du keinen automatischen Update-Mechanismus hast

RDFa — sinnvoll wenn:

Du eine institutionelle oder wissenschaftliche Website betreibst, die Teil eines größeren Linked-Data-Ökosystems ist
Du bereits mit dem Semantic-Web-Standard arbeitest und RDF-Kenntnisse vorhanden sind
Dein CMS (z.B. bestimmte Drupal-Versionen) RDFa als Standard ausgeben kann

Für 99 % der normalen Websites — vom Handwerksbetrieb bis zum großen Online-Shop — ist JSON-LD die richtige Wahl.

JSON-LD richtig einsetzen: Praktische Tipps

1. Platzierung im <head> ist optimal

Platziere den <script type="application/ld+json">-Block im <head> der Seite. Google kann ihn dort beim ersten Crawl lesen, bevor der Rest der Seite verarbeitet wird. Am Ende des <body> funktioniert es ebenfalls, aber <head> ist die Best Practice.

2. Mehrere JSON-LD-Blöcke sind erlaubt

Du kannst mehrere <script type="application/ld+json">-Blöcke auf einer Seite haben. Eine Produktseite kann z.B. einen Block für Product und einen zweiten für BreadcrumbList haben. Das ist vollständig valide und von Google unterstützt.

3. Inhalte müssen auf der Seite sichtbar sein

Google verarbeitet nur Structured-Data-Informationen, die auch im sichtbaren Seiteninhalt vorhanden sind. Wenn du in JSON-LD eine Bewertung von 4,9 Sternen angibst, muss diese Bewertung auch irgendwo auf der Seite für Nutzer sichtbar sein. Versteckte Informationen führen zur Ablehnung durch Google.

Wichtiger Hinweis: Structured Data darf nicht irreführend sein. Falsche Bewertungen, erfundene Rezensionen oder nicht vorhandene Produktverfügbarkeiten im Schema Markup verstoßen gegen Googles Richtlinien und können zu einer manuellen Abstrafung führen.

4. Validierung vor dem Publish

Bevor du Structured Data live schaltest, validiere es mit dem Rich Results Test von Google. Syntaxfehler in JSON (z.B. fehlende Kommas, nicht geschlossene Klammern) führen dazu, dass das gesamte Schema-Markup ignoriert wird. Unser JSON-LD Structured Data Validator hilft dir dabei, Fehler sofort zu finden.

5. Schema-Typen mit Bedacht wählen

Nicht jeder Schema-Typ führt zu Rich Snippets in Google. Google unterstützt nur eine begrenzte Anzahl von Typen für Enhanced Results. Die wichtigsten für deutsche Websites sind:

LocalBusiness — für lokale Unternehmen (Öffnungszeiten, Adresse, Bewertungen)
Article / NewsArticle / BlogPosting — für Redaktionsinhalte
Product — für E-Commerce-Produkte (Preis, Verfügbarkeit, Bewertungen)
FAQPage — für FAQ-Seiten (erscheinen direkt in den Suchergebnissen)
Recipe — für Rezepte
Event — für Veranstaltungen
BreadcrumbList — für Breadcrumb-Navigation

Unser FAQ Schema Generator und der LocalBusiness Schema-Markup-Generator helfen dir, korrekte JSON-LD-Blöcke für diese häufigen Typen zu erstellen — ohne Programmierkenntnisse.

Migration von Microdata/RDFa zu JSON-LD

Wenn deine Website bereits Microdata oder RDFa einsetzt und du zu JSON-LD wechseln möchtest, ist das einfacher als gedacht:

Inventarisierung: Liste alle Seiten auf, die aktuell Microdata oder RDFa enthalten
JSON-LD-Blöcke erstellen: Schreibe das Äquivalent als JSON-LD (alle Schema.org-Typen und -Eigenschaften sind identisch)
Parallelbetrieb: Du kannst übergangsweise beide Formate gleichzeitig betreiben — Google ignoriert Duplikate nicht, aber bestraft sie auch nicht
Schrittweise Migration: Entferne Microdata/RDFa-Attribute aus dem HTML, sobald das JSON-LD validiert ist
Google Search Console prüfen: Beobachte die "Verbesserungen"-Berichte in der GSC nach der Migration

Häufige JSON-LD-Fehler und wie du sie vermeidest

Fehler 1: Ungültiges JSON

JSON hat strikte Syntaxregeln. Ein fehlendes Komma oder eine nicht korrekt escapte Anführungszeichen im Inhalt reicht, um den gesamten Block unlesbar zu machen. Nutze immer einen JSON-Validator vor dem Deployment.

Fehler 2: Falsche Eigenschaftsnamen

Schema.org-Eigenschaften sind case-sensitive. streetAddress ist korrekt, StreetAddress oder street_address werden nicht erkannt. Immer die offizielle Schema.org-Dokumentation als Referenz nutzen.

Fehler 3: Nicht sichtbare Informationen auszeichnen

Wie bereits erwähnt: Was im JSON-LD steht, muss auf der Seite sichtbar sein. Kein unsichtbares Stuffing von Keywords oder Bewertungen.

Fehler 4: Zu viele Schema-Typen auf einer Seite

Während technisch mehrere Blöcke erlaubt sind, solltest du nicht versuchen, eine Landing Page mit 10 verschiedenen Schema-Typen auszustatten, wenn die Seite inhaltlich nur einen Typ abdeckt. Das wirkt manipulativ.

Fehler 5: JSON-LD nicht aktuell halten

Wenn der Produktpreis geändert wird, aber das JSON-LD nicht, indexiert Google einen falschen Preis. Stelle sicher, dass JSON-LD-Blocks bei Content-Änderungen automatisch oder manuell aktualisiert werden.

Checkliste: Structured Data korrekt implementieren

Format gewählt: JSON-LD (empfohlen)
Block im <head> der Seite platziert
JSON-Syntax validiert (keine Syntaxfehler)
Schema.org-Typ korrekt gewählt (LocalBusiness, Article, Product, …)
Alle Pflichtfelder des gewählten Typs ausgefüllt
Alle Informationen im Schema Markup sind auch sichtbar auf der Seite
Im Google Rich Results Test validiert
In der Google Search Console unter "Verbesserungen" geprüft
Update-Prozess definiert (wer aktualisiert das JSON-LD bei Content-Änderungen?)

Fazit: JSON-LD ist die klare Empfehlung

Die Entscheidung zwischen JSON-LD, Microdata und RDFa ist für die meisten Websites keine echte Debatte: JSON-LD gewinnt klar. Es ist einfacher zu implementieren, leichter zu warten, von Google empfohlen und unterstützt alle wichtigen Schema-Typen für Rich Snippets vollständig.

Microdata kann sinnvoll sein, wenn du mit einem Legacy-System arbeitest, das es bereits nutzt und eine Migration nicht rechtfertigt. RDFa ist für spezialisierte Anwendungsfälle im Semantic-Web-Bereich reserviert, für normale Unternehmenswebsites aber überdimensioniert.

Die gute Nachricht: Selbst wenn du heute noch keine Structured Data einsetzt, kannst du morgen damit anfangen. Ein einziger korrekt implementierter JSON-LD-Block für LocalBusiness oder FAQPage kann die Klickrate in den Suchergebnissen spürbar verbessern. Nutze unsere Schema-Markup-Generator-Tools, um in Minuten loszulegen — ohne eine Zeile Code schreiben zu müssen.

Im nächsten Artikel dieser Cluster-Serie gehen wir tiefer in die einzelnen Schema-Typen: Strukturierte Daten für SEO: Schema Markup einfach erklärt gibt dir den Überblick, welcher Typ für welche Art von Website am meisten bringt.