Structured Data für LLMO: JSON-LD richtig einsetzen

Kurzantwort: Strukturierte Daten helfen Suchmaschinen, Seitentypen und Entitäten explizit zuzuordnen. Für LLMO sind sie vor allem dann wertvoll, wenn Organization, Personen, Leistungen, Artikel und Breadcrumbs konsistent miteinander verbunden sind. Es gibt jedoch kein spezielles „LLM-Schema“ und keine Garantie auf Rich Results oder KI-Zitationen. Das Markup muss den sichtbaren Inhalt wahrheitsgemäß beschreiben.

Die wichtigste Aufgabe von JSON-LD ist nicht, möglichst viele Schema.org-Typen unterzubringen. Es soll Mehrdeutigkeit reduzieren: Welche Organisation veröffentlicht den Artikel? Welche Person ist Autor? Welche Leistung beschreibt die Seite? Welche URL ist die kanonische Identität eines Objekts?

Google erklärt im Leitfaden zu AI-Funktionen und Websites, dass für AI Overviews und AI Mode keine zusätzlichen technischen Anforderungen und kein spezielles Schema erforderlich sind. Die klassischen SEO-Grundlagen bleiben relevant; strukturierte Daten sollen mit dem sichtbaren Text übereinstimmen.

Was strukturierte Daten leisten – und was nicht

Aufgabe	Sinnvoller Einsatz	Grenze
Seitentyp beschreiben	Article, Product, Service, FAQPage oder anderer passender Typ	ein falscher Typ macht Inhalt nicht relevanter
Entität identifizieren	stabile `@id`, Name, URL, Logo und reale Profile	`sameAs` darf keine bloß ähnlichen Seiten verbinden
Beziehungen ausdrücken	Autor, Publisher, Anbieter, Breadcrumb oder Hauptentität verknüpfen	Markup ersetzt keine sichtbare Erklärung dieser Beziehung
Rich-Result-Berechtigung	erforderliche und empfohlene Properties korrekt auszeichnen	Google garantiert keine besondere Darstellung
LLMO unterstützen	konsistente maschinenlesbare Fakten bereitstellen	keine garantierte Nennung, Citation oder Antwortposition

Google empfiehlt in den allgemeinen Richtlinien für strukturierte Daten, nur aktuelle, relevante und sichtbare Inhalte auszuzeichnen. Versteckte FAQs, erfundene Bewertungen oder ein nicht vorhandener Standort sind kein Optimierungshebel, sondern ein Qualitäts- und Vertrauensrisiko.

JSON-LD, Microdata oder RDFa?

Google unterstützt JSON-LD, Microdata und RDFa. In der Einführung zu strukturierten Daten wird JSON-LD für die meisten Setups empfohlen, weil es sich getrennt vom sichtbaren HTML pflegen und bei verschachtelten Objekten leichter warten lässt.

Für Teams ist die Wartbarkeit entscheidend. Ein korrektes Microdata-Setup ist besser als widersprüchliches JSON-LD. Bei modernen CMS- und Build-Systemen ist JSON-LD dennoch meist die praktikabelste Wahl, weil Entitäten zentral erzeugt, getestet und über stabile IDs referenziert werden können.

Das sinnvolle Entity- und Seitentyp-Modell

Nicht jede URL braucht denselben Graphen. Beginnen Sie mit realen Objekten und ordnen Sie sie den passenden Seiten zu:

Objekt oder Seite	Typischer Schema.org-Typ	Wichtige Verbindungen
Unternehmen oder Marke	`Organization`	`url`, `logo`, `sameAs`, `parentOrganization`, `contactPoint`
Website	`WebSite`	`publisher` zur Organization
einzelne Seite	`WebPage` oder spezifischer Untertyp	`isPartOf`, `about`, `mainEntity`
Ratgeber oder Newsbeitrag	`Article` oder `NewsArticle`	`author`, `publisher`, `datePublished`, `dateModified`
Leistungsseite	`Service`	`provider`, `areaServed`, gegebenenfalls `hasOfferCatalog`
Produktseite	`Product`	reale Angebote, Varianten und Herstellerbeziehung
Navigation	`BreadcrumbList`	sichtbarer Pfad und kanonische URLs
sichtbare Fragenliste	`FAQPage`	exakt dieselben Fragen und Antworten wie im HTML

Schema.org definiert beispielsweise bei Organization Eigenschaften wie legalName, url, logo, contactPoint, parentOrganization, areaServed und sameAs. Verwenden Sie nur Properties, die tatsächlich zutreffen und gepflegt werden können.

Stabile @id statt widersprüchlicher Kopien

Eine @id ist eine stabile, absolute Kennung für ein Objekt. Sie muss keine eigene Seite ausliefern, sollte aber dauerhaft und eindeutig sein. Beispiel:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.beispiel.de/#organization",
      "name": "Beispiel GmbH",
      "url": "https://www.beispiel.de/",
      "logo": "https://www.beispiel.de/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.beispiel.de/#website",
      "url": "https://www.beispiel.de/",
      "publisher": { "@id": "https://www.beispiel.de/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://www.beispiel.de/ratgeber/#article",
      "headline": "Beispiel-Ratgeber",
      "mainEntityOfPage": "https://www.beispiel.de/ratgeber/",
      "publisher": { "@id": "https://www.beispiel.de/#organization" }
    }
  ]
}

Auf weiteren Seiten wird dieselbe Organization-ID referenziert. Erzeugen Sie nicht versehentlich mehrere Organisationen mit abweichenden Namen, Logos oder URLs. Für eine Marke innerhalb einer Gesellschaft sollte die reale Beziehung sichtbar erklärt und im Graphen konsistent modelliert werden.

Sieben Schritte für ein belastbares Schema-Setup

1. Sichtbare Fakten inventarisieren

Sammeln Sie rechtlichen Namen, Markenname, Haupt-URL, Logo, Kontakt, reale Standorte, Leistungen, Autoren und externe Profile. Klären Sie Widersprüche im Inhalt, bevor Sie diese maschinenlesbar vervielfachen.

2. Seitentypen zuordnen

Erstellen Sie eine kleine Matrix aus Templates und Hauptobjekten: Startseite, Leistung, Produkt, Artikel, Autor, Standort und FAQ. Wählen Sie pro Template den spezifischsten zutreffenden Typ. Ein Blogbeitrag über ein Produkt ist nicht automatisch eine Product-Seite.

3. Zentrale Entitäten definieren

Legen Sie dauerhafte @id-Werte für Organisation, Website und reale Personen fest. Nutzen Sie auf Unterseiten Referenzen statt neuer unabhängiger Kopien. Dokumentieren Sie, welches System die Stammdaten liefert.

4. Required und Recommended Properties trennen

Google-spezifische Rich Results besitzen eigene Pflicht- und Empfehlungseigenschaften. Schema.org selbst kennt wesentlich mehr gültige Properties als Google für eine Darstellung nutzt. Implementieren Sie zuerst vollständige Pflichtfelder und danach nur belastbare Zusatzinformationen.

5. Markup aus derselben Datenquelle erzeugen

Titel, Canonical, Autor, Veröffentlichungsdatum und Änderungsdatum sollten nicht separat in Template, CMS und JSON-LD gepflegt werden. Leiten Sie HTML und Markup möglichst aus denselben Feldern ab. Das senkt das Risiko veralteter oder widersprüchlicher Werte.

6. Drei Ebenen validieren

Syntax und Vokabular: Schema.org Validator
Google-Funktion: Rich Results Test
Ausgelieferte Seite: URL-Prüfung und Enhancement-Berichte in der Search Console

Ein grüner Test beweist nur, dass bestimmte technische Bedingungen erfüllt sind. Prüfen Sie zusätzlich manuell, ob Markup und sichtbarer Inhalt dieselbe Aussage treffen.

7. Änderungen überwachen

Erfassen Sie Fehler, Warnungen und betroffene Templates. Testen Sie nach Releases Stichproben aus jeder Seitenklasse. Bei großen Websites sollte ein Build-Gate mindestens valides JSON, erwartete Typen, eine stabile Organization-ID, Canonical-Konsistenz und sichtbare FAQ-Fragen prüfen.

Häufige Fehler, die LLMO und SEO gleichzeitig schwächen

Scheinstandorte: LocalBusiness oder PostalAddress für Büros, die nicht real existieren.
Falsche sameAs-Links: Profile werden verknüpft, obwohl sie nicht eindeutig dieselbe Entität repräsentieren.
Versteckte FAQ: Fragen stehen nur im JSON-LD und nicht für Nutzer auf der Seite.
Veraltete Daten: dateModified, Preise, Verfügbarkeit oder Personen stimmen nicht mehr.
Mehrere Organization-Identitäten: Name, URL und Logo wechseln zwischen Templates.
Unpassender Haupttyp: jede Seite erhält Product, LocalBusiness oder Article unabhängig vom Inhalt.
Schema-Spam: Bewertungen, Awards oder Aggregate Ratings werden ohne reale sichtbare Grundlage ergänzt.
Canonical-Konflikt: Markup referenziert eine .html-URL, während Canonical und Sitemap die saubere URL verwenden.

Strukturierte Daten für ChatGPT und andere Antwortsysteme

Für ChatGPT Search nennt OpenAI in der Publisher-FAQ vor allem den Zugriff von OAI-SearchBot. Ein besonderes ChatGPT-Schema wird dort nicht beschrieben. Daraus folgt eine wichtige Grenze: Korrektes JSON-LD kann Informationen expliziter machen, ist aber kein öffentlich bestätigter Schalter für eine ChatGPT-Citation.

Die robuste Strategie bleibt systemübergreifend:

Inhalte müssen öffentlich und crawlbar sein,
wichtige Aussagen müssen im sichtbaren HTML stehen,
Entitäten und Beziehungen müssen konsistent sein,
Quellen und Autorenschaft müssen überprüfbar sein,
Wirkung muss je Oberfläche mit festen Prompts gemessen werden.

Der Artikel Content für ChatGPT optimieren zeigt den vollständigen Weg von Crawl-Zugriff bis Monitoring. Der GEO-Leitfaden ordnet strukturierte Daten neben Content, Informationsarchitektur und externen Quellen ein.

Wie Sie die Wirkung messen

Testen Sie nicht die gesamte Website auf einmal. Wählen Sie ein stabiles Seitencluster und dokumentieren Sie:

Ausgangszustand und Fehlertypen,
implementierte Schema-Version,
Deployment-Datum,
Validierungsstatus und gecrawlte Version,
Rich-Result-Impressionen, CTR und organische Klicks,
Markennennungen, Citation-URLs und Aussagegenauigkeit im festen Prompt-Set.

Google empfiehlt für strukturierte Daten einen Vorher-/Nachher-Vergleich auf geeigneten, ausreichend stabilen Seiten. Vermeiden Sie Kausalbehauptungen, wenn gleichzeitig Inhalt, interne Links und Seitentemplate geändert wurden. Unsere Reporting-Methodik trennt Umsetzung, Beobachtung und mögliche Alternativerklärungen.

Fazit: Weniger Markup, dafür richtige Beziehungen

Ein gutes Structured-Data-Setup ist klein genug, um korrekt gepflegt zu werden, und vollständig genug, um zentrale Entitäten und Seitentypen eindeutig zu beschreiben. Beginnen Sie mit sichtbaren Fakten, stabilen IDs und passenden Typen. Validieren Sie nicht nur Syntax, sondern auch Wahrheit und Aktualität.

Sie möchten Inkonsistenzen zwischen Inhalt, Canonical und JSON-LD erkennen? Website prüfen und anschließend einen verfügbaren Termin wählen.

Quellenstand: 15. Juli 2026. Verwendet wurden Googles Einführung zu strukturierten Daten, die allgemeinen Richtlinien, der Leitfaden zu AI-Funktionen, die offiziellen Schema.org-Typen und OpenAIs Publisher-FAQ.

Häufig gestellte Fragen

Welche strukturierten Daten sind für LLMO sinnvoll?

Sinnvoll sind Typen, die den sichtbaren Seitentyp und reale Entitäten korrekt beschreiben, etwa Organization, WebSite, WebPage, Article, BreadcrumbList, Service, Product oder FAQPage. Die Auswahl hängt vom tatsächlichen Inhalt ab; mehr Typen sind nicht automatisch besser.

Gibt es ein spezielles Schema für ChatGPT oder Google AI Mode?

Nein. Google erklärt ausdrücklich, dass für AI Overviews und AI Mode kein spezielles Schema.org-Markup erforderlich ist. OpenAI dokumentiert ebenfalls kein besonderes Schema, das eine Nennung garantiert. Markup sollte sichtbare Inhalte korrekt beschreiben und bestehende Entitäten verbinden.

Ist JSON-LD besser als Microdata oder RDFa?

Google unterstützt alle drei Formate, empfiehlt JSON-LD in den meisten Fällen aber als leichter implementier- und wartbare Lösung. Entscheidend bleiben valide Syntax, vollständige erforderliche Properties und die Übereinstimmung mit dem sichtbaren Inhalt.

Garantiert valides Schema ein Rich Result oder eine KI-Zitation?

Nein. Google garantiert selbst bei technisch korrektem Markup kein Rich Result. Eine KI-Zitation lässt sich ebenfalls nicht garantieren. Strukturierte Daten liefern explizite Hinweise, ersetzen aber weder Indexierung, Relevanz, Quellenqualität noch Auswahl durch ein externes System.

Wie validiert man strukturierte Daten?

Nutzen Sie den Schema.org Validator für das allgemeine Vokabular, Googles Rich Results Test für unterstützte Suchfunktionen und die URL-Prüfung in der Search Console für die tatsächlich gecrawlte Seite. Prüfen Sie zusätzlich manuell, ob jede Aussage im Markup sichtbar und aktuell ist.

Soll jede Seite Organization-Markup enthalten?

Eine konsistente zentrale Organization-Entität kann seitenübergreifend referenziert werden. Vermeiden Sie jedoch widersprüchliche Kopien. Verwenden Sie dieselbe stabile @id und pflegen Sie Name, URL, Logo, rechtliche Beziehung und Profile aus einer gemeinsamen Quelle.

Hilft FAQPage-Markup noch bei Google?

FAQPage ist ein gültiger Schema.org-Typ, doch die Sichtbarkeit als Google-Rich-Result hängt von Googles aktueller Unterstützung und den Richtlinien ab. Verwenden Sie FAQ-Markup nur für sichtbare Fragen und Antworten und nicht als allgemeinen Ranking- oder KI-Hack.

Kostenlose Ersteinschätzung

Beschreibt Ihr JSON-LD das Unternehmen – oder erzeugt es Widersprüche?

Der Website-Check prüft öffentlich sichtbare Grundlagen. Im nächsten Schritt gleichen wir Seitentypen, Entitäten, Canonicals und Markup mit dem tatsächlichen Inhalt ab.

Website und Schema-Basis prüfenErgebnis zuerst. Kontaktdaten erst, wenn Sie fortfahren möchten.

← Alle Wissensartikel ansehen