Schema.org & JSON-LD in der Praxis: strukturierte Daten richtig einsetzen
Strukturierte Daten sind taismos Steckenpferd. Dominik baut für Kunden konsistente Wissensgraphen in JSON-LD, die Rich Results ermöglichen und KI-Systemen die Einordnung erleichtern.
🔄 Zuletzt aktualisiert: 09.08.2026
Strukturierte Daten nach dem Vokabular von schema.org sind maschinenlesbare Zusatzinformationen im Quelltext einer Website. Sie sagen Suchmaschinen und KI-Systemen explizit, worum es auf einer Seite geht: Ist das ein Artikel, ein Produkt, ein Unternehmen, eine FAQ? Das empfohlene Format ist JSON-LD. Richtig eingesetzt ermöglichen strukturierte Daten Rich Results in der Suche und machen dein Unternehmen für KI-Systeme klar erfassbar. Dieser Leitfaden zeigt dir praxisnah, wie du JSON-LD aufbaust, welche Typen zählen und wie du typische Fehler vermeidest.
👉 Du willst wissen, ob dein Schema sauber ist? Ein SEO-Audit prüft deine strukturierten Daten im Detail.
Was sind strukturierte Daten?
Eine Website besteht aus Text, den Menschen lesen. Für eine Maschine ist dieser Text aber zunächst nur eine Folge von Zeichen ohne klare Bedeutung. Strukturierte Daten schließen diese Lücke: Sie liefern eine zusätzliche, streng geordnete Beschreibung dessen, was auf der Seite steht, in einem Format, das Maschinen eindeutig verstehen. Aus „irgendein Text über eine Firma“ wird so „eine Organisation mit diesem Namen, dieser Adresse, diesen Leistungen“.
Das Vokabular dafür liefert schema.org, ein gemeinsames Projekt der großen Suchmaschinen. Es definiert Tausende von Typen (etwa Organization, Article, Product) und deren Eigenschaften. Die technische Umsetzung, also wie diese Beschreibung in die Seite kommt, erfolgt in einem der drei Formate, von denen JSON-LD das mit Abstand empfohlene ist. Strukturierte Daten ändern nicht, was der Nutzer sieht, sie ergänzen unsichtbar die maschinenlesbare Bedeutung.
Warum strukturierte Daten 2026 wichtiger werden
Strukturierte Daten hatten lange einen klaren, aber begrenzten Nutzen: Sie ermöglichten hübschere Suchergebnisse. 2026 ist ihr Wert deutlich gewachsen, aus zwei Gründen. Erstens sind Rich Results, also angereicherte Suchergebnisse mit Sternen, Preisen oder Breadcrumb-Pfaden, zu einem echten Wettbewerbsfaktor geworden. Sie erhöhen die Klickrate spürbar, ohne dass sich die Position ändert.
Zweitens, und das ist der eigentliche Wandel: KI-Systeme und generative Suchmaschinen verlassen sich auf klare, strukturierte Entitäten, um Inhalte zu verstehen und korrekt zuzuordnen. Wer seine Organisation, seine Autoren und seine Leistungen sauber ausgezeichnet hat, macht es Maschinen leicht, ihn richtig einzuordnen und zu zitieren. Strukturierte Daten sind damit von einem netten Extra zur Grundlage sowohl klassischer Sichtbarkeit als auch der KI-Sichtbarkeit geworden. Sie sind die Sprache, in der Websites mit Maschinen sprechen.
Die Formate im Vergleich: JSON-LD, Microdata, RDFa
Es gibt drei Wege, strukturierte Daten in eine Seite zu bringen. Die Wahl ist heute eindeutig, aber es lohnt, den Unterschied zu kennen.
Microdata und RDFa weben die Auszeichnung als Attribute direkt in den HTML-Code ein. Das ist möglich, aber fehleranfällig und schwer zu pflegen, weil sich Struktur und Inhalt vermischen. JSON-LD geht einen anderen Weg: Die gesamte Auszeichnung steht in einem separaten Script-Block im Kopf oder Körper der Seite, sauber getrennt vom sichtbaren HTML. Das macht es lesbar, pflegbar und robust gegen Änderungen am Layout. Google empfiehlt JSON-LD ausdrücklich, und in der Praxis nutzen wir bei taismo ausschließlich dieses Format.
Wie JSON-LD aufgebaut ist
JSON-LD ist im Kern ein einfaches Objekt mit Schlüssel-Wert-Paaren. Drei Bausteine solltest du kennen. Der @context verweist auf das Vokabular, praktisch immer https://schema.org. Der @type bestimmt, um was für ein Ding es sich handelt, etwa Organization oder Article. Und die Eigenschaften beschreiben das Ding, zum Beispiel name, url oder address.
Ein minimales Beispiel für ein Unternehmen sieht so aus:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Beispiel GmbH",
"url": "https://www.beispiel.de/",
"logo": "https://www.beispiel.de/logo.png"
}
Zwei weitere Konzepte machen JSON-LD mächtig. Mit @id gibst du einem Ding eine eindeutige Kennung (meist eine URL mit Anker), sodass du es an anderer Stelle wiederverwenden kannst, ohne es doppelt zu beschreiben. Und mit @graph kannst du mehrere Dinge in einem Block bündeln und über ihre @id miteinander verknüpfen. Genau diese Verknüpfung ist der Schlüssel zu einem sauberen Wissensgraphen, auf den wir später zurückkommen.
Die wichtigsten Schema-Typen im Überblick
schema.org kennt Tausende Typen, aber für die meisten Websites zählen nur eine Handvoll. Diese solltest du kennen und je nach Seite gezielt einsetzen.
Die goldene Regel: Nutze pro Seite den Typ, der zum Inhalt passt, und zeichne nur aus, was auf der Seite auch sichtbar ist. Ein Blogartikel bekommt Article oder BlogPosting, eine Über-uns-Seite AboutPage, eine Produktseite Product. Die globalen Entitäten wie das Unternehmen selbst werden einmal definiert und überall nur referenziert. Wir gehen die wichtigsten Typen nun genauer durch.
Organization und Person: das Fundament
Der wichtigste Typ ist die Organization (oder bei lokalen Anbietern LocalBusiness). Sie beschreibt dein Unternehmen als Entität: Name, Logo, Adresse, Kontaktdaten, Profile in sozialen Netzwerken und, besonders wertvoll, die Verknüpfung zu offiziellen externen Quellen über die Eigenschaft sameAs. Diese Auszeichnung ist die Grundlage dafür, dass Google und KI-Systeme dein Unternehmen als klar definierte Entität erkennen und in ihren Knowledge Graph aufnehmen.
Ebenso wichtig ist der Typ Person für die Autoren deiner Inhalte. Wer einen Artikel geschrieben hat, ist ein starkes E-E-A-T-Signal, also ein Hinweis auf Erfahrung, Expertise und Vertrauenswürdigkeit. Zeichne deine Autoren als Person-Entität aus, verknüpfe sie mit ihren Profilen und ordne sie über worksFor der Organisation zu. So entsteht ein glaubwürdiges Bild, wer hinter den Inhalten steht, was für Suchmaschinen und KI-Systemen gleichermaßen zählt.
Wir prüfen deine strukturierten Daten auf Fehler, Lücken und Dubletten, bauen einen konsistenten Entitäten-Graphen und sorgen dafür, dass deine Rich Results und deine KI-Sichtbarkeit auf einem sauberen Fundament stehen.
Article, BlogPosting und FAQPage
Für Inhaltsseiten sind zwei Typen zentral. Article beziehungsweise BlogPosting beschreibt einen redaktionellen Beitrag mit Überschrift, Autor, Veröffentlichungs- und Änderungsdatum sowie einem Beitragsbild. Diese Angaben helfen Google, den Artikel korrekt einzuordnen, und können in der Suche zu angereicherten Darstellungen führen. Wichtig ist, dass Autor und Publisher als verknüpfte Entitäten auftreten, nicht nur als bloße Textnamen.
Der Typ FAQPage zeichnet einen Frage-Antwort-Block aus. Ein Rich Result entsteht daraus nicht mehr: Google hat die Anzeige 2023 auf Behörden- und Gesundheitsseiten beschränkt und am 7. Mai 2026 ganz eingestellt. Sinnvoll bleibt die Auszeichnung trotzdem, weil sie Fragen und Antworten maschinenlesbar zuordnet und damit auf KI-Antworten und die Themenzuordnung einzahlt. Unverändert gilt die strikte Regel von Google: Das Markup muss exakt dem sichtbaren Inhalt der Seite entsprechen. Fragen und Antworten, die nur im Schema stehen, aber nicht auf der Seite, sind ein Verstoß gegen die Richtlinien. Zeichne also nur echte, sichtbare FAQ aus.
Product und LocalBusiness
Für Online-Shops ist Product mit dem verschachtelten Offer der wichtigste Typ. Er beschreibt Preis, Verfügbarkeit und Eigenschaften eines Produkts und ermöglicht Rich Results mit Preis- und Verfügbarkeitsangabe. Wenn echte Kundenbewertungen vorliegen, kann eine aggregateRating Sternebewertungen im Suchergebnis erzeugen. Wichtig und heikel zugleich: Bewertungen müssen echt und auf der Seite sichtbar sein, erfundene Sterne sind ein klarer Richtlinienverstoß mit Abstrafungsrisiko.
Für lokale Anbieter wie Handwerker, Praxen oder Restaurants ist LocalBusiness der Schlüssel. Er ergänzt die Organisation um lokale Angaben: genaue Adresse, Geokoordinaten, Öffnungszeiten und Einzugsgebiet. Diese Auszeichnung unterstützt die lokale Sichtbarkeit und die Darstellung im Kartenbereich der Suche. Für Unternehmen mit mehreren Standorten wird je Standort eine eigene LocalBusiness-Entität sinnvoll, sauber verknüpft mit der übergeordneten Organisation.
Weitere nützliche Typen
Über die Basis hinaus gibt es Typen, die je nach Geschäft viel bringen. Event zeichnet Veranstaltungen mit Datum, Ort und Ticket-Info aus und kann sie in speziellen Event-Ergebnissen anzeigen, ideal für Seminare, Webinare oder Messen. VideoObject beschreibt eingebettete Videos mit Titel, Beschreibung, Vorschaubild und Dauer und hilft, sie in der Video- und Websuche sichtbar zu machen.
HowTo strukturiert Schritt-für-Schritt-Anleitungen, Recipe Rezepte mit Zutaten und Zubereitungszeit, und Review einzelne Rezensionen. Bei JobPosting lassen sich Stellenanzeigen für die Job-Ergebnisse von Google auszeichnen, ein starker Hebel im Recruiting. Wichtig bleibt bei allen die Grundregel: Nutze einen Typ nur, wenn die Seite den passenden Inhalt tatsächlich sichtbar enthält. Nicht jede Website braucht all diese Typen, aber wer den passenden gezielt einsetzt, verschafft sich sichtbare Vorteile im Suchergebnis. Wichtig ist, sich nicht in Vollständigkeit zu verlieren, sondern die Typen zu wählen, die zu den eigenen Inhalten und Zielen passen.
Der @id-Wissensgraph: der taismo-Ansatz
Hier trennt sich solides von exzellentem Schema. Viele Websites streuen isolierte Schnipsel über ihre Seiten: hier ein Organisations-Block, dort ein Artikel, ohne Zusammenhang. Der bessere Weg ist ein zusammenhängender Wissensgraph, in dem alle Entitäten über ihre @id miteinander verbunden sind.
Das Prinzip: Du definierst deine globalen Entitäten (Organisation, Person, Marke, Leistungen) genau einmal, jede mit einer stabilen @id. Auf jeder einzelnen Seite verweist du dann nur noch per @id auf diese Entitäten, statt sie neu zu beschreiben. Ein Blogartikel referenziert so seinen Autor (@id der Person) und seinen Publisher (@id der Organisation), ohne beide zu duplizieren. So entsteht ein konsistenter Graph über die gesamte Domain, in dem jede Entität nur einmal existiert und überall eindeutig identifizierbar ist.
Der Nutzen ist doppelt: Suchmaschinen und KI-Systeme erhalten ein widerspruchsfreies, klar verknüpftes Bild deines Unternehmens, und die Pflege wird einfacher, weil eine Änderung an der zentralen Entität überall wirkt. Genau diesen graphbasierten Ansatz setzen wir bei taismo standardmäßig um, denn er ist der Unterschied zwischen „technisch vorhandenem Schema“ und einem echten Entitäten-Modell, das GEO-Wert schafft.
Ein praktischer Nebeneffekt: Weil die Entitäten über @id verbunden sind, verschmelzen auch die Schema-Blöcke verschiedener Herkunft, etwa der automatisch erzeugte Block eines SEO-Plugins und ein handgepflegter Block, sauber zu einem Knoten, statt sich zu duplizieren. Google folgt diesen @id-Verweisen und setzt die Teile zu einem Gesamtbild zusammen. So lässt sich vorhandenes Schema erweitern, ohne es neu zu bauen, und die Autorität bleibt an einer eindeutigen Stelle gebündelt.
Rich Results: der sichtbare Nutzen
Der unmittelbarste Ertrag strukturierter Daten sind Rich Results, in Deutschland oft auch Rich Snippets genannt: angereicherte Suchergebnisse, die mehr zeigen als den blauen Link. Je nach Typ und Inhalt können das Sternebewertungen, Breadcrumb-Pfade, Preis- und Verfügbarkeitsangaben, Veranstaltungsdaten oder Rezept-Details sein.
Der entscheidende Vorteil: Rich Results verbessern die Klickrate, ohne dass sich deine Position ändert. Ein Ergebnis mit Sternen und FAQ zieht mehr Blicke auf sich als ein nackter Link auf derselben Position. Wichtig zu verstehen ist aber, dass strukturierte Daten Rich Results nur ermöglichen, nicht erzwingen. Google entscheidet je nach Suchanfrage und Qualität, ob und wie es sie ausspielt. Auch Breadcrumb-Auszeichnungen gehören hierher, sie zeigen die Position der Seite in der Hierarchie und ersetzen die nackte URL im Ergebnis durch einen lesbaren Pfad.
Strukturierte Daten für KI-Sichtbarkeit
Der wachsende Nutzen strukturierter Daten liegt jenseits der klassischen Suche. KI-Systeme wie ChatGPT, Perplexity und Googles KI-Antworten müssen verstehen, welche Entitäten es gibt und wie sie zusammenhängen. Ein sauberer Wissensgraph in JSON-LD liefert genau diese Klarheit. Er sagt der Maschine unmissverständlich, wer du bist, was du anbietest und wer bei dir arbeitet, ohne dass sie es aus Fließtext erraten muss.
Das reduziert Verwechslungen, etwa mit Namensvettern, und erhöht die Chance, als klare, korrekt eingeordnete Quelle in KI-Antworten aufzutauchen. Strukturierte Daten sind damit ein zentraler Hebel der Generative Engine Optimization. Sie sind kein Ersatz für gute Inhalte und Autorität, aber sie sind die maschinenlesbare Grundlage, auf der KI-Systeme dein Unternehmen überhaupt erst zuverlässig erfassen können. Wer hier sauber aufgestellt ist, verschafft sich einen Vorsprung, der mit der Verbreitung der KI-Suche immer wertvoller wird.
Konkret hilft eine gepflegte sameAs-Verknüpfung der Organisation und der Personen, dich mit deinen offiziellen Profilen und Verzeichnissen zu verbinden, sodass eine Maschine deine Entität über mehrere Quellen hinweg als dieselbe erkennt. Und ein klarer knowsAbout-Bezug auf deine Fachthemen signalisiert, in welchen Bereichen du Kompetenz hast. Solche Signale sind es, die aus einer bloßen Website eine für Maschinen greifbare, zitierfähige Entität machen.
Wie strukturierte Daten technisch in die Seite kommen
JSON-LD zu verstehen ist das eine, es sauber in die Website zu bringen das andere. In der Praxis gibt es mehrere Wege, und die Wahl hängt vom System und vom Anspruch ab.
Der einfachste Weg für viele Websites führt über das CMS oder ein SEO-Plugin. Systeme wie WordPress mit einem SEO-Plugin erzeugen für Standardfälle automatisch grundlegendes Schema, etwa für Artikel, Breadcrumbs und die Organisation. Das ist ein guter Start, deckt aber selten alles ab und lässt sich nur begrenzt anpassen. Für individuelle oder reichere Auszeichnung ergänzt man den Theme-Code oder ein eigenes Snippet, das den JSON-LD-Block gezielt ausgibt, oder pflegt das Schema über ein spezialisiertes Werkzeug.
Entscheidend ist, dass die einzelnen Blöcke sich nicht widersprechen. Ein häufiges Problem entsteht, wenn das Plugin ein automatisches Schema erzeugt und zusätzlich ein manueller Block dieselbe Entität nochmals, aber anders beschreibt. Der saubere Weg ist, alles über konsistente @id-Referenzen zu einem Graphen zu verbinden, statt konkurrierende Blöcke nebeneinander zu stellen. Genau hier setzt unser Ansatz an: ein zentrales, gepflegtes Entitäten-Modell, das automatische und manuelle Auszeichnung zu einem widerspruchsfreien Ganzen zusammenführt. Wie das mit einer sauberen technischen Basis zusammenspielt, zeigt unser Leitfaden zu technischem SEO.
Strukturierte Daten validieren und testen
Schema ist unsichtbar, deshalb ist Testen Pflicht. Ein kleiner Syntaxfehler kann den gesamten Block unwirksam machen, ohne dass du es auf der Seite merkst. Zwei Werkzeuge gehören in jeden Workflow. Der Rich Results Test von Google zeigt, ob deine Auszeichnung für Rich Results in Frage kommt und welche Fehler oder Warnungen vorliegen. Der Schema Markup Validator prüft die formale Korrektheit gegen das schema.org-Vokabular unabhängig von Google.
Ein wichtiger Unterschied: Fehler machen die Auszeichnung ganz oder teilweise unwirksam und müssen behoben werden. Warnungen weisen auf empfohlene, aber nicht zwingende Angaben hin, sie sind oft kosmetisch. Zusätzlich meldet die Google Search Console, welche strukturierten Datentypen Google auf deiner Website tatsächlich erkannt hat und ob es Probleme gibt, das ist die verlässlichste Quelle für den Live-Zustand. Prüfe nach jeder größeren Änderung, damit ein Fehler nicht unbemerkt deine Rich Results kostet.
Häufige Fehler bei strukturierten Daten
Einige Fehler tauchen immer wieder auf. Der erste und schwerste: Markup, das nicht dem sichtbaren Inhalt entspricht. Bewertungen ohne echte, sichtbare Rezensionen, FAQ, die nur im Schema stehen, oder Preise, die auf der Seite gar nicht auftauchen, verstoßen gegen die Richtlinien und können zu manuellen Maßnahmen führen. Grundregel: Zeichne nur aus, was der Nutzer auch sieht.
Der zweite Fehler sind Dubletten und Widersprüche: dieselbe Entität mehrfach mit unterschiedlichen Angaben, oder mehrere isolierte Blöcke, die sich nicht über @id verbinden. Das verwirrt Maschinen, statt ihnen zu helfen. Der dritte ist der Vollständigkeitswahn: nicht jeder mögliche Typ gehört auf jede Seite. Zu viel, schlecht gepflegtes Schema schadet mehr, als es nützt. Und der vierte: vergessene Pflege nach einem Relaunch oder CMS-Wechsel, bei dem die Auszeichnung stillschweigend verschwindet. Ein sauberer Wissensgraph ist wartungsärmer, aber auch er will nach großen Änderungen geprüft sein.
Lohnt sich der Aufwand mit strukturierten Daten?
Strukturierte Daten sauber aufzubauen kostet Zeit, deshalb die berechtigte Frage: Rechnet sich das? Für die meisten Websites lautet die Antwort klar ja, aus drei Gründen. Erstens ist der Grundaufwand einmalig: Ist der Wissensgraph mit Organisation, Personen und Leistungen einmal sauber angelegt, referenzieren neue Seiten diese Entitäten nur noch, statt sie neu zu bauen. Der laufende Aufwand pro Seite ist danach gering.
Zweitens ist der Ertrag konkret: Rich Results erhöhen die Klickrate auf bestehende Positionen, ohne dass du im Ranking klettern musst, und eine höhere Klickrate bedeutet mehr Besucher bei gleichem Aufwand. Drittens, und langfristig am wichtigsten: Der Wert strukturierter Daten für die KI-Sichtbarkeit wächst mit jedem Monat, in dem mehr Menschen ihre Fragen KI-Systemen stellen. Wer heute ein sauberes Entitäten-Modell hat, ist auf diese Entwicklung vorbereitet, während andere erst nachziehen müssen.
Wichtig ist die richtige Priorisierung: Fang mit dem Fundament an (Organisation, Autoren, die wichtigsten Seitentypen) und baue von dort aus, statt dich in seltenen Spezialtypen zu verlieren. So kommt der größte Nutzen mit dem geringsten Aufwand zuerst. Genau diese Priorisierung, die stärksten Hebel zuerst, ist der Kern unserer Arbeitsweise.
Die Schema-Praxis-Checkliste
@id, statt Schema-Schnipsel zu streuen.- Format: JSON-LD verwenden, nicht Microdata oder RDFa.
- Fundament: Organisation (oder LocalBusiness) und Autoren als Person-Entitäten auszeichnen, inklusive
sameAs. - Seitenindividuell: je Seite den passenden Typ (Article, Product, FAQPage …), nur was sichtbar ist.
- Graph: globale Entitäten einmal definieren, überall per
@idreferenzieren, keine Dubletten. - FAQ & Bewertungen: nur echten, sichtbaren Inhalt markieren.
- Validieren: Rich Results Test und Schema Validator nach jeder Änderung.
- Überwachen: Search Console auf erkannte Typen und Fehler prüfen.
- Pflegen: nach Relaunch oder CMS-Wechsel die Auszeichnung erneut kontrollieren.
Wir bauen für dich einen sauberen, graphbasierten Wissensgraphen in JSON-LD, der Rich Results ermöglicht und dein Unternehmen für KI-Systeme klar erfassbar macht. Vom Audit bis zur laufenden Pflege.
Häufige Fragen zu Schema.org und JSON-LD
Was ist der Unterschied zwischen Schema.org und JSON-LD?
Schema.org ist das Vokabular, also die Sammlung an Typen und Eigenschaften, mit denen sich Dinge beschreiben lassen. JSON-LD ist das Format, in dem diese Beschreibung technisch in die Seite geschrieben wird. Kurz: Schema.org ist die Sprache, JSON-LD die Schreibweise. Google empfiehlt JSON-LD.
Bringen strukturierte Daten bessere Rankings?
Strukturierte Daten sind kein direkter Rankingfaktor, aber sie ermöglichen Rich Results, die die Klickrate erhöhen, und sie helfen Suchmaschinen und KI-Systemen, deine Inhalte korrekt zu verstehen und einzuordnen. Beides wirkt sich indirekt positiv auf die Sichtbarkeit aus.
Welche strukturierten Daten braucht meine Website?
Das hängt vom Seitentyp ab. Fast jede Website profitiert von einer Organization- oder LocalBusiness-Auszeichnung und Person-Entitäten für Autoren. Dazu kommen seitenindividuelle Typen wie Article für Blogbeiträge, Product für Shops oder FAQPage für Frage-Antwort-Bereiche.
Darf ich FAQ auszeichnen, die nicht auf der Seite stehen?
Nein. Google verlangt, dass FAQ-Markup exakt dem sichtbaren Inhalt der Seite entspricht. Fragen und Antworten, die nur im Schema stehen, aber nicht auf der Seite, verstoßen gegen die Richtlinien und können zu einer Abstrafung führen. Zeichne nur echte, sichtbare Inhalte aus.
Wie prüfe ich, ob mein Schema funktioniert?
Nutze den Rich Results Test von Google und den Schema Markup Validator, um Fehler und Warnungen zu finden, und beobachte in der Google Search Console, welche Typen tatsächlich erkannt werden. Prüfe nach jeder größeren Änderung, denn ein kleiner Syntaxfehler kann den ganzen Block unwirksam machen.
Brauche ich für Schema ein Plugin oder Programmierung?
Für Standardfälle reicht oft ein SEO-Plugin, das grundlegendes Schema automatisch erzeugt. Für individuelle, reichere oder graphbasierte Auszeichnung ist ergänzender Code oder ein spezialisiertes Werkzeug sinnvoll. Wichtig ist, dass automatische und manuelle Blöcke sich nicht widersprechen, sondern über @id zu einem Graphen verbunden sind.
Wie viele Schema-Typen sollte eine Seite haben?
So viele wie nötig, so wenige wie möglich. Nutze je Seite die Typen, die zum sichtbaren Inhalt passen, plus die per @id referenzierten globalen Entitäten. Zu viel schlecht gepflegtes Schema schadet mehr, als es nützt. Qualität und Konsistenz sind wichtiger als die reine Menge.
Erzeugen strukturierte Daten garantiert Rich Results?
Nein. Strukturierte Daten sind die Voraussetzung, aber keine Garantie. Google entscheidet je nach Suchanfrage, Qualität und Richtlinien, ob und wie es Rich Results ausspielt. Deine Aufgabe ist, die Auszeichnung korrekt, vollständig und regelkonform zu halten, die Darstellung selbst liegt bei der Suchmaschine.
Quellen
- Google Search Central: „Einführung in strukturierte Daten„, Google, 2026.
- schema.org: „Getting started with schema.org using Microdata„, Schema.org Community Group, 2026.
- Google Search Central: „FAQPage: Richtlinien für strukturierte Daten„, Google, 2026.
