Ich habe mich lange Zeit mit der Frage beschäftigt, wie strukturierte Daten in Form von Schemata effektiv für die Generative Engine Optimization (GEO) genutzt werden können, und in diesem Artikel möchte ich meine neuesten Erkenntnisse teilen.
In der Vergangenheit habe ich oft Skepsis hinsichtlich der Wirksamkeit strukturierter Daten bei der generativen Suchmaschinenoptimierung geäußert.
Ich möchte diese Ansicht etwas relativieren und einen differenzierteren Ansatz verfolgen.
In diesem Artikel werde ich mich in erster Linie auf die Auswirkungen von Schema-Markup auf GEO konzentrieren. Ich stelle die Notwendigkeit strukturierter Daten und Formate wie Tabellen, semantischem HTML, Überschriften und Textabschnitten für GEO nicht in Frage.
LLMs verarbeiten Schema anders als Suchmaschinen
Sprachmodelle „nutzen“ Schema.org-Markups nicht auf dieselbe Weise wie Google Rich Results, doch Schema-Markups unterstützen sie indirekt durch eine verbesserte Struktur, Abrufbarkeit und KI-Suchsysteme.
Schema-Markup wird von LLMs auch nicht auf dieselbe Weise verwendet, wie es zum Aufbau semantischer Wissensdatenbanken wie Wissensgraphen genutzt wird.
LLMs funktionieren anders als Suchmaschinen und Wissensgraphen, da sie Text, Bilder und andere Inhalte für das Encoding (Lernen) und Decoding (Ausgabe) tokenisieren.
Während des Encoding werden beispielsweise sowohl Text als auch Schema-Markup in Token zerlegt, und während der Dekodierung werden die Token auf der Grundlage von Wahrscheinlichkeiten aneinandergereiht. Die ursprüngliche semantische Bedeutung des Markups geht dabei verloren.
Schema, beispielsweise in Form von JSON-LD, kann daher von LLMs nicht auf dieselbe Weise interpretiert werden wie von anderen Maschinen.
Wie Sprachmodelle mit Schema.org umgehen
In Trainingsdaten werden Schema.org-Tags (JSON-LD, RDFa, Microdata) in der Regel wie normaler Text tokenisiert, ohne dass das Modell eine explizite Sonderbehandlung für @context, @type usw. erkennt.
Token wie @type, itemprop oder schema.org sind für das Rohmodell lediglich Zeichenfolgen; die ursprüngliche semantische Struktur (z. B. Eigenschaftsbeziehungen) „löst sich“ während des Trainings auf.
Untersuchungen zeigen: Obwohl LLMs überraschend gute Schema.org-Markups generieren können, sind ohne zusätzliche Validierung 40–50 % der Annotationen syntaktisch oder semantisch falsch.
Ein LLM betrachtet Ihren JSON-LD-Block nicht als „machine: this is a Product with price“, sondern als ein Muster von Tokens, aus dem es statistisch weiteren Text generiert.
Markups als Labels für maschinelles Lernen in der Verarbeitung natürlicher Sprache
Darüber hinaus nutzen Suchmaschinen und KI-Systeme schema-markierte Informationen und Daten, um Algorithmen für maschinelles Lernen zu trainieren, die dann für die Verarbeitung natürlicher Sprache eingesetzt werden können.
Die Verarbeitung natürlicher Sprache bildet heute die Grundlage für alle KI-Systeme und Sprachmodelle und ermöglicht ein besseres Verständnis (NLU) sowie die Generierung (NLG) natürlicher Sprache.
Die Markups dienen als Labels für maschinelles Lernen.
Auf der Grundlage der strukturierten Daten lernen maschinelle Lernsysteme, Muster zu erkennen. Durch diese Mustererkennung lassen sich Entitätsklassen, Entitäten, ihre Attribute und die Bedeutung unstrukturierter Inhalte besser verstehen.
Hier ein Beispiel:
Dank FAQ-Markups konnten Suchmaschinen lernen, wie man Fragen beantwortet. Diese neu erworbene Fähigkeit dient nun als wichtige Grundlage für AIOverviews, AIMode, Gemini…
Ein weiteres Beispiel:
Früher empfahl Google E-Commerce-Unternehmen, Schema-Markups zu ihren Shopping-Feeds hinzuzufügen. Einige Jahre später gab Google bekannt, dass diese Markups nicht mehr notwendig seien. Durch diese Tagging-Maßnahmen lernte Google, wie Muster von Attribut-Wert-Paaren für Produkte aussehen, sodass es diese heute sogar in unstrukturierten Inhalten identifizieren kann.
Auswirkungen von Schemas während des Trainings und der Tokenisierung
- Während des Pre-Trainings werden HTML und JSON-LD in der Regel in ihrer „Rohform“ in den Korpus eingespeist; das heißt, der Tokenizer zerlegt Tags, Klammern und Eigenschaftsnamen („@type“, „name“, „price“) lediglich in Token, ohne dabei spezifische Semantik für Schema.org einzubetten.
- Infolgedessen lernt das Modell statistische Muster wie „ein Produktname folgt oft auf ‚name‘“, jedoch nicht die Ontologie im Sinne eines Graphen; die Schema-Struktur wird nicht explizit als Graph dargestellt, sondern ist in die Gewichte „eingebacken“.
- Aus Token-Perspektive ist JSON-LD eher ineffizient (viele Klammern, Anführungszeichen), was die Anzahl der Token erhöht, aber nicht automatisch zu einer stärkeren semantischen Unterscheidung führt.
Bei der Dekodierung in der Antwort-Generierung (ohne RAG) „kennt“ das Modell daher nur statistische Muster aus dem Markup, nicht Ihre spezifische Seite oder deren aktuelle Fakten.
Die indirekten Auswirkungen von Schema auf GEO
Suchmaschinen nutzen Schema.org, um Inhalte besser zu verstehen, Rich Results anzuzeigen und Daten in Wissensgraphen oder internen Indizes zu speichern.
Es ist davon auszugehen, dass KI-Systeme, die Graph RAG verwenden, ebenfalls auf semantische Datenbanken wie Knowledge Graphen oder Shopping-Graphen zurückgreifen, sofern sie Zugriff auf solche externen Quellen haben.
Da Markup-Sprachen die Erstellung semantischer Graphdatenbanken unterstützen können, können sie somit auch indirekt für GEO von Nutzen sein.
Graph-RAG und strukturierte Daten
In Graph-RAG-Architekturen werden Schema Mark-Ups explizit in einen Graphen umgewandelt, der aus Knoten (Entitäten) und Kanten (Beziehungen) besteht, z. B. „Arzneimittel – Hersteller → Organisation“.
Abfragen werden dann nicht nur auf der Grundlage semantischer Ähnlichkeit, sondern auch anhand relationaler Logik ausgeführt („Welche Arzneimittel des Herstellers X haben die Nebenwirkung Y?“), wobei die Schema-Eigenschaften die Kanten definieren.
Während der Generierung erhält das LLM keine rohen Schema-Blöcke, sondern vorverarbeitete Fakten (z. B. eine Liste von Entitäten und Attributen), oft in natürlicher Sprache oder tabellarischer Form; diese werden dann tokenisiert und bei der Dekodierung verwendet.
Hier spielen Schema Mark Ups eine zentrale Rolle in der Grounding-Schicht, nicht im Tokenizer selbst.
Die Rolle von Schema beim Decoding (Generierung von Antworten)
Während des Decoding sieht das Modell nur Token, die aus der Eingabe (Frage + kontextbezogene Fakten aus RAG/Graph/DB) abgeleitet wurden; es unterscheidet nicht zwischen „dieses Token stammt aus JSON-LD“ und „aus reinem Text“.
Markup beeinflusst die Dekodierung indirekt durch:
- die Bereitstellung präziserer, weniger redundanter Kontext-Token (z. B. saubere Entitäten anstelle von „Rauschen“ aus HTML)
- die Bereitstellung relevanterer Beziehungen (Graph-RAG)
- die Verbesserung der Quellenauswahl während der Abfrage (da strukturierte Daten leichter indexierbar sind).
- In einigen Systemen werden strukturierte Daten sogar nach der Dekodierung verwendet, um Fakten zu verifizieren oder Zahlen zu überschreiben („Answer Grounding“), d. h., das Modell generiert frei, und ein Nachbearbeitungsprozess ersetzt unsichere Teile durch Werte aus einem Schema oder einer Datenbank.
Die „Rolle beim Decoding“ ist somit kontextabhängig: Was man zuvor als strukturierte Daten einspeist, beeinflusst stark, welche Token das Modell bei der Generierung einer Antwort auswählt.
Fazit
- Bei LLM-Antworten wie ChatGPT ist Schema.org zwar kein direkter „Lesekanal“ für das Modell, erhöht aber durch eine bessere Struktur und KI-gestützte Abfrage die Chancen, zitiert zu werden.
- Strategisch würde ich Schema.org als einen „Hygienefaktor“ für Suchmaschinen und als nützlichen, indirekten Hebel für die GEO/KI-Suche betrachten, nicht als eigenständigen „LLM-Hebel“.
- Der Einfluss erfolgt in erster Linie über Indizierungs-/Wissensgraph-/Abruf-Ebenen (Google AI Overviews, Perplexity, ChatGPT Search usw.), nicht durch ein direktes „Lesen“ des Markups.
Loading...
