Zum Inhalt springen

Glossar Schema.org

Was ist Schema.org? Vokabular und JSON-LD erklärt

Definition

Schema.org ist das standardisierte Vokabular, das Google, Bing, Yahoo und Yandex gemeinsam pflegen, um Seiteninhalte über strukturierte Daten zu beschreiben. Es ist kein Code-Format, sondern ein gemeinsames Wörterbuch aus Typen und Eigenschaften, das anschließend über JSON-LD, Microdata oder RDFa in den HTML-Code eingebaut wird.

Eine genormte Metallkupplung am Ende eines Schlauchs — daneben der Titel Schema.org
Die Kupplung ist genormt, der Schlauch, den du bringst, nicht
Auf dieser Seite 5
  1. Vokabular vs. JSON-LD: zwei Dinge, die oft verwechselt werden
  2. Die wichtigsten Schema-Typen für ein Unternehmen
  3. Ist Schema.org ein Rankingfaktor?
  4. Best Practices
  5. Häufige Fehler
Kurz gefasst

Schema.org legt fest, WAS beschrieben wird, ein Produkt, ein Unternehmen, ein Rezept. JSON-LD legt fest, WIE das im Code eingebaut wird, und ist das Format, das Google seit 2015 empfiehlt. Das richtige Markup verbessert das Ranking nicht von selbst, ist aber die technische Voraussetzung dafür, dass Google Rich Results zeigen kann und dass generative KI-Systeme eine Seite zuverlässiger auswerten. Der häufigste Fehler ist, beide Begriffe als Synonyme zu behandeln: Ein syntaktisch perfektes JSON-LD, das einen nicht existierenden Schema.org-Typ nutzt, bringt trotzdem nichts.

Eine genormte Metallkupplung am Ende eines Schlauchs — daneben der Titel Schema.org
Die Kupplung ist genormt, der Schlauch, den du bringst, nicht

Vokabular vs. JSON-LD: zwei Dinge, die oft verwechselt werden

Zwei Konzepte werden häufig vermischt, obwohl sie unterschiedliche Probleme lösen. Schema.org ist das Vokabular: eine öffentliche Sammlung von Typen (Product, Article, Organization, Recipe) und Eigenschaften (name, price, author, datePublished), die Google, Bing, Yahoo und Yandex 2011 gegründet haben und seither gemeinsam pflegen. Das Projekt entstand genau deshalb: Vor 2011 warb jede Suchmaschine für ein eigenes Markup-System, mit verstreuten Mikroformaten und RDFa, und wer eine Website betrieb, musste dieselbe Angabe in mehreren Formaten duplizieren, um alle Suchmaschinen abzudecken. Dieses Vokabular legt fest, was auf einer Seite beschrieben werden kann und unter welchen Bezeichnungen, sagt aber nichts darüber aus, wie der Code geschrieben wird. JSON-LD, Microdata und RDFa sind die drei Formate, mit denen dieses Vokabular in HTML übersetzt wird. JSON-LD (JavaScript Object Notation for Linked Data) ist heute das Format, das Google für die meisten Fälle empfiehlt: Es steht in einem eigenen <script type="application/ld+json">-Block, ohne den sichtbaren HTML-Code der Seite zu berühren. Microdata dagegen verlangt Attribute (itemscope, itemprop) direkt an den bestehenden Tags, was die Pflege erschwert, sobald sich das Design ändert. Die praktische Folge: Zwei Seiten können exakt dasselbe Schema.org-Vokabular nutzen, denselben Typ Product und dieselben Eigenschaften, und sich nur im gewählten Einbauformat unterscheiden. Google verarbeitet alle drei Formate, priorisiert in der Search-Central-Dokumentation aber JSON-LD, weil es sich aus einem CMS leichter dynamisch generieren und ohne Risiko für das sichtbare Layout validieren lässt. Ein Beispiel zeigt den Unterschied. Der Typ Organization mit den Eigenschaften name, url und logo ist auf jeder Seite, die ihn nutzt, dasselbe Vokabular. Als JSON-LD sieht die Umsetzung so aus:
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Firmenname",
  "url": "https://beispiel.de",
  "logo": "https://beispiel.de/logo.png"
}
</script>
Dieselbe Information als Microdata verlangt, dieselben Attribute über mehrere sichtbare HTML-Tags zu verteilen, was in dynamischen Vorlagen mehr Syntaxfehler erzeugt als ein zentraler, vom übrigen Code getrennter JSON-LD-Block. Details zu den einzelnen Formaten stehen unter JSON-LD und Structured Data.

Die wichtigsten Schema-Typen für ein Unternehmen

Ein typisches Unternehmen, ein Onlineshop, eine Beratung, eine Kanzlei, muss nicht alle über 800 Typen von Schema.org einsetzen. Sechs davon decken, richtig angewendet, die meisten Fälle ab.

Organization identifiziert das Unternehmen als Entität: Name, Logo, Social-Media-Profile und Kontaktdaten. Google nutzt diesen Typ als Basis für das Knowledge Panel.

Product beschreibt Artikel im Verkauf: Preis, Verfügbarkeit, Bewertungen. Er ermöglicht Sterne und Preis direkt im Suchergebnis und ist der Typ, bei dem falsche oder veraltete Werte am schnellsten aus dem Rich Result fliegen.

FAQPage markiert sichtbare Fragen und Antworten auf der Seite. Google nutzt es, wenn überhaupt, für den ausklappbaren Inhalt unter dem Ergebnis, schränkt die Anzeige seit 2023 in den meisten Märkten aber vor allem auf Behörden- und Gesundheitsseiten ein.

Article gilt für redaktionelle Inhalte: Veröffentlichungsdatum, Autor, Titelbild. Relevant sowohl für Google Discover als auch dafür, dass generative KI-Systeme die Quelle korrekt zuordnen, wenn sie einen Absatz aus dem Artikel zitieren.

LocalBusiness erweitert Organization um Öffnungszeiten, Adresse und Einzugsgebiet. Dieser Typ verbindet die Website mit dem Google-Unternehmensprofil.

BreadcrumbList bildet den Navigationspfad ab (Start > Kategorie > Produkt) und erzeugt die sichtbaren Brotkrumen im Suchergebnis anstelle der vollständigen URL.

Diese Typen schließen sich nicht gegenseitig aus. Eine gut gebaute Produktseite kann Product, BreadcrumbList und Organization im selben JSON-LD-Block über die Eigenschaft @graph kombinieren, sodass Google in einem einzigen Aufruf alle relevanten Informationen dieser URL erhält, ohne den Kontext für jeden Typ einzeln zu wiederholen.

Ist Schema.org ein Rankingfaktor?

Nein. Google hat das in seiner Dokumentation mehrfach bestätigt: Strukturierte Daten verbessern die Position einer Seite nicht direkt. Sie schaffen die Voraussetzung für zusätzliche visuelle Funktionen, die Rich Results, die über mehr Platz in der SERP oder Zusatzinfos wie Sterne, Preis oder Zubereitungszeit die Klickrate steigern können.

Entscheidend ist das Wort Voraussetzung, nicht Garantie. Korrekte Syntax und die Richtlinien eines Typs einzuhalten zwingt Google nicht dazu, das entsprechende Rich Result auch anzuzeigen; die Entscheidung hängt von einem zusätzlichen Qualitätsprozess, der Autorität der Seite und der Verfügbarkeit dieser Funktion im jeweiligen Markt und Gerät ab. Es kommt vor, dass FAQPage- oder Product-Markup korrekt implementiert ist und trotzdem nie ein Rich Result erscheint, während eine ähnliche Seite es bekommt.

Die Search Console erlaubt es, das mit echten Daten zu prüfen: Der Bericht zu jedem Rich-Result-Typ, etwa "Produkt-Snippets" oder "Häufig gestellte Fragen", zeigt, wie viele Seiten gültiges Markup haben, verglichen mit der Zahl der Seiten, die die visuelle Funktion tatsächlich im Suchergebnis erhalten. Es kommt vor, dass hundert Prozent des Markups gültig sind und trotzdem nur ein Bruchteil dieser URLs das Rich Result zeigt, eben weil Eligibility keine garantierte Anzeige bedeutet.

Wo die Rolle von Schema.org spürbar wächst, ist bei GEO (Generative Engine Optimization). Generative KI-Systeme, ChatGPT, Perplexity, Googles AI Overviews, müssen konkrete Fakten (Preis, Autor, Datum, Standort) aus Webseiten extrahieren, um ihre Antworten zu bauen. Freier Text zwingt das Modell dazu, diese Daten aus dem Kontext zu erschließen; ein JSON-LD-Block liefert sie bereits eindeutig etikettiert. Es gibt keinen öffentlichen Beleg dafür, dass diese Systeme markierten Inhalt gegenüber unmarkiertem Text bevorzugen, aber die Fehlerquote beim Zitieren von Zahlen oder Produktattributen sinkt. Details zur Optimierung für diese Systeme stehen unter GEO, die konkreten Funktionen bei klassischen Suchmaschinen unter Rich Results und Featured Snippet.

Best Practices

  • JSON-LD als Standardformat nutzen: Google priorisiert es, und es lässt sich aus einem CMS am einfachsten pflegen, ohne das Template für die sichtbare Seite anzufassen.
  • Jede Seite mit dem Rich-Results-Test von Google prüfen, nicht nur mit einem allgemeinen Syntax-Validator, der reine Vokabular-Fehler oft übersieht.
  • Nur markieren, was für Nutzer tatsächlich sichtbar ist. Weicht der Preis im JSON-LD vom sichtbaren Preis ab, kann Google das Markup ignorieren oder abwerten.
  • Schema aktualisieren, sobald sich der Inhalt ändert: Ein ausverkauftes Produkt mit "InStock" im JSON-LD schafft Misstrauen und kann zur Entfernung des Rich Results führen.
  • Den spezifischsten verfügbaren Typ wählen: Recipe statt CreativeWork für ein Rezept, LocalBusiness statt Organization für ein Geschäft mit physischem Standort.
  • Mehrere Typen kombinieren, wenn es sinnvoll ist: Eine Produktseite kann Product und BreadcrumbList gleichzeitig tragen, ohne Konflikt zwischen beiden.
  • Das Markup versionieren wie den restlichen Code: Ein JSON-LD-Block, der beim nächsten Relaunch vergessen wird, zeigt oft monatelang veraltete Preise oder Autoren an.

Häufige Fehler

  • Daten markieren, die im sichtbaren Inhalt fehlen: Bewertungen, Preise oder Verfügbarkeit, die nur im JSON-LD existieren. Google wertet das als Structured-Data-Spam und kann eine manuelle Maßnahme verhängen, die sich nur schwer wieder rückgängig machen lässt.
  • JSON-LD aus einer Vorlage oder von einem Wettbewerber kopieren, ohne die Werte anzupassen: Markennamen oder URLs, die nicht zur aktuellen Seite passen.
  • Pflichtfelder leer lassen oder mit Platzhaltern füllen ("Lorem ipsum", Preis 0), was der Rich-Results-Test nicht immer als kritischen Fehler markiert.
  • Denselben Typ zweimal auf derselben Seite mit unterschiedlichen Werten einsetzen, was Uneindeutigkeit erzeugt und Google zwingt, selbst zu entscheiden, welcher Wert gilt.
  • FAQPage oder HowTo einbauen und das entsprechende Rich Result erwarten, ohne vorher zu prüfen, ob Google diese Funktion im jeweiligen Markt und in der Kategorie der Seite noch anzeigt.
Manuel Riveiro Rodriguez CEO & Digital Strategist

Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.

Audit anfragen

Häufige Fragen

Muss ich JSON-LD nutzen, oder geht auch Microdata?

Nicht zwingend. Google verarbeitet alle drei Formate, JSON-LD, Microdata und RDFa, solange die Syntax korrekt ist. JSON-LD wird empfohlen, weil es das Markup vom sichtbaren HTML trennt und Fehler beim Aktualisieren der Vorlage reduziert. Eine Seite mit sauber implementiertem Microdata verliert dadurch aber keine Eligibility für Rich Results. In der Praxis wechseln die meisten Teams trotzdem zu JSON-LD, sobald sie einmal erlebt haben, wie viele Microdata-Fehler ein einziges Redesign verursachen kann.

Garantiert Schema.org, dass ein Rich Result erscheint?

Nein. Korrektes Markup macht die Seite eligible, entscheidet aber nicht, dass Google sie auswählt. Die endgültige Entscheidung hängt von zusätzlichen Qualitätsfaktoren und der Verfügbarkeit dieser Funktion im Markt des Nutzers ab, etwas, das Google in seiner offiziellen Dokumentation weder steuert noch garantiert.

Was ist der Unterschied zwischen Schema.org und Structured Data?

Structured Data ist der allgemeine Begriff für jede Information, die in einem maschinenlesbaren Format organisiert ist. Schema.org ist das konkrete Vokabular, die Sammlung von Typen und Eigenschaften, die am häufigsten genutzt wird, um solche strukturierten Daten im Web zu erzeugen.

Wie prüfe ich, ob das Markup meiner Website korrekt ist?

Mit dem Rich-Results-Test von Google (search.google.com/test/rich-results), der die Syntax validiert und zeigt, welche Funktionen für diese URL eligible sind. Der Bericht zu strukturierten Daten in der Search Console ergänzt diesen Test mit echten Crawling-Daten.

Nützt Schema.org auch generativer KI, nicht nur Google?

Ja. Als offenes Vokabular kann jedes System, das das Web crawlt, einschließlich der Crawler von ChatGPT oder Perplexity, denselben JSON-LD-Block lesen. Es gibt keine öffentliche Bestätigung, dass diese Systeme markierten Text gegenüber Fließtext bevorzugen, aber er erleichtert das eindeutige Extrahieren konkreter Daten.

Wirkt sich Schema.org-Markup auf Google Discover oder die AI Overviews aus?

Indirekt. Article und seine Eigenschaften (Autor, Datum, Bild) helfen Google, redaktionellen Inhalt für Discover besser einzuordnen, und dieselben sauber etikettierten Daten erleichtern es den AI Overviews, die Quelle korrekt zu zitieren. Das Markup allein garantiert in keinem der beiden Fälle das Erscheinen.

Warum heißt es, Schema.org gehöre Google, Bing, Yahoo und Yandex, und nicht nur Google?

Weil es so gegründet wurde: 2011 einigten sich die vier Suchmaschinen auf ein gemeinsames Vokabular, statt jede ihr eigenes zu pflegen. In der Praxis veröffentlicht Google die meiste Dokumentation und die meisten Testwerkzeuge dazu, weshalb das Projekt fast immer nur mit Google in Verbindung gebracht wird, obwohl die Pflege des Vokabulars weiterhin gemeinsam über die gemeinnützige Organisation läuft, die es verwaltet.