Strukturierte Daten beschreiben den Inhalt einer Seite in einem normierten Vokabular, das Suchmaschinen auslesen können. Richtig gesetzt, öffnen sie den Zugang zu Rich Results — Bewertungssterne, Brotkrumen, aufklappbare Fragen — ohne etwas an dem zu ändern, was der Besucher sieht. Dieser Leitfaden erklärt das JSON-LD-Format, die wirklich nützlichen Schema.org-Typen und das Vorgehen, um sie auszuspielen und zu kontrollieren.
Was strukturierte Daten sind
Ein strukturiertes Datum ist ein Markup, das den Inhalt einer Seite annotiert, um ihre Bedeutung explizit zu machen: „das ist ein Artikel“, „sein Autor ist der und der“, „er wurde an diesem Datum veröffentlicht“. Das Referenzvokabular ist Schema.org, gepflegt von einem Konsortium aus Google, Microsoft, Yahoo und Yandex. Dieses Markup ändert die Darstellung nicht: Es richtet sich an Maschinen, nicht an den Leser.
Es geht um Sichtbarkeit. Suchmaschinen nutzen diese Annotationen, um Rich Results zu erzeugen, die größer und klickstärker sind. Sie sind kein direkter Ranking-Faktor, aber der Zugewinn an Fläche und Klickrate ist messbar — ein Effekt, den man in den Search-Console-Berichten verfolgen sollte.
JSON-LD, Microdata, RDFa: was wählen
Drei Syntaxen drücken dasselbe Vokabular aus. JSON-LD hat sich durchgesetzt, weil es das Markup vom HTML trennt: ein eigenständiger Skriptblock, einfacher zu erzeugen, einzufügen und zu pflegen.
| Format | Wo es lebt | Pflege | Empfehlung |
|---|---|---|---|
| JSON-LD | Ein eigenständiger <script>-Block | Einfach, vom HTML entkoppelt | Von Google empfohlenes Format |
| Microdata | Attribute im sichtbaren HTML | An das Markup gekoppelt, wortreich | Alt, migrieren |
| RDFa | Attribute im HTML | Mächtig, aber komplex | Spezialfälle |
Die Schema.org-Typen, die zählen
Das Vokabular umfasst Hunderte Typen, aber eine Handvoll deckt den Großteil der Bedürfnisse einer professionellen Website ab.
| Typ | Verwendung | Mögliches Rich Result |
|---|---|---|
Article / NewsArticle | Redaktioneller Inhalt | Großes Vorschaubild, Datum, Autor |
Product + Offer | Produktseite | Preis, Verfügbarkeit, Bewertungen |
FAQPage | Fragen und Antworten | Aufgeklapptes Akkordeon unter dem Link |
BreadcrumbList | Brotkrumenpfad | Angezeigter Navigationspfad |
Organization / LocalBusiness | Identität, Kontaktdaten | Knowledge Panel, Öffnungszeiten |
Zwei Prinzipien leiten die Wahl: nur auszeichnen, was auf der Seite sichtbar ist, und Typen bevorzugen, die für die betreffende Tätigkeit tatsächlich eine angereicherte Darstellung auslösen.
Einen korrekten JSON-LD-Block schreiben
Ein JSON-LD-Block gehört in den <head> oder den <body>, in ein Skript-Tag mit dediziertem Typ. Hier ein vollständiges Beispiel für einen Artikel:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data with JSON-LD",
"datePublished": "2026-09-08",
"dateModified": "2026-09-08",
"author": { "@type": "Person", "name": "Simon Janvier" },
"publisher": {
"@type": "Organization",
"name": "Mail Studio",
"logo": { "@type": "ImageObject", "url": "https://www.mail-studio.com/logo.png" }
},
"image": "https://www.mail-studio.com/cover.jpg"
}Der Block wird dann in der Seite deklariert, allein in seinem Tag:
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>Einige Regeln vermeiden die meisten Fehler: Daten im ISO-8601-Format, absolute URLs und strikte Übereinstimmung zwischen den ausgezeichneten Werten und dem angezeigten Inhalt.
Strukturierte Daten ändern nichts an dem, was der Leser sieht; sie ändern, wie die Seite in den Suchergebnissen erscheint.
Markup erzeugen und einfügen, ohne sich zu wiederholen
Nur wenige Websites schreiben ihr JSON-LD von Hand, Seite für Seite. Je nach Stack koexistieren drei Ansätze:
- Serverseitige Erzeugung: Das Template erzeugt den Block aus den Daten der Seite (Titel, Datum, Autor). Das ist der zuverlässigste Ansatz, weil es eine einzige Quelle der Wahrheit gibt.
- CMS-Erweiterung: Unter WordPress setzen SEO-Plugins automatisch
Article,BreadcrumbListundOrganization. Praktisch, aber zu prüfen: Die Voreinstellungen zeichnen manchmal unnütze Typen aus. - Tag-Manager: JSON-LD über einen Tag-Manager einzufügen ist möglich, hängt aber davon ab, dass die Engine JavaScript rendert — weniger robust als serverseitiges Rendering.
Welche Methode auch immer: Ein Prinzip hat Vorrang — eine einzige Quelle der Wahrheit. Ein datePublished, das dem angezeigten Datum widerspricht, ist ein negatives Signal, kein Detail.
Die Fehler, an denen Markup scheitert
Die meisten strukturierten Daten, die Engines ignorieren, werden aus wiederkehrenden Gründen ignoriert, die sich leicht beheben lassen, sobald man sie kennt. Sie zu kennen, spart beim Ausspielen echte Zeit.
- Fehlende Pflichteigenschaften. Jeder Typ verlangt Pflichteigenschaften: Ein
Productohne gültigename– oderoffers-Angabe öffnet kein Rich Result. Der Rich-Results-Test nennt genau, was fehlt. - Werte, die der Seite widersprechen. Ein ausgezeichneter Preis, der vom angezeigten abweicht, eine Durchschnittsnote ohne sichtbare Bewertungen: Signale, die eine manuelle Maßnahme auslösen statt eines Sichtbarkeitsbonus.
- Konkurrierende Blöcke. Ein Theme, ein SEO-Plugin und ein Tag-Manager, die je ihr eigenes
Organizationsetzen, erzeugen widersprüchliche Duplikate. Eine einzige Quelle muss jeden Typ erzeugen. - Nicht verknüpfte Entitäten. Objekte mit
@idzu verknüpfen, vermeidet, Organisation oder Autor von Seite zu Seite neu zu deklarieren, und hilft Engines, den Graphen der Website zu konsolidieren. - Nicht konforme Bilder. Mehrere Typen empfehlen hochauflösende Bilder in bestimmten Seitenverhältnissen; eine fehlende oder zu kleine Bild-URL nimmt dem Artikel sein großes Vorschaubild.
- Per JavaScript geladene Inhalte. Existieren die ausgezeichneten Daten erst nach Ausführung eines Skripts, muss der Crawler sie beim Rendern sehen können, sonst beschreibt das Markup eine Seite, die er nicht wahrnimmt.
Ein und dasselbe Dokument darf legitim mehrere Typen kombinieren: Ein Artikel, der häufige Fragen beantwortet, trägt zugleich Article und FAQPage. Verschachtelung ist erlaubt, sofern jeder ergänzte Typ tatsächlich vorhandenem Inhalt entspricht, sonst verwässert das Signal. Keiner dieser Fehler ist fatal: Alle werden vor dem Livegang erkannt, sobald der Test ein systematischer Schritt des Ausspielens wird.
Ausspielen, testen und überwachen
Vor jeder Veröffentlichung prüft Googles Rich-Results-Test die Syntax und meldet fehlende Eigenschaften. In Produktion verfolgt der Bericht „Verbesserungen“ der Search Console die Indexierung des Markups, Warnungen und Fehler nach Typ.
Die Überwachung fügt sich dann in die Gesamtsteuerung der Website ein: Rich Results liest man in denselben Dashboards wie den Traffic und die Core Web Vitals, neben denen sie das technische Fundament des SEO bilden.
Achtung. Inhalte auszuzeichnen, die auf der Seite fehlen, Bewertungen aufzublähen oder eine unsichtbare FAQ zu deklarieren, setzt einer manuellen Maßnahme wegen „Spam mit strukturierten Daten“ aus. Das Markup muss stets getreu widerspiegeln, was tatsächlich sichtbar ist.
Was bleibt
- Strukturierte Daten annotieren Inhalte für die Engines; sie öffnen Rich Results, ohne die Darstellung zu ändern.
- JSON-LD ist das empfohlene Format: vom HTML entkoppelt, einfach zu erzeugen und zu pflegen.
- Sich auf wenige nützliche Typen konzentrieren (Article, Product, FAQPage, BreadcrumbList, Organization) und nur Sichtbares auszeichnen.
- Mit dem Rich-Results-Test validieren, dann den Bericht „Verbesserungen“ der Search Console überwachen.
Auf meinen eigenen Medien-Websites hat das Article– und BreadcrumbList-Markup mehr für die Sichtbarkeit getan als so manche spektakulärere Optimierung. Mein Rat: klein anfangen, mit einem einzigen sauberen und getesteten Typ, statt mit einem Stapel ungefährer Schemata, die Google am Ende ignoriert. Beständigkeit schlägt Vollständigkeit. — Simon Janvier
Primärquelle: die Google-Dokumentation zu strukturierten Daten und das Referenzvokabular auf Schema.org.
