SEO-Snippet
Was sind strukturierte Daten?
Strukturierte Daten sind Zusatzinformationen im Quellcode einer Webseite. Sie beschreiben den Inhalt einer Seite in einer standardisierten Form, damit Suchmaschinen und andere Systeme ihn besser einordnen können. Sie bilden eine semantische Übersetzungsschicht zwischen dem, was Menschen lesen, und dem, was Maschinen verstehen müssen.
Ein Mensch erkennt sofort: Das hier ist ein Blogartikel. Dort steht der Titel. Hier der Autor. Dieses Datum ist das Veröffentlichungsdatum. Diese Seite gehört zu einer bestimmten Kategorie. Eine Suchmaschine kann solche Zusammenhänge zwar zunehmend gut ableiten, aber strukturierte Daten machen sie explizit. Google beschreibt sie entsprechend als standardisiertes Format, mit dem Informationen zu einer Seite angegeben und Seiteninhalte klassifiziert werden können. (1)
Warum strukturierte Daten wichtig sind
Das Web besteht aus HTML. HTML beschreibt Struktur: Überschriften, Absätze, Links, Listen, Bilder. Das ist wertvoll, aber nicht immer eindeutig genug. Eine <h1> identifiziert eine Hauptüberschrift, mehr nicht. Wessen Artikel das ist, wer ihn geschrieben hat, wann er erschienen ist und zu welcher Website er gehört, muss aus dem übrigen Markup erschlossen werden.
Strukturierte Daten ergänzen diese Ebene. Sie geben Inhaltselementen eine Bedeutung, die über ihre visuelle Darstellung hinausgeht. Sie machen Inhalte anschlussfähiger für Suchmaschinen, Knowledge Graphs, Sprachassistenten, Rich Results und andere maschinelle Auswertungen.
Die verbreitetste Grundlage dafür ist Schema.org. Schema.org stellt ein gemeinsames Vokabular bereit, mit dem Webseiten Dinge wie Artikel, Organisationen, Personen, Produkte, Veranstaltungen, Breadcrumbs oder Rezepte beschreiben können. Dieses Vokabular kann unter anderem mit JSON-LD, Microdata oder RDFa eingebunden werden. (2)
JSON-LD: die heute sinnvollste Variante
In der Praxis sollte man strukturierte Daten meist als JSON-LD einbinden. JSON-LD steht für „JSON for Linked Data" und ist ein JSON-basiertes Format zur Beschreibung verknüpfter Daten. Der Vorteil: Das Markup kann sauber im <head> oder im HTML-Dokument stehen, ohne das eigentliche HTML mit zusätzlichen Attributen zu überfrachten. Google empfiehlt JSON-LD ausdrücklich, sofern die Website dies technisch ermöglicht. (3)
Ein einfacher JSON-LD-Block sieht zum Beispiel so aus:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Was sind strukturierte Daten?",
"description": "Strukturierte Daten erklären Suchmaschinen, welche Bedeutung Inhalte auf einer Webseite haben.",
"author": {
"@type": "Person",
"name": "Oli Feiler"
},
"publisher": {
"@type": "Organization",
"name": "urbanstudio"
},
"datePublished": "2026-06-22",
"dateModified": "2026-06-22",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.example.de/blog/was-sind-strukturierte-daten"
}
}
</script>
Dieser Code macht aus einem normalen Blogartikel keinen besseren Text. Aber er macht für Maschinen deutlicher, was dieser Text ist.
Ein Beispiel: Artikel-Markup
Für einen Blogartikel ist BlogPosting oder allgemeiner Article naheliegend. Wichtig ist, dass die strukturierten Daten den sichtbaren Inhalt der Seite korrekt beschreiben. Der Titel im JSON-LD sollte also zum sichtbaren Seitentitel passen. Das Veröffentlichungsdatum sollte wirklich das Veröffentlichungsdatum sein. Die Autorin oder der Autor sollte auch auf der Seite erkennbar sein.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Barrierefreiheit ist kein Feature",
"alternativeHeadline": "Warum digitale Zugänglichkeit zur Grundqualität des Webs gehört",
"description": "Ein Beitrag über Barrierefreiheit, Verantwortung und die Qualität digitaler Angebote.",
"image": [
"https://www.example.de/media/barrierefreiheit.jpg"
],
"author": {
"@type": "Person",
"name": "Oli Feiler"
},
"publisher": {
"@type": "Organization",
"name": "urbanstudio",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.de/assets/logo.png"
}
},
"datePublished": "2026-06-22",
"dateModified": "2026-06-22"
}
</script>
Technisch ist das simpel. Inhaltlich ist es anspruchsvoller, als es aussieht. Denn strukturierte Daten zwingen zu Klarheit: Wer ist Urheber? Was ist der primäre Inhalt? Welche Seite ist kanonisch? Welche Organisation steht dahinter? Genau deshalb passen sie gut zu sauber gepflegten Content-Modellen in einem CMS.
Ein zweites Beispiel: Breadcrumbs
Breadcrumbs sind ein gutes Beispiel, weil sie nicht nur Suchmaschinen helfen, sondern auch die Informationsarchitektur einer Seite sichtbar machen. Sie beschreiben, wo sich eine Seite innerhalb der Website befindet.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Startseite",
"item": "https://www.example.de/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.example.de/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Was sind strukturierte Daten?",
"item": "https://www.example.de/blog/was-sind-strukturierte-daten"
}
]
}
</script>
Hier sieht man gut, worum es eigentlich geht: Strukturierte Daten sind keine Dekoration. Sie sind maschinenlesbare Informationsarchitektur.
Was strukturierte Daten nicht leisten
Strukturierte Daten sind kein Ranking-Garant. Sie können Rich Results ermöglichen, aber nicht erzwingen. Google weist ausdrücklich darauf hin, dass korrektes Markup keine Garantie dafür ist, dass strukturierte Daten auch als Rich Result angezeigt werden. Die tatsächliche Darstellung hängt von mehreren Faktoren ab, darunter Suchkontext, Gerät, Standort, Qualität der Seite und Googles Einschätzung, welches Ergebnis für die Suchenden am hilfreichsten ist. (4)
Strukturierte Daten werden trotzdem oft falsch verkauft. Markup macht eine schwache Seite nicht sichtbarer. Sie helfen Suchmaschinen, Inhalte besser zu verstehen. Relevanz, technische Qualität und redaktionelle Arbeit lassen sich damit nicht ersetzen.
Typische Fehler
Der häufigste Fehler: Inhalte auszeichnen, die auf der Seite gar nicht sichtbar sind. Strukturierte Daten müssen den sichtbaren Hauptinhalt der Seite realitätsgetreu beschreiben. Wer Bewertungen, Preise, Personen oder Veranstaltungen markiert, die für Nutzer:innen nicht nachvollziehbar auf der Seite erscheinen, riskiert nicht nur wirkungslose Daten, sondern im schlimmsten Fall eine manuelle Maßnahme. (4)
Übertriebene Auszeichnung ist ein zweites Problem. Eine Kontaktseite ist kein Artikel. Eine Leistungsseite wird nicht zum FAQ, nur weil irgendwo Fragen stehen. Eine Veranstaltung ist nur dann eine Veranstaltung, wenn sie tatsächlich Datum, Ort und Teilnahmebezug hat. Strukturierte Daten funktionieren am besten, wenn sie nüchtern bleiben.
Hinzu kommt oft die Entkopplung vom CMS. Wenn strukturierte Daten händisch in Templates kopiert werden, veralten sie schnell. Sinnvoller ist es, sie aus den vorhandenen Inhaltsfeldern zu generieren: Titel, Teaser, Autor, Datum, Bild, Kategorie, kanonische URL, Organisation, Breadcrumb. Dann entstehen strukturierte Daten nicht als Zusatzaufgabe, sondern als Nebenprodukt sauberer Inhaltsmodellierung.
Sinnvolle Typen für viele Websites
Für klassische Unternehmens- und Verbandswebsites sind vor allem einige Schema-Typen interessant: Organization, WebSite, WebPage, Article oder BlogPosting, BreadcrumbList, Event, Person, gelegentlich FAQPage, Product, LocalBusiness oder JobPosting. Google unterstützt eine definierte Auswahl strukturierter Datentypen für Rich Results, darunter Artikel, Breadcrumbs, Events, Organisationen, Produkte, Job Postings, Videos und weitere Formate. (5)
FAQPage verdient einen eigenen Hinweis. Als Inhaltsformat ist es nach wie vor sinnvoll: Frage-Antwort-Strukturen lassen sich von Suchmaschinen und KI-Systemen gut auswerten. Als Weg zu sichtbaren Rich Results taugt es für die meisten Websites seit August 2023 allerdings nicht mehr. Google hat die FAQ-Rich-Result-Darstellung auf Regierungs- und Gesundheitswebsites beschränkt. (6)
Den Inhalt zuerst klären, dann das passende Schema wählen. Wer das Schema sucht und den Inhalt danach ausrichtet, hat das Prinzip verkehrt.
Testen nicht vergessen
Nach dem Einbau sollten strukturierte Daten getestet werden. Dafür gibt es zwei sinnvolle Werkzeuge: den Google Rich Results Test für Google-spezifische Rich-Result-Funktionen und den Schema Markup Validator für die allgemeinere Prüfung von Schema.org-Markup. Der Test zeigt technische Fehler, fehlende Pflichtfelder und mögliche Erweiterungen. Er ersetzt aber keine redaktionelle Prüfung. Ein valider JSON-LD-Block kann inhaltlich trotzdem falsch, irreführend oder nutzlos sein.
Webqualität, die Maschinen lesen
Strukturierte Daten sind ein stiller Teil moderner Webqualität. Der Inhalt wird dadurch nicht besser, wohl aber lesbarer für Maschinen. Am stärksten wirken sie dort, wo Inhalt, Technik und Informationsarchitektur sauber ineinandergreifen.
Kein SEO-Anstrich. Gute strukturierte Daten zeigen, dass eine Website verstanden hat, was ihre Inhalte bedeuten.
Quellen
- Google for Developers: Einführung in strukturierte Daten
- Schema.org: Organization of Schemas
- W3C: JSON-LD 1.1
- Google for Developers: Allgemeine Richtlinien für strukturierte Daten
- Google for Developers: Unterstützte strukturierte Datentypen für Rich Results
- Google for Developers: Changes to HowTo and FAQ rich results
Mehr lesen
