Schema und strukturierte Daten für die KI-Suche: echter Nutzen, Mythen und Tests

Kurzantwort

Strukturierte Daten helfen Maschinen, eine Seite, ihre Entitäten und bestimmte Eigenschaften explizit zu identifizieren. Sie können eine Seite für unterstützte Suchfunktionen berechtigt machen. Sie garantieren weder Ranking noch Rich Snippet noch eine Zitation in einer KI-Antwort. Google erklärt, dass für AI Overviews oder AI Mode kein spezielles Schema.org-Markup und keine „KI"-Datei nötig ist; SEO-Grundlagen und die Übereinstimmung zwischen Markup und sichtbarem Inhalt bleiben entscheidend.

Wähle den Typ, der das Hauptobjekt tatsächlich beschreibt: Article für einen Artikel, DefinedTermSet für ein Glossar, Course für eine Ausbildung und SoftwareApplication nur für die Seite einer tatsächlichen Software. Füge FAQPage, HowTo oder Bewertungen nicht nur hinzu, um mehr SERP-Fläche zu besetzen. Veröffentliche zuerst die sichtbaren Informationen, kodiere sie danach in JSON-LD, validiere Syntax und Regeln der Suchmaschine, prüfe das gerenderte HTML und überwache anschließend Fehler nach der Bereitstellung. Ein kurzer, korrekter, gepflegter Graph ist besser als ein riesiger generierter Block, der der Seite widerspricht.

Das Wichtigste in Kürze

• Schema.org liefert ein Vokabular; jede Suchmaschine entscheidet, welche Funktionen sie unterstützt.
• Gültiges JSON-LD kann trotzdem nicht berechtigt, nutzlos oder irreführend sein.
• Das Markup muss den sichtbaren Inhalt widerspiegeln und stabile Identifikatoren verwenden.
• Es gibt kein von Google garantiertes Schema für „GEO", „AEO", „LLMO" oder „AI Overview".
• Teste Syntax, Parität, Relevanz, Richtlinienkonformität, Rendering und Überwachung, nicht nur das grüne Licht eines Validators.

Die fünf Ebenen, die man nicht verwechseln sollte

1. JSON-LD ist eine Syntax. Sie erlaubt es, verknüpfte Daten in einem Skript auszudrücken. Microdata und RDFa sind andere mögliche Syntaxen.
2. Schema.org ist ein Vokabular. Es definiert Typen und Eigenschaften wie Article, Person, Course oder dateModified.
3. Eine Suchmaschinenfunktion ist ein Produkt. Google, Bing oder eine andere Plattform wählt Typen aus, fügt erforderliche Eigenschaften hinzu und wendet ihre Richtlinien an.
4. Die sichtbare Seite ist der Beleg. Das Markup darf keinen Autor, Preis, keine Bewertung, Verfügbarkeit, Frage oder Schritt erfinden, die für die Person nicht vorhanden sind.
5. Beobachtung ist ein Prozess. Validierung, Indexierung, Berechtigung und Anzeige sind unterschiedliche, sich entwickelnde Ereignisse.

Der Einführungsleitfaden von Google erklärt, dass strukturierte Daten explizite Hinweise auf die Bedeutung einer Seite liefern und Rich Results ermöglichen können. Google weist auch darauf hin, dass korrekte Verwendung die Anzeige nicht garantiert. Diese Einschränkung sollte in jedem Business Case erscheinen.

Welcher Typ für welche Seite?

Ein Typ kann in Schema.org gültig sein, ohne eine Google-Galerie zu erzeugen. DefinedTermSet, Course und LearningResource bleiben nützlich, um eine Struktur auszudrücken oder anderen Datenkonsumenten das Verständnis zu ermöglichen. Stelle diesen semantischen Nutzen nicht als Anzeigeversprechen dar.

Der Relevanztest in einem Satz

Vervollständige, bevor du Code schreibst:

Diese Seite ist hauptsächlich [Entität]; eine Person kann [Eigenschaften] im sichtbaren Inhalt überprüfen; das Markup hilft einer Maschine, [Beziehungen] zu verknüpfen, ohne eine neue Tatsache hinzuzufügen.

Braucht der Satz mehrere „und auch", wähle eine Hauptentität und verknüpfe die sekundären Objekte in einem @graph. Kannst du nicht zeigen, wo eine Eigenschaft auf der Seite erscheint, veröffentliche sie nicht.

Zehnstufiges Bereitstellungsverfahren

1. Die Vorlagen inventarisieren

Liste Seitentypen, eine Beispiel-URL, Volumen, verfügbare Daten, Verantwortlichen und Aktualisierungsfrequenz auf. Beginne nicht damit, einen Block auf die ganze Website zu kopieren. Ein Fehler in einer Vorlage kann Tausende URLs betreffen.

2. Die Hauptentität definieren

Entscheide, ob die Seite ein Artikel, eine Sammlung, ein Begriff, ein Kurs oder ein Produkt ist. Der Marketingtitel der Vorlage ist nicht immer das echte Objekt. Eine Seite „beste Tools" ist ein Vergleichsartikel, keine zehn SoftwareApplication-Entitäten im Besitz des Herausgebers.

3. Das aktuelle Vokabular auswählen

Prüfe die veröffentlichte Version von Schema.org und die Dokumentation der Ziel-Suchmaschine. Vermeide eine Eigenschaft, die in einem alten Beispiel gefunden wurde, ohne ihren Status zu prüfen. Notiere das Abrufdatum im technischen Register.

4. Quelle und Eigenschaft zuordnen

Notiere für jede Eigenschaft das CMS-Feld oder das sichtbare Element, das sie liefert, ihr Format, ihre Validierung und ihren Verantwortlichen. dateModified muss von einer echten redaktionellen Änderung stammen, nicht vom Zeitpunkt des Builds.

5. Stabile Identifikatoren erstellen

Verwende absolute, konsistente @ids für die Organisation, die Website, die Autoren und das Seitenobjekt. Verknüpfe author, publisher, isPartOf und mainEntity mit diesen Identifikatoren, sofern die Entität existiert. Erstelle nicht bei jeder URL eine neue Organisation.

6. Das JSON-LD serverseitig generieren

Escape Werte korrekt und verwende dieselben Daten wie das HTML. In einer Multi-Tenant-Anwendung darf kein Tenant-Datensatz den Graphen eines anderen Tenants füllen können. Teste leere Eingaben, Anführungszeichen, Unicode, sehr lange Beschreibungen und gelöschte Inhalte.

7. Syntax und Regeln validieren

Der Schema Markup Validator prüft das allgemeine Vokabular. Der Rich Results Test von Google prüft die von Google unterstützten Funktionen. Ein Tool ersetzt das andere nicht. Protokolliere Fehler, Warnungen, getestete URL und Datum.

8. Die sichtbare Parität prüfen

Öffne jede sensible Eigenschaft: Autor, Preis, Bewertung, Verfügbarkeit, Frage und Schritt. Dieselbe Information muss für die Person zugänglich sein. Prüfe auch Canonical, HTTP-Status, Indexierbarkeit und sprachliche Konsistenz.

9. Schrittweise bereitstellen

Beginne mit einigen repräsentativen URLs, vergleiche das erzeugte HTML und beobachte die Berichte. Bewahre einen Rollback pro Vorlage auf. Stelle keine globale Generierung bereit, wenn der Unit-Test nur eine ideale Seite abgedeckt hat.

10. Auf Abweichungen überwachen

Erkenne ungültiges JSON, leere Eigenschaften, doppelte Identifikatoren, inkonsistente Daten und Unterschiede zwischen HTML und JSON-LD. Validiere nach jeder Änderung von CMS, Vorlage, Übersetzung, Vokabular oder Suchmaschinen-Richtlinie neu.

Durchgerechnetes Beispiel: der minimale Graph eines Glossars

Dieses Beispiel zeigt einen Hub mit zwei sichtbaren Definitionen. URLs und Texte müssen mit der tatsächlich veröffentlichten Seite übereinstimmen. Organisation, Website und Breadcrumb können vom globalen Chrome gerendert werden und werden hier nicht dupliziert.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "CollectionPage",
      "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#page",
      "url": "https://www.seoryon.com/de/glossaire-seo-ia/",
      "name": "SEO-, GEO- und KI-Suche-Glossar",
      "mainEntity": {
        "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#terms"
      }
    },
    {
      "@type": "DefinedTermSet",
      "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#terms",
      "name": "SEO-, GEO- und KI-Suche-Glossar",
      "hasDefinedTerm": [
        {
          "@type": "DefinedTerm",
          "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#geo",
          "name": "GEO",
          "description": "Optimierung der Auffindbarkeit und Zitierfähigkeit von Inhalten in generativen Antworten.",
          "inDefinedTermSet": {
            "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#terms"
          }
        },
        {
          "@type": "DefinedTerm",
          "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#ki-zitation",
          "name": "KI-Zitation",
          "description": "Eine URL oder Domain, die explizit als Quelle in einer beobachteten generativen Antwort angezeigt wird.",
          "inDefinedTermSet": {
            "@id": "https://www.seoryon.com/de/glossaire-seo-ia/#terms"
          }
        }
      ]
    }
  ]
}

Der Typ DefinedTermSet erlaubt es, Begriffe zu gruppieren. Das Beispiel ist bewusst kurz: Auf der Live-Website kann der Generator die vollständigen 45 sichtbaren Definitionen einbeziehen, sofern Anker, Beschreibungen und Identifikatoren synchron bleiben. Kopiere diesen Code nicht, wenn Begriffe oder URLs abweichen.

Das SEOryon-Freigabetor

Verwende für jede Vorlage eine binäre Entscheidung:

Bereit zur Bereitstellung =
  gültige Syntax
  UND Parität mit dem sichtbaren Inhalt
  UND für das Hauptobjekt relevanter Typ
  UND eingehaltene Suchmaschinen-Richtlinien
  UND stabile Identifikatoren
  UND aktive Überwachung und Rollback

Das ist kein Google-Score. Eine einzige falsche Bedingung blockiert die Bereitstellung. Um Vorlagen gegeneinander zu priorisieren, ergänze URL-Volumen × potenzielle Wirkung × Fehlerwahrscheinlichkeit, verwandle diese Priorität aber nicht in eine vermeintliche Rich-Result-Wahrscheinlichkeit.

Was die Daten und die Dokumentation belegen und was nicht

Googles allgemeine Richtlinien verlangen unter anderem eine wahrheitsgetreue, sichtbare Darstellung, Relevanz und die Einhaltung der Content-Richtlinien. Sie erklären auch, dass korrektes Markup keine Funktion garantiert. Sie belegen die von Google zum Zeitpunkt der Abfrage erklärten Bedingungen, nicht die kausale Wirkung eines Typs auf das Ranking.

In seinem am 10. Juli 2026 aktualisierten Leitfaden erklärt Google, dass für seine KI-Funktionen dieselben Grundlagen gelten, dass strukturierte Daten dem sichtbaren Text entsprechen müssen und dass keine neuen speziellen strukturierten Daten oder maschinenlesbaren Dateien erforderlich sind (Leitfaden zur Optimierung für KI-Funktionen). Diese Position betrifft die Google-Suche; sie beschreibt nicht jede LLM-Anwendung oder deren Pipeline.

Schema.org veröffentlicht ein Community-Vokabular. Das Vorhandensein eines Typs in diesem Vokabular belegt, dass er ausgedrückt werden kann, nicht dass eine Suchmaschine ihn für eine Funktion nutzt. Course und LearningResource bieten beispielsweise nützliche Eigenschaften für eine Akademie, aber die Bereitstellung muss dennoch zum Inhalt, den vorgesehenen Konsumenten und den aktuellen Regeln passen.

Um eine Wirkung zu messen, vergleiche Vorlagen und Zeiträume, während du den Rest so stabil wie möglich hältst. Verfolge Fehler, Berechtigung, Impressionen und Klicks der Funktion, wenn der Bericht existiert. Ein gleichzeitiger Anstieg nach dem Markup bleibt korrelativ, wenn sich auch Inhalt, interne Verlinkung oder Nachfrage geändert haben.

Neun Mythen, die man ablegen sollte

Fehler, Grenzfälle und Abbruchkriterien

• Ein Softwarepreis ändert sich, aber offers.price bleibt veraltet.
• Eine übersetzte Seite behält inLanguage, Name oder Beschreibung der Ausgangssprache bei.
• Das CMS entfernt eine sichtbare FAQ, aber das JSON-LD behält sie.
• Zwei verschiedene Autoren teilen sich dieselbe @id.
• Jeder Artikel erzeugt eine Organization mit unterschiedlichem Logo oder unterschiedlicher URL neu.
• Eine Vergleichsseite markiert Software von Drittanbietern, als wäre der Herausgeber deren Anbieter.
• Eine aggregierte Bewertung vermischt interne Bewertungen, Testimonials und erfundene Zahlen.
• Eine Seite mit noindex, Weiterleitung oder Canonical auf eine andere URL bleibt im Überwachungslos.
• Ein clientseitiges Rendering schlägt fehl, und das Skript erscheint nicht im HTML, das Tools erhalten.
• Eine Multi-Tenant-Variable injiziert Name, Angebot oder Autor eines anderen Kunden.

Brich die Bereitstellung ab bei einer unsichtbaren Tatsache, einer ungeprüften sensiblen Eigenschaft, einem Leck zwischen Tenants, einem instabilen Identifikator oder einem unmöglichen Rollback. Entferne eine unsichere Eigenschaft, statt zu hoffen, dass die Suchmaschine sie ignoriert.

Wiederverwendbares Asset: Audit-Register für strukturierte Daten

Erstelle für jede Vorlage eine Zeile mit template_id, Beispiel_URL, Hauptentität, Typen, Eigenschaft, CMS_Quelle, sichtbarer_Selektor, interne_Anforderung, Validator, Status, Verantwortlich, Prüfdatum, Rollback und Beleg. Verknüpfe jede Ergebnisaussage mit der Datei assets/registre-preuves.csv.

Ergänze automatisierte Tests: parsebares JSON, absolute URLs, eindeutige @id, konsistente Canonical, nicht leere interne Pflichtfelder und keine Identifikatoren eines anderen Tenants. Vervollständige mit einer menschlichen Stichprobe, da ein Formtest den Wahrheitsgehalt nicht beurteilen kann.

Wie es weitergeht

• Kehre zum SEO-, GEO- und KI-Suche-Glossar zurück, um Vokabular, Standard und Plattform-Kennzahl zu unterscheiden.
• Ordne das Markup in die Unterschiede zwischen SEO, GEO und AEO ein.
• Verstehe, warum eine Antwort mehrere Blickwinkel erkunden kann, mit dem Leitfaden zum Query Fan-out.
• Teste die Grenzen des Markups anhand der Daten zu KI-Zitationen und klassischen Rankings.

So bringt sich SEOryon ein

SEOryon-Seiten können dieses Modell anwenden, um ihr Objekt und ihre Beziehungen explizit zu machen, ohne zu behaupten, dass Markup eine Zitation verursacht. Jede zugehörige Audit- oder Generierungsfunktion muss anhand des echten HTML, der versionierten Regeln, der sichtbaren Parität, der Datenisolation und der Exportmöglichkeit beurteilt werden. SEOryon unterliegt denselben Richtlinien wie andere Herausgeber.

Messbare Übung: eine Vorlage in Produktion prüfen

1. Wähle zehn URLs derselben Vorlage aus: normal, leer, übersetzt, aktualisiert und fehlerhaft.
2. Extrahiere HTML, Canonical und JSON-LD aus jeder.
3. Validiere mit Schema Markup Validator und, falls der Typ unterstützt wird, mit Rich Results Test.
4. Vergleiche jede sensible Eigenschaft mit dem sichtbaren Inhalt und dem CMS-Feld.
5. Prüfe @id, Sprache, Daten, URLs, HTTP-Status und Tenant-Isolation.
6. Simuliere eine Löschung und führe den Rollback aus.

Ergebnis: eine Matrix von 10 URLs, die Validierungsbelege und die Torentscheidung. Erfolgskriterium: null ungültiges JSON, null unsichtbare Tatsache, null Entitätsleck, 100 % der Anomalien zugewiesen und Rollback geprüft, bevor auf den Rest der Website ausgeweitet wird.

FAQ

Ist JSON-LD besser als Microdata?

Google empfiehlt in der Regel JSON-LD, weil es getrennt vom HTML-Markup einfacher zu pflegen ist. Microdata und RDFa können gültig sein. Datenkonsistenz und das endgültige Rendering zählen mehr als eine ideologische Syntaxwahl.

Welches Schema sollte man für eine Glossarseite verwenden?

DefinedTermSet für die Menge und DefinedTerm für jede Definition sind geeignet, oft verknüpft mit einer CollectionPage. Begriffe und Beschreibungen müssen sichtbar und ihre Identifikatoren stabil sein.

Muss man jedem Artikel FAQPage hinzufügen?

Nein. Verwende es nur, wenn die Seite tatsächlich eine Reihe von Fragen und Antworten präsentiert und die geltenden Richtlinien eingehalten werden. Ein nur für das Markup hinzugefügter Block verbessert nicht die Substanz.

Helfen strukturierte Daten ChatGPT oder Perplexity?

Diese Anwendungen können das Web über unterschiedliche Pipelines nutzen und veröffentlichen nicht alle eine identische Unterstützung. Exaktes Markup verbessert die maschinelle Lesbarkeit, garantiert aber weder Abruf noch Zitation ohne einen oberflächenspezifischen Test.

Wie erkennt man, ob das Markup eine Wirkung hatte?

Verfolge Fehler, gültige URLs, Berechtigung und Funktions-Impressionen in verfügbaren Tools, mit einem Bereitstellungsdatum und einer vergleichbaren Gruppe. Beschreibe konkurrierende Änderungen und vermeide einen kausalen Schluss aus einer einfachen Vorher-Nachher-Entwicklung.

Quellen

1. Google Search Central: Introduction to structured data2. Google Search Central: General structured data guidelines3. Google Search Central: AI features optimization guide4. Schema.org: Latest release5. Schema.org: DefinedTermSet6. Schema.org: Course7. Schema.org: LearningResource8. Schema Markup Validator

Methoden- und Aktualisierungshinweis

Seite überprüft am 22. Juli 2026, übersetzt und redigiert nach dem französischen Original (überprüft am 16. Juli 2026), basierend auf Googles Richtlinien und dem Schema.org-Vokabular. Die Beispiele beschreiben einen technischen Vertrag, kein Anzeigeversprechen. Prüfe Typen, Eigenschaften und Funktionen vor jeder Bereitstellung und mindestens vierteljährlich; führe die Tests nach jeder Änderung von CMS, Rendering, Locale, Suchmaschinen-Richtlinie oder Schema.org-Version erneut aus.