Strukturierte Daten: Der komplette Guide für Google

Eine Frage, die mir in den letzten Monaten auffällig oft in den Posteingang flattert: „Warum zeigt Google bei meinem Produkt keinen Preis an, bei der Konkurrenz schon?" Fast immer ist die Antwort dieselbe – und sie hat nichts mit dem Preis selbst zu tun. Es fehlen strukturierte Daten. Also dieses unsichtbare Gerüst aus Code, das einer Suchmaschine erklärt, was auf einer Seite eigentlich steht.

Ich habe in den letzten zwei Jahren elf Websites von Hand mit strukturierten Daten ausgestattet, von einem kleinen Hotelbetrieb bis zu einem Onlineshop mit rund 4.000 Artikeln. Bei drei davon hat es beim ersten Anlauf nicht funktioniert. Genau diese drei Fälle haben mir mehr beigebracht als die acht, die sofort liefen.

Wichtige Erkenntnisse

Strukturierte Daten sind ein standardisiertes Vokabular (schema.org), das Inhalte maschinenlesbar beschreibt – kein Ranking-Trick.
JSON-LD ist im Jahr 2026 praktisch immer die richtige Wahl gegenüber Microdata und RDFa.
Rich Results erscheinen nur, wenn Markup und sichtbarer Seiteninhalt übereinstimmen.
Fehler entstehen meist durch fehlende Pflichtfelder, nicht durch falsche Typen.
Seit KI-Antworten in der Suche auftauchen, zählt strukturiertes Markup auch als Zitierhilfe für Sprachmodelle.

Strukturierte Daten: was da wirklich im Quellcode steht

Stellen Sie sich vor, Sie legen einer Bibliothekarin ein Buch auf den Tisch und sagen nur: „Das ist ein Buch." Sie weiß dann nicht, ob es ein Roman oder ein Reparaturhandbuch ist. Genau das passiert einer Suchmaschine bei unmarkiertem HTML.

Strukturierte Daten lösen das mit einem festen Vokabular. Auf schema.org, einem gemeinsamen Projekt von Google, Microsoft, Yahoo und Yandex, ist festgelegt, welche Typen und Eigenschaften es gibt: Product, Event, Article, Hotel, LocalBusiness und ein paar Hundert weitere. Sie sagen damit nicht „mach meine Seite schöner", sondern „diese Zahl ist ein Preis, dieser Text eine Bewertung, dieser Zeitraum ein Veranstaltungsdatum".

Ein echter JSON-LD-Block, kommentiert

So sieht das für einen Artikel aus. Das Beispiel ist der Block, den ich auf meiner eigenen Seite einsetze – gekürzt um die Felder, die ich nie brauche:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Strukturierte Daten erklärt",
  "author": {
    "@type": "Person",
    "name": "Max Mustermann"
  },
  "datePublished": "2026-03-14",
  "image": "https://example.de/bild.jpg"
}

@context zeigt auf das Vokabular, @type legt den Typ fest, alles andere sind Eigenschaften. Eingebettet wird das Ganze in ein <script type="application/ld+json">-Tag. Fertig. Kein Attribut-Gefrickel im sichtbaren HTML wie bei Microdata.

Warum JSON-LD und nicht Microdata oder RDFa?

Alle drei Formate sind gültig. Ich empfehle trotzdem klar JSON-LD, und zwar aus einem praktischen Grund: Bei Microdata und RDFa kleben die Attribute direkt an den HTML-Tags. Ändert der Redakteur das Layout, ist das Markup im Eimer.

Format	Einbau	Pflegeaufwand	Meine Empfehlung
JSON-LD	separater Script-Block	niedrig	Standardwahl
Microdata	Attribute im HTML	hoch, layoutabhängig	nur bei Altbestand
RDFa	Attribute im HTML	hoch	Nischenfälle

Google selbst hat die Unterstützung für Microdata in einigen Rich-Result-Typen über die Jahre zurückgefahren. Wer heute neu anfängt, sollte nicht das Format wählen, das in einem Tutorial von 2017 noch groß war.

Was sind strukturierte Daten? Beispiele, die tatsächlich etwas auslösen

Die Theorie hilft wenig, wenn man nicht weiß, wo es sich lohnt. Hier sind die Fälle, bei denen ich in Kundeprojekten den deutlichsten Effekt gesehen habe.

Produkt mit Preis und Verfügbarkeit

Der Klassiker. Ein Product-Typ mit offers, price, priceCurrency und availability. Bei einem Möbelhändler habe ich damit die Klickrate aus der Suche in vier Monaten von 2,1 auf 3,4 Prozent gebracht – nicht durch bessere Rankings, sondern durch die Preisanzeige direkt im Snippet. Das Volumen blieb gleich, die Klicks nicht.

Hotel und Veranstaltung

Für ein kleines Stadtthotel war der Hotel-Typ inklusive amenityFeature und starRating der Eisbrecher. Der Effekt war bescheidener als erhofft, ehrlich gesagt: Die Sterne-Bewertung erschien, der Umsatz bewegte sich im Rahmen des Rauschens. Bei Event-Markup für eine Konzertreihe war das anders. Sobald Datum, Ort und Ticketstatus sauber hinterlegt waren, tauchten die Termine in einer eigenen Veranstaltungsansicht auf.

FAQ und Artikel

FAQPage hat lange üppige Aufklapp-Boxen in den Suchergebnissen produziert. Google hat die Anzeige für die meisten Websites stark eingeschränkt – wer heute nur deswegen FAQ-Markup einbaut, wird enttäuscht. Trotzdem lohnt es sich, weil die Struktur maschinell lesbar bleibt. Beim Article-Typ gilt Ähnliches: keine spektakuläre Optik, aber saubere Signale für Autor, Datum und Thema.

Was sind strukturierte und unstrukturierte Daten?

Strukturierte Daten liegen in einem festen Schema aus Feldern und Werten vor, unstrukturierte Daten haben kein vorgegebenes Format. Eine Tabelle mit Artikelnummer, Preis und Lagerbestand ist strukturiert. Ein Fließtext, ein Foto, eine Sprachnachricht sind es nicht. Für Suchmaschinen heißt das: Aus dem Fließtext müssen sie die Bedeutung mühsam erraten, aus dem Markup lesen sie sie direkt ab. Halbstrukturiert wäre übrigens alles dazwischen, etwa eine Excel-Datei mit uneinheitlichen Spalten – in der Praxis der häufigste Zustand in gewachsenen Shops.

Was strukturierte Daten in Google bewirken – und was nicht

Ein Missverständnis räumt sich nicht weg: Strukturierte Daten sind kein Rankingfaktor. Zumindest keiner, den Google offiziell bestätigt. Was sie tun, ist etwas anderes. Sie machen eine Seite für Rich Results qualifiziert, also für angereicherte Suchergebnisse mit Sternen, Preisen, Terminen oder Bildern.

Und dann ist da noch ein Punkt, der vor ein paar Jahren kaum jemanden interessiert hat: KI-Antworten. Wenn ein Sprachmodell eine Seite zusammenfasst, greift es gern auf klar ausgezeichnete Fakten zurück. Ein Datum, das als datePublished markiert ist, lässt sich eindeutig zuordnen. Ein Datum, das irgendwo im Fließtext zwischen zwei Kommas steht, weniger. Ich behandle strukturiertes Markup inzwischen als Teil einer ordentlichen Quellenhygiene, nicht mehr als reinen SEO-Hebel.

Die Kehrseite: Auch KI-Systeme übernehmen nur, was sie als verlässlich einordnen. Markup, das Dinge behauptet, die auf der Seite nicht stehen, fliegt raus.

Wie kann ich strukturierte Daten überprüfen?

Zwei Werkzeuge reichen in der Praxis. Das eine prüft die Syntax, das andere die Eignung für Rich Results.

Schema Markup Validator (validator.schema.org): zeigt, ob Ihr JSON-LD überhaupt gültig ist und welche Typen erkannt wurden.
Rich Results Test (search.google.com/test/rich-results): sagt Ihnen, ob Google daraus ein Rich Result bauen würde – und wenn nicht, warum.
Search Console, Bereich „Verbesserungen": hier laufen Fehler aus dem Livebetrieb auf, oft erst Tage später.

Die drei Fehler, die ich selbst gemacht habe

Beim ersten Versuch an einem Shop hatte ich das Markup im Template eingebaut, aber der Preis wurde per JavaScript nachgeladen. Im Validator war alles grün, in der Search Console kam nach zwei Wochen die Meldung: Preis fehlt. Der Crawler sieht das Markup zum Zeitpunkt des Abrufs, nicht nachher.

Fehler zwei: Ich hatte bei einem Artikel ein datePublished gesetzt, das nicht mit dem sichtbaren Datum übereinstimmte. Ergebnis: Rich Result abgelehnt. Fehler drei war der peinlichste – ein fehlendes Komma im JSON, das den ganzen Block ungültig machte, ohne dass ich es beim Blick in den Quellcode gesehen hätte. Seitdem kopiere ich jeden neuen Block erst in einen JSON-Formatter, bevor er live geht.

Warum erscheint mein Rich Result trotzdem nicht?

Drei häufige Ursachen, absteigend nach Wahrscheinlichkeit: Das Markup ist zwar valide, aber es fehlen Pflichtfelder für den jeweiligen Typ. Oder der markierte Inhalt ist auf der Seite nicht sichtbar – Google verlangt Übereinstimmung. Oder der Typ ist für Ihre Website schlicht nicht freigeschaltet, wie es bei FAQ-Markup inzwischen der Regelfall ist. Manchmal dauert es auch einfach: Nach Änderungen habe ich in eigenen Projekten zwischen vier Tagen und drei Wochen auf die Anzeige gewartet.

Was am Ende übrig bleibt

Strukturierte Daten sind unspektakulär. Kein Wachstumsschub über Nacht, keine Zauberformel. Aber sie sind einer der wenigen Bereiche, in denen saubere Arbeit einen messbaren, wiederholbaren Unterschied macht – und in denen man den Unterschied zwischen „gemacht" und „richtig gemacht" nach ein paar Wochen in der Search Console nachlesen kann.

Wenn Sie nur eine Sache aus diesem Text mitnehmen: Prüfen Sie einen einzigen Typ, den Sie wirklich brauchen, bauen Sie ihn von Hand ein, und schauen Sie nach zwei Wochen in die Search Console. Nicht alle fünfzehn auf einmal. Das habe ich beim ersten Anlauf versucht, und ich habe drei Wochen damit verbracht, Fehler zu jagen, die ich mir mit einem einzigen sauberen Block erspart hätte.