Schlagwort: Strukturierte Daten

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.

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
• 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