Strukturierte Daten (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.

Für 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 eingefügt werden.

Prüfe im technischen Audit-Ablauf, ob maschinenlesbare Angaben mit der sichtbaren Seite und ihrer kanonischen Identität übereinstimmen.

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

Einfach erklärt

Eine Webseite ist zuerst für Menschen gemacht. Menschen sehen Überschriften, Preise, Autoren, Bilder, Sternebewertungen, Termine oder eine Navigation. Suchmaschinen können vieles davon aus HTML, Text, Layout, Links und Kontext ableiten. Aber nicht alles ist eindeutig.

Structured Data fügt eine zweite Ebene hinzu. Diese Ebene sagt nicht nur "hier steht etwas", sondern "das ist der Preis", "das ist die Verfügbarkeit", "das ist die Autorin", "das ist das Veröffentlichungsdatum", "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 weiß jedes System schneller, was es vor sich hat, wo es hingehört und welche Eigenschaften wichtig sind.

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

Warum Structured Data für 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, Entitäten klarer machen und Suchergebnisse visuell erweitern. Beispiele sind Produktinformationen, Breadcrumbs, Veranstaltungsdaten, Organisationsinformationen, Videos, Artikelinformationen oder Review Snippets.

Der Nutzen ist besonders groß, wenn eine Website viele ähnliche 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 vertrauenswürdig. Eine Seite ohne klare Suchintention wird durch JSON-LD nicht hilfreich. Structured Data ist ein Verständnis- und Darstellungswerkzeug, kein Ersatz für 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 können.

Schema Markup meint im SEO-Alltag meistens die konkrete Auszeichnung mit Schema.org. Schema.org ist ein gemeinsames Vokabular für 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 für strukturierte Daten, sofern es für den jeweiligen Typ unterstützt wird. Microdata und RDFa sind ebenfalls unterstützte Formate für Rich-Result-Fähigkeit, aber JSON-LD ist für viele Teams wartbarer.

Kurz gesagt: Structured Data ist die Idee, Schema.org ist die Sprache, JSON-LD ist häufig 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 erklärt", "datePublished": "2026-06-21", "dateModified": "2026-06-21", "author": { "@type": "Person", "name": "Matthias Ramahi" }, "publisher": { "@type": "Organization", "name": "Crawl Foundry" } } ``

Das Beispiel zeigt den Kern: Die Seite enthält nicht nur Text. Der Code erklärt, welche Rolle einzelne Informationen spielen. Die Überschrift 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 für den jeweiligen Typ passen. Wenn ein erforderliches Feld fehlt oder ein Wert nicht zur Seite passt, kann die Seite für das Rich Result ungeeignet sein.

Formate für Structured Data

JSON-LD

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

Der große Vorteil: Die Daten können direkt aus dem CMS, aus Produktdaten, aus Autorenprofilen oder aus Navigationstabellen erzeugt werden. Entwickler müssen nicht jedes sichtbare HTML-Element einzeln mit Attributen versehen. Wenn das Datenmodell sauber ist, kann JSON-LD über viele Seiten hinweg konsistent ausgespielt werden.

Microdata

Microdata wird direkt in sichtbare HTML-Elemente eingebaut. Das kann für einfache Seiten funktionieren, wird aber bei komplexen Layouts schnell unübersichtlich. Wenn ein Designer oder Entwickler später HTML-Struktur verändert, kann versehentlich auch das Markup brechen.

RDFa

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

Was Rich Results wirklich bedeuten

Rich Results sind Suchergebnisse, die über den klassischen blauen Link hinausgehen. Sie können Bilder, Preise, Bewertungen, Breadcrumbs, Produktdaten, Veranstaltungsinformationen oder andere visuelle Elemente enthalten.

Structured Data kann eine Seite für solche Darstellungen qualifizieren. "Qualifizieren" ist hier das wichtige Wort. Es bedeutet nicht, dass Google das Rich Result immer ausspielt. Die tatsächliche Darstellung kann je nach Anfrage, Gerät, Standort, Suchkontext, Qualität, Richtlinien und Googles Entscheidung anders aussehen.

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

Welche Markups häufig sinnvoll sind

Article, BlogPosting und NewsArticle

Diese Typen helfen bei redaktionellen Inhalten. Sie können Headline, Autor, Publikationsdatum, Aktualisierungsdatum, Bilder und Publisher klarer machen. Für Blogs, Wissensseiten, Glossare und News ist das oft ein grundlegender Baustein.

Product und Offer

Product Markup kann Name, Bild, Preis, Verfügbarkeit, Bewertung, Marke oder Varianten beschreiben. In E-Commerce ist das besonders wertvoll. Aber die Daten müssen 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 unspektakulär, aber sehr nützlich, weil es Hierarchie und Navigation eindeutig macht.

Organization, LocalBusiness und Person

Diese Typen helfen, Identität zu strukturieren. Sie können Namen, Logos, Kontaktpunkte, Standorte, Profile und Verbindungen beschreiben. Für Knowledge-Graph-Verständnis und konsistente Entitätssignale sind sie wichtig, auch wenn sie nicht immer sofort spektakuläre Snippets erzeugen.

VideoObject, Event, JobPosting und weitere Spezialtypen

Spezialtypen können stark sein, wenn der Seitentyp wirklich passt. Genau deshalb sollte man vor der Umsetzung immer die aktuelle Google Search Gallery prüfen. Nicht jeder Schema.org-Typ erzeugt ein Google-Rich-Result, und unterstützte Features können sich ändern.

Richtlinien, die du ernst nehmen solltest

Die wichtigste Regel ist einfach: Markiere nur Inhalte, die zur Seite passen und für 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 Qualitätsanforderungen: Informationen sollen aktuell sein, zum Hauptinhalt passen, nicht irreführen, nicht irrelevant sein und nicht genutzt werden, um Nutzer oder Suchsysteme zu täuschen. Außerdem müssen die jeweiligen spezifischen Richtlinien des Rich-Result-Typs eingehalten werden.

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

Ein weiterer Punkt wird oft unterschätzt: Vollständigkeit. Wenn ein Rich-Result-Typ Pflichtfelder hat, müssen sie vorhanden sein. Empfohlene Felder sind nicht immer zwingend, können aber die Qualität des Ergebnisses für 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 lässt den Rest hart codiert stehen. Das funktioniert vielleicht für 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 ändert, ändert 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 prüft, ob eine URL oder ein Code-Snippet für von Google unterstützte Rich Results gültig 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 prüft, sondern den gecrawlten Kontext einer echten Seite.

Schema Markup Validator

Der Schema Markup Validator prüft 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 prüfen willst.

Search Console Reports

Search Console kann für bestimmte strukturierte Datentypen Reports anzeigen, sobald Google entsprechendes Markup erkennt. Diese Reports sind wichtig, weil sie Muster über 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, Verfügbarkeit, Marke und Bewertungen. Das SEO-Team will Product Markup ausspielen, damit Google die Daten klarer verarbeiten kann und die Seiten für 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 fällt auf, dass alte Produkte manchmal keinen Lagerstatus haben. Das Team fälscht keine Verfügbarkeit, sondern repariert die Datenquelle. Danach werden mehrere Produkttypen getestet: verfügbar, ausverkauft, Variante, reduzierter Preis, Produkt ohne Bewertung. Erst dann wird das Template ausgerollt.

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

Häufige Fehler

• Markup für Inhalte erstellen, die Nutzer auf der Seite nicht sehen.
• Den attraktivsten Rich-Result-Typ wählen, obwohl der Seitentyp nicht passt.
• Preise, Bewertungen oder Verfügbarkeit 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, gelöscht oder veraltet sind.
• Schema.org-Validität mit Google-Rich-Result-Fähigkeit verwechseln.
• Strukturierte Daten als direkten Ranking-Booster verkaufen.
• Nach Google-Dokumentationsupdates nicht prüfen, ob Features oder Anforderungen geändert wurden.
• Mehrere JSON-LD-Blöcke aus verschiedenen Plugins ausspielen, die sich widersprechen.

Mini-Workflow

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

Mit Crawl Foundry anwenden

Der Site Audit von Crawl Foundry verbindet Crawl-Ergebnisse, interne Links und technische Befunde. Prüfe betroffene URLs und priorisiere die nötigen Korrekturen.

Site Audit ansehen

Verwandte Begriffe

Diese Begriffe passen als nächste Leseschritte:

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

Quellen für 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