Structured Data

Kurz gesagt

Structured Data sind strukturierte, maschinenlesbare Informationen im Code einer Webseite. Sie sagen Suchmaschinen genauer, was auf einer Seite vorkommt: ein Produkt, ein Artikel, eine Person, eine Organisation, ein Video, ein Breadcrumb, ein Event, ein Jobangebot oder eine Bewertung.

Fuer SEO wird Structured Data meistens mit dem Schema.org-Vokabular und dem JSON-LD-Format umgesetzt. Schema.org liefert die Begriffe, zum Beispiel Product, Article oder Organization. JSON-LD ist die technische Schreibweise, in der diese Informationen oft in den HTML-Code eingefuegt werden.

Der wichtigste Gedanke: Structured Data ist kein Zaubertrick fuer Rankings. Es ist eine saubere Beschreibungsschicht. Sie hilft Suchsystemen, Inhalte, Beziehungen und Seitentypen eindeutiger zu verstehen. Dadurch kann eine Seite fuer bestimmte Rich Results in Frage kommen. Aber Google garantiert kein Rich Result, selbst wenn das Markup technisch korrekt ist.

Einfach erklaert

Eine Webseite ist zuerst fuer Menschen gemacht. Menschen sehen Ueberschriften, Preise, Autoren, Bilder, Sternebewertungen, Termine oder eine Navigation. Suchmaschinen koennen vieles davon aus HTML, Text, Layout, Links und Kontext ableiten. Aber nicht alles ist eindeutig.

Structured Data fuegt eine zweite Ebene hinzu. Diese Ebene sagt nicht nur "hier steht etwas", sondern "das ist der Preis", "das ist die Verfuegbarkeit", "das ist die Autorin", "das ist das Veroeffentlichungsdatum", "das ist der Pfad in der Seitenhierarchie".

Man kann es mit Etiketten in einem gut organisierten Lager vergleichen. Die Ware selbst bleibt gleich. Aber durch saubere Etiketten weiss jedes System schneller, was es vor sich hat, wo es hingehoert und welche Eigenschaften wichtig sind.

Gutes Structured Data erfindet nichts. Es beschreibt, was Nutzer auf der Seite wirklich sehen oder was logisch zur Seite gehoert. Wenn der sichtbare Inhalt und das Markup auseinanderlaufen, entsteht kein SEO-Vorteil, sondern ein Qualitaetsproblem.

Warum Structured Data fuer SEO wichtig ist

Structured Data macht Bedeutung expliziter. Ohne Markup muss ein Suchsystem raten: Ist diese Zahl ein Preis, eine Bewertung oder eine Artikelnummer? Ist diese Person Autor, Interviewgast oder Ansprechpartner? Ist diese Liste eine Navigation, ein Rezeptschritt oder eine Produktvariante?

Mit gutem Markup bekommt das System standardisierte Hinweise. Das kann die Verarbeitung erleichtern, Entitaeten klarer machen und Suchergebnisse visuell erweitern. Beispiele sind Produktinformationen, Breadcrumbs, Veranstaltungsdaten, Organisationsinformationen, Videos, Artikelinformationen oder Review Snippets.

Der Nutzen ist besonders gross, wenn eine Website viele aehnliche Seiten hat. Ein einzelner Blogartikel kann auch ohne Markup verstanden werden. Bei 10.000 Produktseiten, hunderten Standorten oder vielen Autorenprofilen wird saubere Struktur aber schnell wichtig. Structured Data macht Templates konsistenter und reduziert Interpretationsspielraum.

Trotzdem gilt: Markup ersetzt keinen guten Inhalt. Ein schlechter Produktdatensatz bleibt schlecht. Eine nicht sichtbare Bewertung wird nicht vertrauenswuerdig. Eine Seite ohne klare Suchintention wird durch JSON-LD nicht hilfreich. Structured Data ist ein Verstaendnis- und Darstellungswerkzeug, kein Ersatz fuer Substanz.

Structured Data, Schema Markup und JSON-LD

Diese Begriffe werden oft vermischt, meinen aber nicht genau dasselbe.

Structured Data ist der Oberbegriff. Er beschreibt das Prinzip: Informationen werden in einer strukturierten Form bereitgestellt, damit Maschinen sie leichter lesen koennen.

Schema Markup meint im SEO-Alltag meistens die konkrete Auszeichnung mit Schema.org. Schema.org ist ein gemeinsames Vokabular fuer Dinge und Eigenschaften, zum Beispiel Product, Article, Organization, Person, BreadcrumbList, Event, VideoObject oder FAQPage.

JSON-LD ist ein Format. Es nutzt JSON und Linked-Data-Konzepte, um diese Aussagen in den Code einzubauen. Google empfiehlt JSON-LD fuer strukturierte Daten, sofern es fuer den jeweiligen Typ unterstuetzt wird. Microdata und RDFa sind ebenfalls unterstuetzte Formate fuer Rich-Result-Faehigkeit, aber JSON-LD ist fuer viele Teams wartbarer.

Kurz gesagt: Structured Data ist die Idee, Schema.org ist die Sprache, JSON-LD ist haeufig die Schreibweise.

Ein kleines JSON-LD-Beispiel

Ein sehr vereinfachter Article-Block kann so aussehen:

``json { "@context": "https://schema.org", "@type": "Article", "headline": "Core Web Vitals einfach erklaert", "datePublished": "2026-06-21", "dateModified": "2026-06-21", "author": { "@type": "Person", "name": "Matthias Ramahi" }, "publisher": { "@type": "Organization", "name": "Contextter" } } ``

Das Beispiel zeigt den Kern: Die Seite enthaelt nicht nur Text. Der Code erklaert, welche Rolle einzelne Informationen spielen. Die Ueberschrift ist eine Headline, das Datum ist ein Publikationsdatum, die Person ist der Autor, die Organisation ist der Publisher.

In der Praxis muss das Markup zum sichtbaren Inhalt und zur Google-Dokumentation fuer den jeweiligen Typ passen. Wenn ein erforderliches Feld fehlt oder ein Wert nicht zur Seite passt, kann die Seite fuer das Rich Result ungeeignet sein.

Formate fuer Structured Data

JSON-LD

JSON-LD wird meist als Script-Block in den HTML-Code eingefuegt. Es ist vom sichtbaren HTML getrennt. Das macht es in modernen CMS-, React-, Next.js- oder Template-Systemen gut wartbar.

Der grosse Vorteil: Die Daten koennen direkt aus dem CMS, aus Produktdaten, aus Autorenprofilen oder aus Navigationstabellen erzeugt werden. Entwickler muessen nicht jedes sichtbare HTML-Element einzeln mit Attributen versehen. Wenn das Datenmodell sauber ist, kann JSON-LD ueber viele Seiten hinweg konsistent ausgespielt werden.

Microdata

Microdata wird direkt in sichtbare HTML-Elemente eingebaut. Das kann fuer einfache Seiten funktionieren, wird aber bei komplexen Layouts schnell unuebersichtlich. Wenn ein Designer oder Entwickler spaeter HTML-Struktur veraendert, kann versehentlich auch das Markup brechen.

RDFa

RDFa ist ebenfalls HTML-basiert und kann strukturierte Aussagen ausdruecken. Im heutigen SEO-Alltag ist es weniger verbreitet als JSON-LD. Es bleibt aber wichtig zu wissen, dass Google fuer Rich Results mehrere Formate unterstuetzt, solange die jeweiligen technischen und qualitativen Richtlinien eingehalten werden.

Was Rich Results wirklich bedeuten

Rich Results sind Suchergebnisse, die ueber den klassischen blauen Link hinausgehen. Sie koennen Bilder, Preise, Bewertungen, Breadcrumbs, Produktdaten, Veranstaltungsinformationen oder andere visuelle Elemente enthalten.

Structured Data kann eine Seite fuer solche Darstellungen qualifizieren. "Qualifizieren" ist hier das wichtige Wort. Es bedeutet nicht, dass Google das Rich Result immer ausspielt. Die tatsaechliche Darstellung kann je nach Anfrage, Geraet, Standort, Suchkontext, Qualitaet, Richtlinien und Googles Entscheidung anders aussehen.

Deshalb ist eine gesunde Erwartung wichtig. Structured Data ist erfolgreich, wenn es korrekt, aktuell, vollstaendig und konsistent beschreibt, was auf der Seite ist. Das Rich Result ist ein moeglicher Effekt, nicht die einzige Definition von Erfolg.

Welche Markups haeufig sinnvoll sind

Article, BlogPosting und NewsArticle

Diese Typen helfen bei redaktionellen Inhalten. Sie koennen Headline, Autor, Publikationsdatum, Aktualisierungsdatum, Bilder und Publisher klarer machen. Fuer Blogs, Wissensseiten, Glossare und News ist das oft ein grundlegender Baustein.

Product und Offer

Product Markup kann Name, Bild, Preis, Verfuegbarkeit, Bewertung, Marke oder Varianten beschreiben. In E-Commerce ist das besonders wertvoll. Aber die Daten muessen stimmen. Veraltete Preise oder erfundene Bewertungen sind nicht nur technische Fehler, sondern Vertrauensprobleme.

BreadcrumbList

Breadcrumb Markup beschreibt die Position einer Seite in der Website-Struktur. Es ist oft unspektakulaer, aber sehr nuetzlich, weil es Hierarchie und Navigation eindeutig macht.

Organization, LocalBusiness und Person

Diese Typen helfen, Identitaet zu strukturieren. Sie koennen Namen, Logos, Kontaktpunkte, Standorte, Profile und Verbindungen beschreiben. Fuer Knowledge-Graph-Verstaendnis und konsistente Entitaetssignale sind sie wichtig, auch wenn sie nicht immer sofort spektakulaere Snippets erzeugen.

VideoObject, Event, JobPosting und weitere Spezialtypen

Spezialtypen koennen stark sein, wenn der Seitentyp wirklich passt. Genau deshalb sollte man vor der Umsetzung immer die aktuelle Google Search Gallery pruefen. Nicht jeder Schema.org-Typ erzeugt ein Google-Rich-Result, und unterstuetzte Features koennen sich aendern.

Richtlinien, die du ernst nehmen solltest

Die wichtigste Regel ist einfach: Markiere nur Inhalte, die zur Seite passen und fuer Nutzer sichtbar oder nachvollziehbar sind. Wenn JSON-LD eine Bewertung, einen Autor, einen Preis oder ein Event beschreibt, sollte die Seite diesen Inhalt ebenfalls sauber zeigen.

Google nennt mehrere Qualitaetsanforderungen: Informationen sollen aktuell sein, zum Hauptinhalt passen, nicht irrefuehren, nicht irrelevant sein und nicht genutzt werden, um Nutzer oder Suchsysteme zu taeuschen. Ausserdem muessen die jeweiligen spezifischen Richtlinien des Rich-Result-Typs eingehalten werden.

Technisch muss Google die Seite und die relevanten Ressourcen crawlen koennen. Structured Data auf per noindex, robots.txt oder Zugriffsschutz blockierten Seiten kann nicht sinnvoll fuer Search verarbeitet werden. Bilder, die im Markup referenziert werden, sollten ebenfalls crawlbar und indexierbar sein.

Ein weiterer Punkt wird oft unterschaetzt: Vollstaendigkeit. Wenn ein Rich-Result-Typ Pflichtfelder hat, muessen sie vorhanden sein. Empfohlene Felder sind nicht immer zwingend, koennen aber die Qualitaet des Ergebnisses fuer Nutzer verbessern.

Implementierung als Datenmodell, nicht als Copy-Paste

Schlechtes Structured Data entsteht oft durch Copy-Paste. Jemand nimmt ein Beispiel aus der Dokumentation, ersetzt ein paar Werte und laesst den Rest hart codiert stehen. Das funktioniert vielleicht fuer eine Testseite, skaliert aber schlecht.

Besser ist ein Datenmodell-Ansatz. Der Seitentyp entscheidet, welche Schema-Typen gebraucht werden. Die Felder kommen aus echten Quellen: Produktpreis aus dem Produktfeed, Autor aus dem CMS, Breadcrumb aus der Navigation, Event-Datum aus der Event-Datenbank, Unternehmensdaten aus einer zentralen Brand-Quelle.

So entsteht weniger Drift. Wenn sich ein Preis aendert, aendert sich auch das Markup. Wenn ein Autorprofil aktualisiert wird, ist die strukturierte Ausgabe konsistent. Wenn ein CMS-Feld fehlt, kann das Template warnen, statt fehlerhaftes Markup auszugeben.

Testen und Validieren

Rich Results Test

Der Google Rich Results Test prueft, ob eine URL oder ein Code-Snippet fuer von Google unterstuetzte Rich Results gueltig ist. Er ist der wichtigste Test, wenn das Ziel ein Google-Rich-Result ist.

URL Inspection in Search Console

Die URL Inspection zeigt, wie Google eine konkrete URL sieht. Sie hilft nach dem Deployment, weil sie nicht nur ein Code-Snippet prueft, sondern den gecrawlten Kontext einer echten Seite.

Schema Markup Validator

Der Schema Markup Validator prueft breiter, ob Schema.org-Markup syntaktisch und strukturell verstanden wird. Er ist hilfreich, wenn du Markup baust, das nicht direkt an ein Google-Rich-Result gebunden ist, oder wenn du die Schema.org-Ebene getrennt pruefen willst.

Search Console Reports

Search Console kann fuer bestimmte strukturierte Datentypen Reports anzeigen, sobald Google entsprechendes Markup erkennt. Diese Reports sind wichtig, weil sie Muster ueber URL-Gruppen sichtbar machen. Ein Fehler auf einem Template kann hunderte URLs betreffen.

Ein realistisches Beispiel

Ein Shop hat 8.000 Produktseiten. Sichtbar sind Produktname, Bilder, Preis, Verfuegbarkeit, Marke und Bewertungen. Das SEO-Team will Product Markup ausspielen, damit Google die Daten klarer verarbeiten kann und die Seiten fuer passende Produktdarstellungen in Frage kommen.

Statt JSON-LD manuell in Templates zu kopieren, definiert das Team ein Mapping: name kommt aus dem Produkttitel, image aus den freigegebenen Produktbildern, offers.price aus dem aktuellen Preis, offers.availability aus dem Lagerstatus, aggregateRating nur dann, wenn echte sichtbare Bewertungen vorhanden sind.

Beim Test im Rich Results Test faellt auf, dass alte Produkte manchmal keinen Lagerstatus haben. Das Team faelscht keine Verfuegbarkeit, sondern repariert die Datenquelle. Danach werden mehrere Produkttypen getestet: verfuegbar, ausverkauft, Variante, reduzierter Preis, Produkt ohne Bewertung. Erst dann wird das Template ausgerollt.

Das ist gute Structured-Data-Arbeit: nicht Snippet-Jagd, sondern korrekte Uebersetzung echter Seiteninformationen in ein maschinenlesbares Format.

Haeufige Fehler

• Markup fuer Inhalte erstellen, die Nutzer auf der Seite nicht sehen.
• Den attraktivsten Rich-Result-Typ waehlen, obwohl der Seitentyp nicht passt.
• Preise, Bewertungen oder Verfuegbarkeit hart codieren.
• Nur eine Beispiel-URL testen, obwohl das Template viele Varianten hat.
• Warnungen ignorieren, bis sie nach einem Template-Update zu Fehlern werden.
• Markup aus CMS-Feldern erzeugen, die leer, geloescht oder veraltet sind.
• Schema.org-Validitaet mit Google-Rich-Result-Faehigkeit verwechseln.
• Strukturierte Daten als direkten Ranking-Booster verkaufen.
• Nach Google-Dokumentationsupdates nicht pruefen, ob Features oder Anforderungen geaendert wurden.
• Mehrere JSON-LD-Bloecke aus verschiedenen Plugins ausspielen, die sich widersprechen.

Mini-Workflow

1. Bestimme den Seitentyp und den Zweck des Markups. 2. Pruefe die aktuelle Google-Dokumentation und den passenden Schema.org-Typ. 3. Waehle JSON-LD, wenn der Typ es fuer Google Search unterstuetzt. 4. Verbinde jedes Property mit einer echten Datenquelle. 5. Stelle sicher, dass markierte Informationen sichtbar oder logisch nachvollziehbar sind. 6. Baue Tests fuer mehrere Template-Varianten, nicht nur fuer eine URL. 7. Pruefe mit Rich Results Test und Schema Markup Validator. 8. Nutze URL Inspection fuer echte Live-URLs nach dem Deployment. 9. Ueberwache Search Console Reports und Fehlertrends. 10. Dokumentiere Pflichtfelder, Datenquellen und Verantwortlichkeiten.

Contextter-Perspektive

Contextter betrachtet Structured Data als Teil einer groesseren SEO-Qualitaetskette. Eine Seite ist nicht fertig, nur weil der Text gut klingt. Sie braucht klare Entitaeten, saubere Metadaten, nachvollziehbare Autoren- und Quelleninformationen, passende interne Struktur und technische Signale, die Suchsysteme verarbeiten koennen.

Fuer Content-Teams ist das besonders wichtig. Structured Data sollte nicht erst am Ende als Entwickler-Ticket angeklebt werden. Es gehoert frueh in Briefing und Content-Modell: Welche Entitaeten kommen vor? Wer ist Autor? Welche Daten muessen gepflegt werden? Welche Seitentypen sollen skalierbar ausspielbar sein?

So wird Markup nicht zu Kosmetik, sondern zu Infrastruktur. Es sorgt dafuer, dass gute Inhalte nicht nur fuer Menschen klar sind, sondern auch fuer Systeme, die diese Inhalte crawlen, interpretieren, zusammenfassen und in Suchergebnisse einordnen.

Verwandte Begriffe

Diese Begriffe passen als naechste Leseschritte:

• schema-markup
• rich-snippet
• knowledge-graph
• technical-seo-advanced
• content-optimization

Quellen fuer den Review

• Google Search Central: Intro to structured data markup
• Google Search Central: General structured data guidelines
• Google Search Central: Search Gallery
• Google Search Central: Generate structured data with JavaScript
• Google Search Central: Rich Results Test
• Schema.org: Getting started with schema.org
• Schema.org: validator