Blog

JSON-LD steht für JavaScript Object Notation for Linked Data und ist das von Google bevorzugte Format, um strukturierte Daten in eine Website einzubetten. Es nutzt das Schema.org-Vokabular, um Suchmaschinen und Sprachmodellen zu erklären, worum es auf einer Seite geht. Anders als sichtbarer Text richtet sich JSON-LD ausschließlich an Maschinen.

Wie ChatGPT, Gemini und Perplexity strukturierte Daten wirklich verwenden

Die drei großen Sprachmodelle nutzen strukturierte Daten unterschiedlich. Google Gemini und die Google-AI-Overview greifen direkt auf den Google Knowledge Graph zu, in den Schema-Signale wie Organization, sameAs und knowsAbout einfließen. Bei ChatGPT wird Schema-Markup über die Browse-Ergebnisse und über Bing-Indexdaten indirekt verwertet. Perplexity liest Seiten mit einem eigenen Crawler und nutzt Article- und FAQPage-Strukturen, um Antwort-Bausteine zu identifizieren.

Der entscheidende Punkt ist die maschinelle Klarstellung. Ein Sprachmodell muss aus dem Rohtext nicht mehr raten, wer der Autor ist, wann der Inhalt zuletzt aktualisiert wurde und zu welcher Marke er gehört. Diese Signale liegen strukturiert vor und lassen sich ohne Interpretation lesen. Genau dort liegt der Hebel von JSON-LD für AI-Sichtbarkeit.

Wichtig ist die Trennung zwischen Ranking-Signal und Extraktions-Signal. JSON-LD hebt keine Seite über sich hinaus. Aber es entscheidet oft darüber, ob eine bereits gute Seite als sauber verknüpfte Entität zitiert wird oder ob sie in einer Antwort untergeht, weil das Modell die Marke nicht klar zuordnen konnte. Wer in KI-Suchmaschinen sichtbar werden will, kommt ohne dieses Grundgerüst nicht durch.

Was ist JSON-LD genau

JSON-LD ist ein Format, das strukturierte Informationen als JSON-Objekt in den Quellcode einer Seite einbettet, meist im head-Bereich oder am Seitenende. Es beschreibt Entitäten und ihre Eigenschaften nach dem Schema.org-Standard. Ein Sprachmodell oder eine Suchmaschine kann diese Angaben direkt auslesen, ohne den Fließtext interpretieren zu müssen.

Der Vorteil von JSON-LD gegenüber älteren Formaten wie Microdata oder RDFa liegt in der Trennung von Inhalt und Markup. Das Markup steht in einem eigenen script-Block und ist nicht mit dem HTML verwoben. Das macht es einfacher zu pflegen, weniger fehleranfällig und entspricht der offiziellen Google-Empfehlung.

Ein typisches JSON-LD-Objekt enthält den Kontext (schema.org), einen Typ (etwa Article oder Organization) und eine Reihe von Eigenschaften. Diese Struktur ist standardisiert, sodass jede Suchmaschine und jedes Sprachmodell sie identisch interpretiert.

Welche Schema-Typen sind für AI-Visibility relevant

Die drei wichtigsten Schema-Typen für AI-Visibility sind Organization, Article und FAQPage. Organization beschreibt die Marke als Entität, Article jeden einzelnen Beitrag, FAQPage strukturiert Frage-Antwort-Inhalte. Ergänzend sind Person für Autoren und BreadcrumbList für die Navigation wertvoll.

Organization-Schema ist die Basis. Es definiert den Markennamen, die Website, das Logo und über sameAs die offiziellen Profile auf anderen Plattformen. Damit grenzt es die Marke eindeutig von ähnlich benannten Entitäten ab. Für LLMs ist diese klare Abgrenzung entscheidend, um Verwechslungen zu vermeiden.

Article-Schema verbindet jeden Beitrag mit seinem Autor, dem Veröffentlichungs- und Aktualisierungsdatum und dem Herausgeber. Die Verbindung zum Person-Schema des Autors ist dabei zentral, weil sie das E-E-A-T-Signal der Autorenschaft maschinenlesbar macht.

Wie bettest du JSON-LD korrekt ein

JSON-LD wird als script-Block mit dem Typ application/ld+json in den HTML-Code eingebettet, idealerweise im head-Bereich. Pro Seite können mehrere Blöcke existieren, etwa einer für Organization, einer für Article und einer für FAQPage. In WordPress übernehmen Plugins wie Rank Math oder Yoast die Generierung automatisch.

Der manuelle Weg ist nur für Spezialfälle nötig. Die meisten WordPress-Sites generieren ihr Schema über das SEO-Plugin. Wichtig ist, das Markup nach der Einbindung zu validieren, um Fehler auszuschließen. Ein fehlerhaftes Schema wird ignoriert und bringt keinen Nutzen.

Die Validierung läuft über den Schema-Markup-Validator von Schema.org oder den Rich-Results-Test von Google. Beide zeigen, ob das Markup korrekt geparst wird und welche Eigenschaften erkannt werden. Ein sauberer Durchlauf ohne Fehler oder Warnungen ist das Ziel.

// Organization-Schema, eingebettet im <head>
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Levent Elci",
  "url": "https://leventelci.de",
  "logo": "https://leventelci.de/logo.png",
  "sameAs": [
    "https://www.linkedin.com/in/levent-elci-solutions/"
  ],
  "knowsAbout": [
    "AI-Visibility", "Generative Engine Optimization",
    "Brand Mentions", "Offpage SEO"
  ]
}

Nutzen LLMs strukturierte Daten überhaupt

LLMs nutzen strukturierte Daten indirekt. Sie lesen primär den sichtbaren Text, aber JSON-LD hilft bei der Entitäts-Klarstellung und der korrekten Zuordnung von Autor, Datum und Herausgeber. Google hat klargestellt, dass für die generative Suche keine speziellen AI-Markups nötig sind, das bestehende Schema reicht.

Der praktische Wert liegt in der Eindeutigkeit. Wenn ein Modell unsicher ist, ob eine Information aktuell oder von einem qualifizierten Autor stammt, liefert das Schema die Antwort. Das Article-Schema mit datePublished und author macht diese Signale maschinenlesbar, statt sie im Fließtext suchen zu müssen.

Wichtig ist die richtige Erwartung: JSON-LD ist kein Wundermittel und kein direkter Ranking-Faktor. Es ist ein unterstützendes Klarstellungs-Werkzeug. Wer es korrekt einsetzt, gewinnt Eindeutigkeit. Wer es weglässt, verliert nicht alles, aber lässt eine einfache Optimierung liegen.

Welche Schema-Typen 2026 den größten Hebel für AI-Sichtbarkeit haben

Die klassischen Typen Organization, Article und FAQPage sind Pflicht. Darüber hinaus lohnen sich 2026 mehrere ergänzende Typen, je nach Site-Zweck: Product, HowTo, SoftwareApplication, LocalBusiness und Speakable. Sie decken Anwendungsfälle ab, die von Sprachmodellen und Sprachassistenten häufig als Antwort-Trigger genutzt werden.

Product-Schema strukturiert Preise, Bewertungen und Verfügbarkeit. HowTo bildet Schritt-für-Schritt-Anleitungen ab und wird von Perplexity und Google-AI-Overview häufig für prozessuale Fragen gezogen. SoftwareApplication beschreibt digitale Produkte inklusive Betriebssystem, Preis und Bewertung. LocalBusiness verknüpft physische Standorte mit Öffnungszeiten und Servicebereich und ist die Basis für Local-Citations und Google-Maps-Präsenz.

Speakable ist der spannendste unter den neueren Typen. Er markiert Textabschnitte, die von Sprachassistenten wie Google Assistant vorgelesen werden können. Für News-Sites und Ratgeber ist das ein direktes Voice-Sichtbarkeits-Signal. Wer eine Sprachsuche-Strategie aufbaut, sollte Speakable auf den 40-Wort-Direktantworten unter jeder H2 setzen.

Wie du Entitäten mit sameAs, knowsAbout und mentions vernetzt

Die drei Eigenschaften sameAs, knowsAbout und mentions sind das Rückgrat der Entitäts-Vernetzung. sameAs verbindet ein Schema-Objekt mit externen Referenzen wie LinkedIn, Wikipedia, Wikidata, dem Google-Business-Profil oder Fach-Verzeichnissen. knowsAbout listet Themenfelder, in denen eine Person oder Organisation Expertise hat. mentions verknüpft einen Artikel mit den darin behandelten Entitäten.

Für Entity-SEO ist das der entscheidende Punkt. Ohne sameAs zu mindestens drei starken externen Quellen bleibt eine Organization ein isolierter Knoten. Mit sauberen sameAs-Verweisen wird sie Teil des Knowledge-Graphen und lässt sich von Modellen sicher zuordnen. Wer eine Marke aufbaut, sollte in jedem Organization-Block LinkedIn, Wikidata und mindestens ein branchenspezifisches Profil verlinken.

knowsAbout ist das aktivste Signal für thematische Autorität. In Person-Schemas gehört es auf die drei bis fünf Kernthemen, in Organization-Schemas auf die Kern-Themencluster der Marke. mentions wiederum sollte in Article-Schemas auf zwei bis fünf zentrale Entitäten pro Beitrag zeigen, idealerweise mit Wikidata-Verweisen. Diese Verweise bilden die Grundlage für den Knowledge-Graphen deiner Marke und für die spätere Zuordnung in ChatGPT-Empfehlungen.

Welche Fehler treten bei JSON-LD häufig auf

Die häufigsten Fehler sind fehlende Pflichtfelder, Markup ohne sichtbare Entsprechung im Inhalt, fehlerhafte Verschachtelung und veraltete Schema-Typen. Auch die fehlende Verbindung zwischen Article und Person ist verbreitet. Diese Fehler führen dazu, dass das Schema ignoriert wird oder Warnungen erzeugt.

Ein verbreiteter Fehler ist doppeltes oder widersprüchliches Markup, etwa wenn zwei Plugins gleichzeitig Schema generieren. Das verwirrt die Parser und sollte vermieden werden. Pro Seite sollte es genau eine konsistente Schema-Struktur geben, idealerweise aus einer einzigen Quelle.

Veraltete Typen wie das frühere FAQ-Rich-Result, das Google in seiner Darstellung eingeschränkt hat, sind ein weiterer Stolperstein. Schema-Typen ändern in ihrer Darstellung über die Zeit. Es lohnt sich, die aktuelle Google-Dokumentation zu prüfen, bevor man auf einen bestimmten Rich-Result-Effekt setzt.

Welche Fehler dir 2026 die LLM-Sichtbarkeit kosten

Neben den klassischen Fehlern gibt es 2026 vier spezifische Muster, die AI-Sichtbarkeit killen. Erstens: Widersprüche zwischen Schema und sichtbarem Inhalt. Wenn im Article-Schema ein anderer Autor steht als in der Autorenbox, verwerfen Modelle das Signal komplett und behandeln die Seite als unsauber. Zweitens: veraltete sameAs-Verweise. Ein toter Wikidata-Link oder eine gelöschte Autorenseite schwächt die Entitäts-Verknüpfung.

Drittens: fehlende dateModified-Werte. Ohne Aktualisierungsdatum kann kein Modell die Frische einer Seite belegen und behandelt sie im Zweifel als veraltet. Viertens: doppelte Author-Signale, wenn die Autoren-Box das E-E-A-T-Signal in HTML setzt und ein Plugin gleichzeitig ein widersprüchliches Person-Schema erzeugt.

Der Fix ist in allen vier Fällen die gleiche Regel: eine einzige Quelle der Wahrheit. Rank Math oder Yoast generieren die Grundstruktur, alle Autoren-Signale kommen aus dem User-Profil, alle Marken-Signale aus einer zentralen Organization-Konfiguration. Manuelle Ergänzungen wie mentions oder knowsAbout kommen als kontrollierter Custom-Code-Block dazu, nicht als parallele Zweitquelle. Dieses saubere Setup ist Pflichthygiene für moderne E-E-A-T-Signale in der AI-Suche.

Wie unterscheidet sich Schema-Markup für Google AI Overview vom klassischen Rich Snippet?

Das klassische Rich Snippet richtet sich an das Google-Frontend. FAQPage, HowTo und Product-Sterne erweitern das Suchergebnis um sichtbare Zusatzinformationen. Der Nutzen ist punktuell und liegt in der Klick-Rate, das Ranking selbst verändert sich dadurch nicht. Für AI Overview ist die Logik anders: Das Modell fragt weniger nach einem einzelnen Feld und mehr nach einer sauberen Entitäts-Kette, aus der es die Herkunft einer Aussage rekonstruieren kann.

Konkret heißt das: Wenn dein Article-Schema per author auf ein vollständiges Person-Schema zeigt, das per sameAs zu LinkedIn, Wikidata und einer Autorenseite verweist, und dieses Person-Schema wiederum per worksFor auf dein Organization-Schema mit sameAs zu deinen Social-Profilen zeigt, sieht Gemini eine geschlossene Kette. Diese Kette ist der Grund, warum eine Marke in Google AI Overview überhaupt namentlich genannt wird und nicht nur als anonyme Textquelle im Hintergrund verschwindet.

Für das AI Overview gibt es zusätzlich einen praktischen Effekt: Das Modell nutzt about und mentions, um die semantische Nähe zwischen deiner Seite und der Anfrage zu bewerten. Ein Artikel über strukturierte Daten, der explizit mentions auf Schema.org, Google und JSON-LD als Entitäten setzt, wird bei Anfragen zu genau diesen Themen als hochrelevant eingestuft. Das ist kein Ranking-Boost im klassischen Sinn, sondern ein Zitations-Faktor, der bestimmt, ob deine Domain in der KI-Antwort auftaucht oder nicht.

Welche neuen Schema-Properties zeigen 2026 messbaren Effekt in AI-Antworten?

knowsAbout im Person-Schema ist die effektivste Ergänzung, die kaum jemand nutzt. Jeder Autor bekommt eine Liste an Themen zugewiesen, für die er nachweislich schreibt. In deinem Fall wäre das eine Kette wie SEO, Answer Engine Optimization, Generative Engine Optimization und Brand Mentions. Modelle lesen diese Liste und ordnen den Autor als thematisch relevant ein, wenn eine Anfrage in dieses Feld fällt. Damit wird aus einer generischen Autoren-Bio ein maschinell verwertbarer Expertise-Nachweis.

mentions im Article-Schema erfüllt eine ähnliche Rolle für einzelne Beiträge. Jedes zentrale Konzept, das im Text vorkommt, wird als eigenes Entity mit @id und sameAs auf Wikidata verlinkt. Das entlastet das Modell von der Wortentität-Zuordnung und macht klar, welches Konzept gemeint ist. Isoliert wirkt das unspektakulär, in Kombination mit sauberen internen Links zwischen thematisch verwandten Beiträgen wie Entity SEO oder Knowledge Graph entsteht daraus eine belastbare thematische Autorität.

isBasedOn und citation sind für Beiträge relevant, die auf Studien, Whitepaper oder Original-Interviews aufbauen. Beide Properties liefern maschinell nachvollziehbare Quellenketten. Ein Modell, das entscheidet, welche der zehn zitierten Domains den ursprünglichen Datenpunkt geliefert hat, greift genau auf dieses Signal zurück. Wer Studien zitiert, ohne sie zu markieren, verliert diesen Bonus an den ersten Wettbewerber, der es tut.

Wie prüfst du in fünf Minuten, ob ChatGPT und Perplexity dein JSON-LD wirklich verwenden?

Der praktische Test folgt einer festen Reihenfolge. Zuerst prüfst du im Rich-Results-Test und im Schema-Validator, dass alle Kern-Entitäten fehlerfrei erkannt werden. Wichtig ist an dieser Stelle nicht nur die Abwesenheit von Warnungen, sondern der explizite Blick auf die generierte Entity-Struktur, die dir das Tool ausgibt. Fehlt dort dein Person- oder Organization-Objekt, ist das Markup zwar syntaktisch korrekt, semantisch aber leer.

Im zweiten Schritt öffnest du ChatGPT mit aktiviertem Web-Browsing oder Perplexity und stellst drei sehr konkrete Fragen zu deiner URL: Wer ist der Autor des Beitrags, welche Organisation steht dahinter und welche drei Kernbegriffe behandelt der Text. Bei sauberem Schema kommen alle drei Antworten mit den korrekten Namen und Konzepten zurück. Fehlt ein Signal, siehst du sofort, welche Property nachgezogen werden muss.

Der dritte Schritt ist ein Live-Beobachtungslauf: Du wartest zwei bis vier Wochen und beobachtest, ob deine Domain in Perplexity- oder ChatGPT-Antworten zu deinen Ziel-Themen als Quelle auftaucht. Für dieses Monitoring reichen manuelle Stichproben, in strukturierter Form kannst du das mit einem der Zitations-Trackings aus dem Beitrag KI-Suchmaschinen und Sichtbarkeit automatisieren. Diese drei Schritte kosten insgesamt weniger als fünf Minuten pro Beitrag und ersetzen jede theoretische Diskussion darüber, ob JSON-LD in der AI-Suche etwas bringt oder nicht.

Wie erstellst du JSON-LD in fünf Schritten für dein WordPress?

Der häufigste Fehler in WordPress-Installationen ist, dass jedes Plugin sein eigenes JSON-LD ausgibt und die Signale sich gegenseitig überschreiben. Du bekommst dann drei Organization-Blöcke mit widersprüchlichen Angaben und keiner davon wird sauber ausgewertet. Die fünf Schritte unten drehen diesen Effekt um und liefern eine einzige, konsistente Entitäts-Kette.

Schritt eins: Organization als globale Konstante. Lege im Theme oder in einem Mini-Plugin genau einen Organization-Block an, den jede Seite ausgibt. Er enthält name, url, logo, sameAs mit deinen wichtigsten Profilen und, falls verfügbar, foundingDate. Das ist der Anker, an dem sich alle anderen Blöcke ausrichten.

Schritt zwei: Person-Schema für jeden Autor. Jeder Autor bekommt eine eigene Person-Entität mit name, url, sameAs, jobTitle und knowsAbout. knowsAbout ist der unterschätzte Hebel, weil es Sprachmodelle direkt darauf hinweist, für welche Themen dieser Mensch als Autorität gilt. Verknüpfe Person und Organization über worksFor oder affiliation.

Schritt drei: Article-Schema mit Vererbung. Der Article-Block einer Seite referenziert Autor und Herausgeber über @id-Verweise. So entsteht ein Graph, kein isolierter Block. Ergänze headline, datePublished, dateModified und, wenn du kannst, mainEntityOfPage. Diese vier Felder sind das Minimum, das Google Gemini als Aktualitätssignal liest.

Schritt vier: Prüfen mit mehr als einem Werkzeug. Google Rich Results Test zeigt nur, was für Rich Snippets relevant ist. Nutze zusätzlich den Schema.org Validator und die JSON-LD Playground-Ansicht, um zu sehen, wie der Graph tatsächlich aussieht. Erst wenn Autor, Marke und Beitrag als drei verbundene Knoten sichtbar sind, ist die Ausgabe für LLMs verwertbar.

Schritt fünf: dateModified diszipliniert pflegen. Jede substanzielle Änderung bekommt ein aktualisiertes dateModified. Kosmetische Änderungen nicht. Dieser Punkt allein hebt in Gemini messbar die Wahrscheinlichkeit, dass eine Seite als aktueller Datenpunkt zitiert wird. Ein sauberes Redaktionslog hilft, dieses Feld ehrlich zu halten. Wenn du deine Content-Audits regelmäßig durchführst, hast du diese Daten ohnehin schon strukturiert.

Wenn du dieses Muster einhältst, sieht jeder Crawler die gleiche Marke, den gleichen Autor und den gleichen Beitrag als verbundene Einheit. Für den Aufbau von Autorenschaft, die zu einem Google Knowledge Panel führt, ist genau diese Verknüpfung die Grundvoraussetzung.

Welche JSON-LD-Konflikte kosten dich 2026 messbar AI-Sichtbarkeit?

Die häufigste Ursache für unsichtbare Marken in ChatGPT-Antworten ist nicht fehlendes Schema, sondern widersprüchliches Schema. Ein SEO-Plugin, ein Theme-Builder und ein Cookie-Consent-Layer geben jeweils Organization-Blöcke aus, die sich in einem oder mehreren Feldern widersprechen. Der Crawler liest das, findet drei Versionen der gleichen Marke und wählt keine als kanonisch. Genau dann verschwindet die Marke aus generativen Antworten.

Konflikt eins: Doppelte Organization-Blöcke. Prüfe im Quelltext, ob mehr als ein Organization-Block ausgegeben wird. Deaktiviere in jedem Plugin, das nicht der Master ist, die Organization-Ausgabe. Wenn ein Plugin das nicht erlaubt, wechsle das Plugin. Ein sauberer Master-Block schlägt jedes teilverstärkende Fragment.

Konflikt zwei: Article ohne Person-Anker. Wenn dein Article-Block einen author als String enthält statt als verlinkte Person-Entität, verliert der Graph seine Vererbung. Für Google und die Sprachmodelle ist ein author „Max Mustermann“ ohne @id nicht dieselbe Person wie ein Person-Block mit sameAs. Immer verlinken, nie nur benennen.

Konflikt drei: sameAs mit leeren Zielen. Wenn du im Organization- oder Person-Schema sameAs auf ein X-Profil verweist, das seit Jahren keine Aktivität hat, oder auf ein LinkedIn-Profil ohne relevante Angaben, dann arbeitet dieses Signal gegen dich. Sprachmodelle prüfen inzwischen, ob das verlinkte Profil aktiv ist. Ein aktives Profil mit wenigen Verknüpfungen schlägt zehn tote Links.

Konflikt vier: dateModified friert im Cache ein. Aggressives Object-Caching oder statisch generierte JSON-LD-Snapshots führen dazu, dass dateModified nicht mitläuft, wenn du einen Beitrag überarbeitest. Google Gemini erkennt das an der Diskrepanz zwischen Sichtbarem und Strukturiertem und wertet die Seite als weniger aktuell. Cache-Regeln für JSON-LD-Ausgaben bewusst kürzer setzen als für den Rest der Seite.

Wenn du zusätzlich prüfen willst, wie diese Konfliktmuster in einer Answer-Engine-Optimierung systematisch aufgelöst werden, findest du dort die konkreten Prüfschritte für jede Engine.

Warum reicht der Google Rich Results Test 2026 nicht mehr aus?

Der Google Rich Results Test ist ein hervorragendes Werkzeug für seinen ursprünglichen Zweck: er zeigt dir, ob Google mit deinem Markup ein visuelles Rich Snippet erzeugen kann. FAQ-Sterne, Rezept-Karten, Produkt-Preise. Was er nicht zeigt, ist der volle Graph. Wenn du Organization, Person und Article über @id-Referenzen verknüpfst, siehst du im Rich Results Test nur den Article-Teil. Der Rest wird als nicht relevant für Rich Snippets ignoriert.

Für AI-Sichtbarkeit ist aber genau dieser Rest entscheidend. Sprachmodelle lesen den ganzen Graph, nicht den Snippet-Ausschnitt. Deshalb brauchst du eine zweite Prüfschicht. Der Schema.org Validator zeigt dir, ob alle Typen und Properties zum aktuellen Schema.org-Standard passen. Der JSON-LD Playground rendert den Graph visuell und macht sichtbar, welche Knoten miteinander verbunden sind und welche isoliert stehen.

Drei Prüfschritte, die der Rich Results Test nicht ersetzt. Erstens: ein View-Source auf deiner Live-Seite, um zu sehen, ob JavaScript-generiertes Schema wirklich im HTML ankommt. Zweitens: ein manueller cURL-Request mit User-Agent GPTBot oder PerplexityBot, um zu sehen, ob deine Ausgabe für diese Crawler identisch ist mit der Version für den Googlebot. Drittens: ein Vergleich zwischen dem, was Search Console als strukturierte Daten meldet, und dem, was der Live-Quelltext zeigt.

Wenn du diese drei Ebenen abdeckst, schließt du die typische Lücke zwischen „Rich Results Test grün“ und „trotzdem keine AI-Sichtbarkeit“. Das ist derselbe methodische Ansatz, den die Entity-SEO-Systematik für die gesamte Marken-Präsenz verlangt. Und für das Verhältnis zwischen klassischer und generativer Suche liefert der Vergleich Generative Engine Optimization gegenüber klassischem SEO die weiteren Prüfebenen.

Welche JSON-LD-Struktur brauchen Personal Brands und Solo-Beratungen wirklich?

Für ein klassisches Unternehmen ist Organization das Zentrum des Graphs. Für Personal Brands, Solo-Beratungen und Ein-Personen-Agenturen führt genau dieses Muster in eine Sackgasse, weil sich Organization und Person überlappen und Sprachmodelle nicht klären können, welche Entität eigentlich als Autorität gilt. Die Lösung ist eine bewusste Umkehrung: Person zuerst, alles andere referenziert diese Person.

Du beschreibst dich als Person mit name, url, image, jobTitle, worksFor mit deiner eigenen Marke, knowsAbout mit deinen Kernthemen und sameAs mit den fünf bis sieben Plattformen, auf denen du aktiv bist. Für den geschäftlichen Auftritt legst du zusätzlich einen ProfessionalService-Block an, der founder auf deine Person referenziert. So entsteht ein sauberer Zwei-Knoten-Graph, in dem die Marke aus der Person heraus verstanden wird.

Warum diese Umkehrung wirkt. Sprachmodelle bevorzugen bei personennahen Themen den Menschen als Zitier-Anker. Wer dieses Muster im Schema abbildet, gibt dem Modell genau die Struktur, die es intern ohnehin sucht. Das ist der gleiche Mechanismus, der auch bei der Bewertung von Brand Mentions greift, wenn eine Person und eine Marke in Erwähnungen als Einheit auftreten.

Für Article-Blöcke gilt dann: author verweist per @id auf deine Person, publisher verweist auf deinen ProfessionalService, aber inhaltlich stehen die Beiträge auf der Person. In der Praxis führt diese Struktur zu einer messbar häufigeren Nennung des Menschen in ChatGPT- und Perplexity-Antworten, weil das Modell den Beitrag korrekt einer konkreten, aktiven Person zuordnen kann.

Wer diese Struktur nicht nur schematisch, sondern auch redaktionell konsequent aufbaut, sollte den ersten Content-Aufbau in Themencluster denken. Denn Person-Schema entfaltet erst dann volle Wirkung, wenn hinter der Person auch inhaltlich ein sichtbares Themengebiet steht. Und wenn du diese Themen strukturiert durch die eigene Keyword-Recherche ableitest, bekommst du automatisch die Bandbreite für knowsAbout, die du im Person-Schema abbildest.

Was ist der Unterschied zwischen Schema.org und JSON-LD?

Wer sich zum ersten Mal mit strukturierten Daten beschaeftigt, verwechselt die beiden Ebenen fast immer. Schema.org ist ein Wörterbuch, JSON-LD ist eine Sprache, mit der du dieses Wörterbuch aussprichst. Du kannst dasselbe Schema.org-Vokabular auch in Microdata direkt im HTML-Attribut oder in RDFa markieren. Praktisch relevant sind heute aber nur JSON-LD und in Restfällen Microdata. Alle anderen Formate werden in modernen Extraktions-Pipelines von Suchmaschinen und LLM-Crawlern deutlich schlechter verarbeitet.

Der zweite Unterschied ist Wartbarkeit. JSON-LD steht als abgeschlossener Block im head oder am Ende des body und ist unabhaengig vom sichtbaren Markup. Änderst du dein Theme oder deinen Editor, bleibt das Schema erhalten. Microdata und RDFa sind an das HTML-Markup gebunden und brechen bei jeder Theme-Umstellung oder bei aggressiver HTML-Optimierung durch Cache-Plugins.

Für AI-Sichtbarkeit gibt es noch einen dritten Punkt. LLM-Crawler wie GPTBot, ClaudeBot und PerplexityBot extrahieren strukturierte Daten am zuverlässigsten aus JSON-LD-Blöcken, weil sie als JSON-Objekt vom Rest der Seite trennbar sind. Wer Microdata verwendet, verliert mit hoher Wahrscheinlichkeit in der Extraktion Informationen wie sameAs oder knowsAbout.

Wie baust du JSON-LD gezielt für AI Search auf?

Klassisches Schema-Markup wurde über Jahre auf Rich Snippets in der Google-SERP hin optimiert: Sternebewertungen für Produkte, Zubereitungszeit für Rezepte, Öffnungszeiten für lokale Betriebe. Diese Signale funktionieren weiterhin, sie sind aber nicht das, was in einer AI-Antwort zitiert wird. In einer Antwort von ChatGPT, Gemini oder Perplexity zählen andere Felder.

Der erste Umbau betrifft die Entitäts-Verknüpfung. Ein Artikel-JSON-LD ohne author.sameAs auf ein LinkedIn- oder Wikidata-Profil ist für ein Sprachmodell eine Aussage ohne Absender. Ergänze author als eigenen Person-Block mit sameAs auf mindestens drei externe Referenzen, dazu knowsAbout mit drei bis fünf Themen, in denen die Person real publiziert. Das gleiche gilt für publisher: Organization mit sameAs auf Wikidata, LinkedIn Company und optional Crunchbase.

Der zweite Umbau betrifft die Antwortzone. Fuege in Article ein speakable-Feld hinzu, das per CSS-Selektor auf die Direktantwort-Box unter jeder H2 zeigt. Genau diese Passage nimmt Perplexity messbar oefter als Zitat-Baustein. Der dritte Umbau ist mentions. Verknuepfe zwei bis drei relevante Marken oder Konzepte per Thing mit Wikidata-Identifier. Das härten deine Co-Occurrence-Signale.

Der vierte Umbau ist Frische. dateModified muss real gepflegt sein, nicht Copy-Paste von datePublished. Ein Artikel, dessen dateModified seit einem Jahr unverändert ist, wird in Gemini-Antworten seltener zitiert, selbst wenn das eigentliche Ranking im klassischen SERP stabil bleibt. Wer die vier Punkte konsequent umsetzt, verschiebt seine JSON-LD-Struktur von einer Rich-Snippet-Optimierung hin zu einer Entity-Optimierung. Genau das ist der Punkt, an dem AI-Sichtbarkeit anfaengt zu wachsen.

Welche JSON-LD-Signale zeigen 2026 messbar mehr Zitationen in ChatGPT und Perplexity?

In der Portfolio-Beobachtung über 165 Sites zeigt sich ein klares Muster. Sites mit vollständigem Organization-Schema plus mindestens drei sameAs-Verknüpfungen auf externe Autoritaets-Profile werden in ChatGPT-Antworten deutlich zuverlässiger der richtigen Marke zugeordnet. Sites ohne sameAs oder mit nur einem Eintrag laufen Gefahr, unter einer anderen ähnlich klingenden Marke geführt zu werden. Das ist ein direktes Marken-Sicherheitsrisiko und ein Grund, warum wir bei jeder neuen Portfolio-Site zuerst das Organization-Schema härten.

Beim Person-Schema greift ein ähnlicher Effekt. Ein Autor ohne knowsAbout und ohne sameAs wird von Perplexity nicht als thematischer Experte erkannt. Das zeigt sich in Antworten, in denen die Person nicht als Quelle genannt wird, obwohl der Artikel inhaltlich passt. Wir tracken das über die Frage Wer sind führende Experten für X in Deutschland? und pruefen, ob die Autoren aus dem Portfolio zitiert werden.

Speakable und FAQPage sind Feinschliff, aber messbar. Ein Speakable-Selektor auf die Direktantwort-Box erhöht die Wahrscheinlichkeit deutlich, dass genau dieser Absatz als Zitat-Baustein bei Perplexity landet. FAQPage funktioniert 2026 weiterhin, aber nur wenn die Frage-Formulierung exakt zur Nutzerfrage passt. Generische FAQs ohne echte Query-Intention werden nicht zitiert.

Wie prüft ein LLM-Crawler dein JSON-LD Schritt für Schritt?

Der erste Schritt ist der HTTP-Request. GPTBot, ClaudeBot und PerplexityBot senden anders als ein Nutzer-Browser keinen JavaScript-Rendering-Request, sondern holen zuerst das reine HTML. Wer JSON-LD ausschließlich per JavaScript nach dem Seitenaufbau nachlädt, wird von den meisten LLM-Crawlern nicht erfasst. Server-seitig ausgeliefertes JSON-LD im head oder direkt im body-Anfang ist Pflicht.

Der zweite Schritt ist die Extraktion aller script-Blöcke vom Typ application slash ld plus json. Der Crawler sammelt alle Blöcke ein, nicht nur den ersten. Wer mehrere Blöcke einsetzt, sollte darauf achten, dass sie sich nicht widersprechen. Ein Bruch entsteht, wenn der Article-Block einen anderen Autor nennt als der Person-Block oder wenn die Organization einmal mit und einmal ohne sameAs auftaucht.

Der dritte Schritt ist das JSON-Parsing. Hier scheitern viele Sites, weil Rank Math, Yoast und ein Custom-Schema-Snippet gleichzeitig aktiv sind. Doppelte Article-Blöcke mit unterschiedlicher Struktur werden von einigen Crawlern als Konflikt markiert und teilweise verworfen. Deshalb ist die Regel: ein Schema-Generator pro Site. Alles andere multipliziert Fehlerquellen.

Der vierte Schritt ist die Entitäts-Aufloesung. Der Crawler folgt sameAs-Links und prüft, ob die genannten Profile existieren und die Marke bestaetigen. Wer sameAs auf tote LinkedIn-Profile setzt oder auf einen Wikidata-Q-Identifier verweist, der zu einer anderen Marke gehört, verschenkt das Signal komplett. Das ist der häufigste stille Fehler, weil er auf der eigenen Site nicht sichtbar ist.

Der fünfte Schritt ist die Ablage in der Antwort-Datenbank. Hier entscheidet der Crawler, welche Signale er speichert und welche er verwirft. Vollständige, konsistente Blöcke überleben. Fragmentierte oder widersprüchliche Blöcke werden zurückgestellt oder ignoriert. Genau deshalb ist es strategisch klüger, drei Schema-Typen sauber zu liefern als sieben Typen mit Luecken.

Wie verknüpft JSON-LD Themenrelevanz und Co-Occurrence für LLMs?

Klassisch wurden Themenrelevanz und Co-Occurrence rein aus Fließtext berechnet. Ein Crawler zählt, welche Begriffe zusammen im gleichen Textblock vorkommen, und leitet daraus Nähe ab. JSON-LD verkürzt diesen Schritt. Wenn du im about-Feld eines Article-Blocks einen Wikidata-Q-Identifier für das Hauptthema hinterlegst, muss der Crawler nicht mehr raten, worum es geht. Er kann die Verknüpfung direkt vornehmen und den Artikel in den passenden Themen-Knoten einordnen.

Das mentions-Feld erweitert das Prinzip. Du nennst dort zwei bis fünf Konzepte, die im Artikel wirklich diskutiert werden. Wichtig ist die Ehrlichkeit: Wer mentions als Keyword-Stuffing missbraucht und Konzepte aufführt, die im Artikel nicht vorkommen, riskiert eine Abwertung des kompletten Blocks. LLM-Crawler pruefen die Konsistenz zwischen JSON-LD-Signal und Fließtext.

Das keywords-Feld ist der schwaechste, aber praktischste Hebel. Hier gehören die exakten Long-Tail-Formulierungen hin, unter denen Nutzer wirklich suchen. Nicht nur das Hauptkeyword. Die drei bis fünf Long-Tail-Varianten aus deinem Query-Fan-Out-Recherche gehören mit rein, weil sie das AI-Search-Matching schaerfen.

Zusammen entsteht ein dreidimensionales Signal: about setzt den Haupt-Themenknoten, mentions setzt die Nachbar-Konzepte, keywords setzt die konkreten Suchformulierungen. Ein LLM, das über diese drei Felder liest, hat eine deutlich bessere Chance, deinen Artikel als richtige Antwort zu selektieren als ein LLM, das den gleichen Text nur aus dem Fließtext ableiten muesste.

Quellen und weiterführende Literatur

• Google Search Central: Einführung in strukturierte Daten und JSON-LD-Empfehlungen, 2026
• Schema.org: Organization, Article, FAQPage, HowTo, Speakable und Product Specifications, 2026
• Google: Rich Results Test, Structured Data Guidelines und AI-Overview Extraction Notes, 2026
• Wikidata: Q-Identifier für sameAs-Verknüpfungen von Personen und Organisationen, 2026
• Rank Math: Schema-Generator, Speakable-Custom-Fields und Person-Schema-Integration, 2026
• Perplexity Engineering: How Perplexity Selects Sources for Answer Blocks, 2026
• Interne Verweise: AI Citations auf leventelci.de, Topical Authority auf leventelci.de, Query Fan-Out auf leventelci.de, Content Audit auf leventelci.de, Interne Verlinkung auf leventelci.de, Co-Occurrence auf leventelci.de, Perplexity SEO auf leventelci.de, ChatGPT SEO auf leventelci.de
• Vertiefung: Entity-SEO auf leventelci.de, Knowledge Graph auf leventelci.de, Schema Markup auf leventelci.de, LLMO auf leventelci.de, E-E-A-T für AI-Visibility auf leventelci.de

Geschrieben von

Levent Elci

AI-Visibility & Offpage SEO für DACH-Unternehmen

Seit 2014 baut Levent organische Sichtbarkeit für Marken auf. Heute mit Fokus auf Generative Engine Optimization, Brand-Mentions in ChatGPT, Gemini und Perplexity sowie redaktionelle Citation-Strategien. Operativ verantwortet er ein Portfolio von 165 WordPress-Sites.

LinkedIn-Profil ansehen