Relationship Schema für KI-Modelle: Entitäten richtig verlinken
In eigenen geaio-Scans sehen wir bei einem großen Teil der geprüften Websites ein vollständiges Organization-Schema, aber kaum eine Verknüpfung zu den Personen dahinter. Genau diese Lücke macht es KI-Systemen schwer, eine Marke eindeutig einzuordnen.
Definition: Relationship Schema bezeichnet den gezielten Einsatz von Schema.org-Eigenschaften wie
sameAs,affiliation,memberOf,founderoderauthor, um Personen, Organisationen und Inhalte explizit miteinander zu verknüpfen. Für KI-Systeme wie ChatGPT, Perplexity oder Google AI Overviews entscheidet diese Verknüpfung darüber, ob eine Entität isoliert bleibt oder im Wissensgraph klar identifizierbar wird.
Warum KI-Modelle explizite Verknüpfungen zwischen Personen und Organisationen brauchen
KI-Systeme arbeiten mit Entitäten, nicht mit Keywords. Ein Name wie “Müller GmbH” oder “Jens Schmidt” ist für ein Sprachmodell zunächst mehrdeutig, es gibt schließlich Dutzende Unternehmen und Personen mit ähnlichen Namen. Relationship Schema löst diese Mehrdeutigkeit auf, indem es maschinenlesbar festhält: Diese Person ist Gründer dieser Organisation, dieser Autor gehört zu dieser Redaktion, dieses Profil ist dasselbe wie jenes auf LinkedIn oder Wikidata.
Laut Google Search Central-Dokumentation zu Organization-Structured-Data gehören Eigenschaften wie sameAs, founder, address und contactPoint zu den empfohlenen Feldern, damit Google eine Organisation als eigenständige Entität im Knowledge Graph erfassen kann. Fehlen diese Verknüpfungen, bleibt die Organisation für Google und vergleichbare Systeme ein loses Bündel aus Textfragmenten statt einer zusammenhängenden Entität.
Genau das ist der Kern der beiden häufigsten Probleme, die Website-Betreiber an geaio herantragen: KI-Systeme erkennen die Marke nicht zuverlässig, oder es entsteht gar kein Knowledge Panel. Beides hängt oft nicht am Content, sondern an fehlenden oder unvollständigen Beziehungsdaten.
Ansatz 1: Manuelles JSON-LD für Personen-Organisation-Beziehungen
Der direkteste Weg ist handgeschriebenes JSON-LD im <head> der wichtigsten Seiten. Du definierst ein Organization-Objekt mit founder, employee oder member, verknüpfst Personen per Person-Objekt mit affiliation oder memberOf zurück zur Organisation und ergänzt bei Autoren zusätzlich author auf Artikelebene.
Der Vorteil: volle Kontrolle über jede Eigenschaft, keine Abhängigkeit von einem Plugin-Update, und du kannst branchenspezifische Rollen (OrganizationRole mit Start- und Enddatum) sauber abbilden. Der Nachteil ist der Pflegeaufwand. Ändert sich eine Position, ein Standort oder ein Team, muss das JSON-LD manuell nachgezogen werden, sonst entstehen Widersprüche zwischen Website und Realität, die KI-Systeme eher als Vertrauensproblem denn als Marketing-Nachlässigkeit werten.
Ansatz 2: CMS-Plugins für automatisierte Schema-Pflege
Für WordPress, Typo3 oder vergleichbare Systeme gibt es Plugins, die Organization- und Person-Schema aus vorhandenen Feldern (Autorenprofil, Impressum, Team-Seite) generieren. Das reduziert den manuellen Aufwand erheblich und sorgt dafür, dass neue Autoren oder Standorte automatisch ins Schema einfließen.
Der Nachteil: Die meisten Plugins decken die Standardfelder ab, aber nicht die feineren Relationship-Properties wie knowsAbout, OrganizationRole oder mehrstufige memberOf-Ketten bei Tochtergesellschaften. Wer über eine einfache Autor-Organisation-Verknüpfung hinausgeht, landet meist doch wieder bei individuellem JSON-LD, das das Plugin ergänzt oder überschreibt. Zudem hängt die Qualität stark vom jeweiligen Plugin ab, hier lohnt sich ein Blick in den generierten Quellcode statt blindem Vertrauen in die Marketing-Beschreibung.
Ansatz 3: Externe Profile als Anker: sameAs und Wikidata
Der dritte Ansatz setzt nicht primär auf die eigene Website, sondern auf externe, bereits vertrauenswürdige Profile. Über sameAs verweist du von deinem Organization- oder Person-Schema auf Wikidata-Einträge, LinkedIn-Unternehmensseiten, Handelsregister-Profile oder Branchenverzeichnisse. Diese Quellen dienen als Referenzpunkte, an denen KI-Systeme die Identität deiner Entität abgleichen können.
Laut Schema.org-Vokabular ist sameAs als URL definiert, die eindeutig auf eine Referenzseite verweist, welche die Identität der beschriebenen Entität bestätigt. Besonders Wikidata gilt in der SEO-Praxis als starker Anker, weil es eine der Datenquellen ist, die in Googles Knowledge-Graph-Pipeline einfließen. Der Nachteil: Einen Wikidata-Eintrag anzulegen und zu pflegen ist ein eigener Prozess mit eigenen Relevanzkriterien, das lässt sich nicht einfach nebenbei erledigen, und kleine Unternehmen erfüllen die Relevanzschwelle mancher Verzeichnisse schlicht nicht.
Ein Rechenbeispiel zur Einordnung: Ein Unternehmen mit fünf Autoren, drei Standorten und zwei Marken müsste ohne jede Automatisierung rein rechnerisch über 15 einzelne Person-Organisation- und Standort-Verknüpfungen pflegen, plus die dazugehörigen sameAs-Referenzen. Ohne Plugin oder Vorlage wächst der Pflegeaufwand linear mit jeder neuen Person oder jedem neuen Standort, das ist der Punkt, an dem viele Teams das Schema irgendwann nicht mehr aktuell halten.
| Ansatz | Aufwand | Kontrolle über Details | Skalierbarkeit | Wann sinnvoll |
|---|---|---|---|---|
| Manuelles JSON-LD | Hoch, laufende Pflege nötig | Sehr hoch | Gering bei vielen Entitäten | Kleine Websites, wenige Personen/Standorte |
| CMS-Plugin | Mittel, Einrichtung einmalig | Mittel, Standardfelder | Hoch bei einfachen Strukturen | Blogs, Redaktionen mit vielen Autoren |
| Externe Profile (sameAs/Wikidata) | Mittel bis hoch, externer Prozess | Gering auf eigener Seite | Hoch, wirkt entitätsweit | Marken mit Bekanntheitsanspruch, Knowledge-Panel-Ziel |
Was für die meisten Websites den besten Kompromiss bietet: Kombination aus Plugin und sameAs
In der Praxis schließen sich die drei Ansätze nicht aus, sie ergänzen sich. Unsere Einordnung bei geaio: Ein CMS-Plugin für die Grundlast aus Autoren- und Organisationsdaten spart am meisten Zeit, während sameAs-Verknüpfungen zu Wikidata, LinkedIn und Handelsregister die Entität nach außen absichern. Manuelles JSON-LD bleibt dort sinnvoll, wo es um Sonderfälle geht, etwa Tochtergesellschaften, Gründerrollen mit Zeitraum oder Fachexpertise über knowsAbout.
Wie stark einzelne sameAs-Quellen tatsächlich in die Entity-Resolution von ChatGPT, Perplexity oder Claude einfließen, ist öffentlich nicht einheitlich dokumentiert. Für Google lässt sich die Nähe zum Knowledge Graph über offizielle Dokumentation zumindest indirekt begründen, für die übrigen Systeme bleibt es eine begründete Annahme statt ein belegter Mechanismus. Wer auf Nummer sicher gehen will, verzichtet nicht auf eine der drei Quellen, sondern kombiniert sie und beobachtet über Zeit, ob sich die Zitierhäufigkeit verändert.
Wichtig ist außerdem die Rückkopplung ins bestehende Markup: Eine saubere Marken-Entität als Knowledge Graph Actor funktioniert nur, wenn die sameAs-Verknüpfungen tatsächlich konsistent auf dieselbe Entität zeigen. Und wenn am Ende ein Knowledge Panel entstehen soll, ist Relationship Schema die Vorstufe dazu und ergänzt andere Signale wie Presseerwähnungen oder Backlinks.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Relationship Schema und normalem Organization-Schema?
Organization-Schema beschreibt eine einzelne Entität mit Eigenschaften wie Name, Adresse oder Logo. Relationship Schema geht einen Schritt weiter und verknüpft diese Entität explizit mit anderen Entitäten, etwa Personen über founder oder employee, andere Organisationen über memberOf, oder externe Profile über sameAs.
Welche Schema.org-Eigenschaften eignen sich am besten, um Personen und Organisationen zu verknüpfen?
Am häufigsten genutzt werden sameAs für externe Identitätsnachweise, affiliation und memberOf für die Zugehörigkeit einer Person zu einer Organisation, founder beziehungsweise employee für die Gegenrichtung sowie author auf Artikelebene. Für komplexere Rollen mit Zeitraum eignet sich OrganizationRole.
Reicht sameAs allein aus, um einen Knowledge Panel zu bekommen?
Nein. sameAs ist ein Baustein unter mehreren. Google und andere Systeme berücksichtigen zusätzlich Bekanntheit, Presseerwähnungen, Backlink-Qualität und die Konsistenz der Daten über verschiedene Quellen hinweg. Relationship Schema erleichtert die Zuordnung, garantiert aber keinen Knowledge Panel.
Wie prüfe ich, ob meine Relationship-Schema korrekt von KI-Systemen erkannt wird? Technisch lässt sich das JSON-LD mit Googles Rich-Results-Test oder dem Schema Markup Validator prüfen. Ob ChatGPT, Perplexity oder Claude die Verknüpfung tatsächlich für Zitierungen nutzen, lässt sich nur indirekt über wiederholte Prompts und Beobachtung der Antworten über Zeit einschätzen, eine offizielle Prüfschnittstelle dafür gibt es bislang nicht.