2026-01-14 · Redaktion Baduno · 6 blog.readMin · Blog & Wissen
Strukturierte Daten: Schema.org verständlich erklärt
Maschinenlesbare Zusatzinfos machen aus Suchtreffern reiche Ergebnisse mit Bewertungen, FAQs und Firmendaten. So funktioniert es.
Was strukturierte Daten sind
Unsichtbare JSON-Blöcke im Quelltext beschreiben, was auf der Seite steht: Das ist ein Unternehmen mit dieser Adresse, das ein Artikel mit diesem Datum, das eine FAQ mit diesen Fragen. Suchmaschinen müssen nicht raten – sie lesen.

Was es bringt
Berechtigung für erweiterte Darstellungen (FAQ-Auszüge, Breadcrumbs, Organisations-Panel), besseres Verständnis der Zusammenhänge und sauberere Wissensgraph-Einträge. Kein Ranking-Turbo – aber mehr Fläche und Vertrauen im Suchergebnis.
Die wichtigsten Typen für Unternehmen
Organization mit Registerdaten, WebSite, Service oder Product mit Offer, Article für Fachbeiträge, FAQPage und BreadcrumbList. Mehrsprachig gilt: Jede Sprachfassung trägt ihre eigene, übersetzte Auszeichnung.
Validieren nicht vergessen
Der Rich-Results-Test zeigt, was Google liest, der Schema-Validator prüft die Syntax. Fehlerhafte Auszeichnung ist schlimmer als keine – sie kostet Vertrauen und im Ernstfall die erweiterte Darstellung.
Strukturierte Daten und hreflang: Perfektes Zusammenspiel für mehrsprachige Seiten
Eine häufige Fehlerquelle bei mehrsprachigen Websites ist die inkonsistente Verwendung von strukturierten Daten und hreflang-Tags. Während hreflang den Suchmaschinen die Sprach- und Regionsalternativen einer Seite signalisiert, geben strukturierte Daten den Inhaltstyp preis. Beide sind voneinander unabhängig, aber ergänzen sich: Eine deutsche Produktseite sollte sowohl ein hreflang-Tag auf die englische Variante verweisen als auch im strukturierten Datenblock die gleiche Produkt-ID mit unterschiedlichen Angeboten und Sprachen auszeichnen. Wichtig: Jede Sprachfassung erhält ihren eigenen JSON-LD-Block mit passenden Werten – sonst entstehen Widersprüche. Der Rich-Results-Test von Google zeigt oft Fehler, wenn etwa die Organisation in der deutschen Version eine englische Adresse enthält. Prüfen Sie daher nach jedem Sprach-Rollout stets beide Auszeichnungen parallel.
Wartung und Aktualisierung: Wer pflegt die Daten?
Strukturierte Daten sind kein einmaliges Projekt. Ändern sich Preise, Öffnungszeiten oder Produktdetails, müssen die JSON-LD-Blöcke aktualisiert werden. Idealerweise übernimmt das Content-Management-System die dynamische Befüllung. Fehlt diese Automatisierung, ist ein klarer Verantwortlicher im Team nötig – etwa der Redakteur für Artikel- und FAQ-Daten, der Entwickler für organisatorische Daten. Vermeiden Sie Datensilos: Eine veraltete Telefonnummer im Organization-Block schadet dem Vertrauen. Planen Sie vierteljährliche Reviews aller strukturierten Daten, mindestens aber vor jedem großen Relaunch. Hilfreich ist ein zentrales Dashboard, das alle ausgezeichneten Seiten und deren Validierungsstatus anzeigt.
KI-gestützte Erstellung und Prüfung strukturierter Daten
Moderne KI-Tools können aus unstrukturiertem Text automatisch JSON-LD generieren – etwa für FAQ-Seiten oder Artikel. Das beschleunigt die Arbeit, birgt aber Risiken: KI übersieht oft kontextuelle Nuancen (z. B. falscher Preis oder veraltetes Datum). Daher ist die muttersprachliche Prüfung durch einen Redakteur unverzichtbar. Nutzen Sie KI für die Rohfassung, lassen Sie dann einen Menschen die Werte validieren. Auch bei mehrsprachigen Seiten hilft KI bei Übersetzungen der strukturierten Daten, aber hreflang-Tags und sprachspezifische IDs müssen manuell gesetzt werden. Ein bewährtes Vorgehen: KI erstellt den englischen Standardblock, ein lokaler Redakteur korrigiert und ergänzt die landesspezifischen Felder.
Maschinenlesbare Zusatzinfos machen aus Suchtreffern reiche Ergebnisse mit Bewertungen, FAQs und Firmendaten. So funktioniert es.
Dynamische Inhalte auszeichnen: FAQs, Rezensionen und Produkte
Besonders häufig treten Fehler bei dynamischen Inhalten auf. FAQ-Seiten sollten je Frage ein eigener JSON-LD-Eintrag sein – nicht die gesamte Liste als ein einziges Question-Objekt. Bei Rezensionen muss die Bewertungsskala korrekt angegeben sein (z. B. bestRating und worstRating). Produktseiten mit Varianten erfordern AggregateOffer-Blöcke mit allen Preis- und Verfügbarkeitsinformationen. Nutzen Sie Templates im CMS, die automatisch die korrekten Typen generieren. Testen Sie jede dynamische Seite einzeln im Rich-Results-Test, da Fehler erst bei konkreten Werten sichtbar werden. Ein häufiger Fehler: die Verwendung von 'Review' statt 'AggregateRating' für Durchschnittsbewertungen.
Kombination mehrerer Schema.org-Typen auf einer Seite
Auf einer einzelnen Seite können Sie mehrere Schema.org-Typen parallel auszeichnen, sofern diese unterschiedliche Aspekte des Inhalts beschreiben. Eine Produktseite könnte gleichzeitig einen Product-Block (mit Preis, Verfügbarkeit), einen Organization-Block (für den Hersteller) und einen Review-Block (für Bewertungen) enthalten. Wichtig ist, dass jeder Typ in einem eigenen JSON-LD-Skript steht oder durch @id konsistent verknüpft wird. Beispiel: Der Product-Block verweist mit "brand": {"@id": "#organisation"} auf den Organization-Block. Vermeiden Sie widersprüchliche Angaben – etwa unterschiedliche Adressen im Organization- und LocalBusiness-Block. Jeder Typ muss inhaltlich korrekt und sprachspezifisch ausgezeichnet sein: Eine französische Seite erhält französische Werte in allen Blöcken. Nutzen Sie das CMS, um Typen modular zu verwalten, sodass Sie nicht jeden Block manuell anpassen müssen. Prüfen Sie im Rich-Results-Test, ob alle Blöcke akzeptiert werden – manche Tests zeigen nur den ersten Block an. Eine saubere Kombination mehrerer Typen erhöht die Chancen auf reiche Ergebnisse wie Karussell, Produkt-Boxen oder Organisations-Panel.
Arbeiten mit @id und Referenzen für verbundene Daten
Schema.org erlaubt es, Objekte über @id zu referenzieren und so redundante Daten zu vermeiden. Statt auf jeder Seite die vollständige Organisation zu wiederholen, definieren Sie einen zentralen Organization-Block mit einer eindeutigen @id (z. B. "https://beispiel.de/#firma") und verweisen in anderen Blöcken darauf via "@id": "https://beispiel.de/#firma". Dies ist besonders bei mehrsprachigen Websites hilfreich: Die Organisation bleibt gleich, nur die sprachspezifischen Felder wie „name“ oder „description“ weichen ab. Achten Sie darauf, dass die @id über alle Sprachversionen hinweg konsistent ist – also dieselbe URI für Deutsch, Englisch usw. Referenzen können auch für Artikel-Autoren, Produkt-Marken oder Rezensions-Items genutzt werden. Validieren Sie mit dem Schema-Validator, dass alle @id-Verweise auflösbar sind. Ein Fehler: Wenn die referenzierte @id nicht im selben Seitenquelltext oder auf einer anderen Seite definiert ist, bricht die Validierung. Hinterlegen Sie daher zentrale Entitäten entweder in einer globalen Datei (z. B. organisation.json) und binden Sie diese per JavaScript ein, oder nutzen Sie das CMS zur dynamischen Einbindung. Eine saubere @id-Struktur erleichtert Suchmaschinen das Verknüpfen von Informationen und verbessert die Konsistenz im Knowledge Graph.
BreadcrumbList korrekt auszeichnen: Tipps und Fallstricke
Die Auszeichnung von BreadcrumbList mag simpel erscheinen, doch in der Praxis zeigen sich häufig Fehler, die den Rich-Snippet-Erfolg gefährden. Eine korrekte Implementierung beginnt mit dem Verständnis der Hierarchie: Jeder Eintrag in der Liste benötigt ein ItemListElement-Objekt, das wiederum ein ListItem-Objekt enthält. Entscheidend ist die Position-Eigenschaft: Sie nummeriert die Elemente aufsteigend, beginnend mit 1 für die Startseite. Vermeiden Sie es, die Startseite auszulassen – selbst wenn sie nicht im sichtbaren Breadcrumb erscheint, sollte sie in den strukturierten Daten enthalten sein. Ein häufiger Fehler ist die Verwendung absoluter URLs ohne Berücksichtigung der Sprachversion: Stellen Sie sicher, dass die URL im Breadcrumb auf die korrekte Sprachvariante verweist, also z. B. auf /de/produkte statt /en/products. Auch die Benennung der Elemente muss sprachspezifisch erfolgen – 'Startseite' im Deutschen, 'Home' im Englischen. Nutzen Sie das name-Feld für den angezeigten Text und vermeiden Sie Kürzel oder Abkürzungen, die Suchmaschinen missverstehen könnten. Prüfen Sie nach der Implementierung jeden Pfad mit dem Rich-Results-Test, da insbesondere bei dynamisch generierten Breadcrumbs leicht Positionen vertauscht oder doppelte Einträge erzeugt werden. Beachten Sie zudem, dass Google maximal zehn Elemente anzeigt – eine kürzere, präzise Navigation ist daher einer überlangen vorzuziehen.
Verschachtelte Objekte und Referenzen: @id und @context
Komplexe strukturierte Daten nutzen oft die Verknüpfung mehrerer Typen über @id-Referenzen. Ein typisches Beispiel ist eine Product-Seite, die sowohl einen Offer als auch eine Review enthält. Statt alle Daten in einen monolithischen Block zu packen, ist es sauberer, separate Blöcke mit eindeutigen @id-Werten zu definieren und diese dann zu referenzieren. Der @id-Wert muss innerhalb der Seite und der gesamten Domain eindeutig sein – idealerweise verwenden Sie die absolute URL des Objekts mit einem Fragment wie #product-1. Vermeiden Sie generische IDs wie #produkt, da sie bei mehreren Seiten zu Konflikten führen. Ein weiterer wichtiger Aspekt ist der @context: Standardmäßig wird das Schema.org-Vokabular genutzt, aber für proprietäre Erweiterungen kann ein eigener Kontext angegeben werden. Achten Sie darauf, dass geprüfte Erweiterungen wie health-lifesci oder bib nicht versehentlich in kommerziellen Seiten landen. Bei mehrsprachigen Seiten müssen @id-Referenzen sprachspezifisch sein: Die deutsche Produktseite referenziert die deutsche Offer-ID, nicht die englische. Eine nützliche Technik ist die Verwendung von @reverse für Inverse Beziehungen, etwa wenn ein Product auf eine Organisation verweist, aber die Organisation keine direkte Liste aller Produkte führt. Testen Sie solche Verkettungen im Schema-Validator, da bereits ein fehlender Doppelpunkt zu einem Validierungsfehler führt. Planen Sie ausreichend Zeit für die Fehlersuche bei referenzierten Objekten ein – sie sind eine häufige Fehlerquelle in umfangreichen Implementierungen.
blog.faqT
Kann ich strukturierte Daten auch nachträglich auf alten Seiten einbauen?
Ja, strukturierte Daten können jederzeit ergänzt werden. Achten Sie darauf, dass alle Angaben aktuell sind. Nutzen Sie den Rich-Results-Test von Google, um die korrekte Umsetzung zu prüfen. Bei vielen Seiten empfiehlt sich ein schrittweises Vorgehen je Inhaltstyp.
Wie oft sollten strukturierte Daten aktualisiert werden?
Immer dann, wenn sich die zugrundeliegenden Informationen ändern (Preise, Öffnungszeiten, Produktdetails). Planen Sie mindestens eine vierteljährliche Gesamtprüfung ein. Dynamische Systeme können Daten automatisch befüllen – das reduziert Aktualisierungsaufwand und Fehlerquellen.