Warum die Frage nach der Entity-ID bei GEO wichtiger wird
Wer sich intensiver mit Generative Engine Optimization (GEO), strukturierten Daten und Knowledge Graphs beschäftigt, landet früher oder später bei einer grundlegenden Frage:
Wo lebt eigentlich die digitale Identität einer Entität?
Unternehmen, Personen, Marken, Organisationen, Standorte oder Projekte lassen sich mit strukturierten Daten beschreiben. Über Eigenschaften und Beziehungen können diese Entitäten miteinander verbunden werden.
In der praktischen Umsetzung passiert das heute häufig direkt auf einer Website. Ein CMS, ein SEO-Plugin oder eine individuelle Schema.org-Implementierung erzeugt beispielsweise eine @id für eine Organisation:
https://example.com/#organization
Solange diese Website und ihre technische Struktur unverändert bestehen, erscheint das zunächst logisch.
Problematisch wird es, sobald man die Website nicht mehr als dauerhaften Mittelpunkt der Identität betrachtet.
Websites ändern sich. Entitäten nicht unbedingt.
- Eine Unternehmenswebsite kann heute mit WordPress betrieben werden und in einigen Jahren auf einem völlig anderen System basieren.
- Ein Unternehmen kann mehrere Websites betreiben.
- Ein Shop kann auf Shopify laufen, während die Unternehmenswebsite WordPress verwendet und weitere Inhalte über ein anderes System veröffentlicht werden.
- Domains können wechseln. Websites werden zusammengeführt oder aufgeteilt. SEO-Plugins werden ausgetauscht. URL-Strukturen ändern sich.
Die reale Entität dahinter bleibt jedoch dieselbe.
Eine Organisation wird nicht zu einer neuen Organisation, nur weil ihre Website neu gebaut wurde.
Dasselbe gilt für Personen, Marken oder andere Entitäten.
Trotzdem koppeln wir ihre digitale Identität häufig genau an jene technische Infrastruktur, die vergleichsweise kurzlebig ist.
Wenn das CMS die Identität definiert
Nehmen wir ein vereinfachtes Beispiel.
Ein Unternehmen verwendet WordPress und ein SEO-Plugin erzeugt folgende Entity-ID:
https://example.com/#organizationAndere strukturierte Daten dieser Website können anschließend auf diese ID verweisen.
Technisch ist daran zunächst nichts falsch.
Aber was passiert bei einem Wechsel des Systems?
Vielleicht erzeugt das neue System:
https://example.com/#/schema/organization/123Oder:
https://example.com/about/#organizationOder es existiert nach dem Relaunch überhaupt keine entsprechende ID mehr.
Aus Sicht eines einzelnen Webseitenprojekts ist das möglicherweise nur ein Implementierungsdetail.
Aus Sicht eines langfristigen Entity Graphs stellt sich aber eine andere Frage:
Warum sollte sich die Referenz auf eine Entität ändern, wenn sich lediglich die Software ändert, mit der sie beschrieben wird?
Noch deutlicher wird das Problem bei mehreren Systemen
Viele Unternehmen haben längst nicht mehr nur eine Website.
Ein denkbares Setup könnte so aussehen:
Unternehmenswebsite
WordPress
Onlineshop
Shopify
Karriereportal
externes Recruiting-System
Newsroom
eigenständiges CMS
weitere Länder-Websites
unterschiedliche PlattformenAlle diese Systeme können dieselbe Organisation beschreiben.
Wenn jedes System seine eigene Entity-ID erzeugt, entstehen mehrere technische Identitäten für dieselbe reale Entität.
Natürlich lassen sich diese wiederum über sameAs oder andere Mechanismen miteinander verbinden.
Man könnte sich aber auch eine grundsätzlichere Frage stellen:
Sollten die verschiedenen Systeme überhaupt jeweils die Identität der Entität definieren müssen?
Identity Layer und Presentation Layer
Eine mögliche Betrachtungsweise ist die Trennung von Identität und Darstellung.
Identity Layer
Der Identity Layer beantwortet Fragen wie:
- Welche Entität ist gemeint?
- Welche persistente ID besitzt sie?
- Um welchen Typ von Entität handelt es sich?
- Welche Beziehungen bestehen zu anderen Entitäten?
- Welche externen Identifikatoren und Referenzen gehören zu ihr?
Die Identität sollte dabei möglichst langlebig sein.
Presentation Layer
Der Presentation Layer beschreibt dagegen, wo und wie die Entität aktuell dargestellt wird.
Das kann beispielsweise sein:
- eine Unternehmenswebsite,
- ein Onlineshop,
- ein CMS,
- eine Profilseite,
- eine App,
- ein Presseportal,
- eine Microsite.
Diese Systeme dürfen sich verändern.
Die zugrunde liegende Identität müsste das nicht zwangsläufig tun.
Die Website würde eine Entität dann nicht mehr ausschließlich selbst definieren
Aus dieser Trennung ergibt sich ein anderes Architekturmodell.
Heute sieht es häufig vereinfacht so aus:
Website
↓
definiert Entity-ID
↓
beschreibt EntitätMit einer unabhängigen Identität könnte das Modell stattdessen so aussehen:
Persistente Entity-ID
↓
Entität
↑
┌─┼─┐
│ │ │
Website Shop AppDie verschiedenen Systeme würden dieselbe Entität referenzieren.
Die Website wäre damit weiterhin eine wichtige Quelle für Informationen über die Entität – aber nicht zwingend der einzige Ort, an dem deren Identität definiert wird.
Welche Rolle spielt @id?
Schema.org verwendet JSON-LD @id, um einen Knoten eindeutig innerhalb eines Graphen referenzierbar zu machen.
Beispielsweise:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example GmbH"
}Andere Knoten können anschließend dieselbe Organisation über diese URI referenzieren.
Genau diese Eigenschaft macht @id für Entity Graphs interessant: Informationen können auf dieselbe identifizierte Entität zeigen.
Die entscheidende Architekturfrage ist daher nicht, ob @id verwendet werden sollte.
Sondern:
Wie persistent ist die URI, die wir als @id verwenden?
@id und sameAs erfüllen unterschiedliche Aufgaben
In Diskussionen über Entity SEO und GEO werden @id und sameAs teilweise sehr ähnlich behandelt. Sie erfüllen jedoch unterschiedliche Funktionen.
@id identifiziert den jeweiligen Knoten im JSON-LD-Graphen.
sameAs kann dagegen auf andere Seiten oder Identifikatoren verweisen, die dieselbe Entität repräsentieren.
Vereinfacht:
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example GmbH",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.wikidata.org/wiki/Q123456"
]
}Das ermöglicht es, unterschiedliche Repräsentationen einer Entität miteinander in Beziehung zu setzen.
Für eine langfristige Identitätsarchitektur bleibt jedoch die Frage bestehen, welche Referenz als stabile Identität dienen soll.
Muss eine persistente Entity-ID auf der eigenen Domain liegen?
Auf den ersten Blick erscheint eine URI auf der Unternehmensdomain als ideale Lösung.
Das hat durchaus Vorteile: Das Unternehmen kontrolliert die Domain und kann die URI selbst verwalten.
Aber auch Domains sind nicht zwangsläufig permanent.
Unternehmen fusionieren. Marken werden verkauft. Domains ändern sich nach Rebrandings. Geschäftsbereiche werden ausgegliedert. Projekte wechseln Betreiber.
Damit entsteht ein interessanter Zielkonflikt:
Eine Entity-ID sollte einerseits unter möglichst verlässlicher Kontrolle stehen.
Andererseits sollte sie möglichst unabhängig von den Systemen und Strukturen sein, die sich im Laufe der Zeit verändern können.
Eine universelle Antwort darauf gibt es nicht.
Aber genau deshalb lohnt es sich, Persistenz als eigene Anforderung an Entity-IDs zu betrachten.
Was müsste eine persistente Entity-ID leisten?
Wenn man Entity Identity unabhängig vom jeweiligen CMS betrachtet, ergeben sich einige sinnvolle Eigenschaften.
Eine solche ID sollte:
- eine Entität dauerhaft und eindeutig referenzieren können,
- unabhängig von einem bestimmten CMS oder Plugin funktionieren,
- nicht von einer veränderlichen URL-Struktur abhängen,
- von unterschiedlichen Websites und Systemen referenzierbar sein,
- maschinenlesbar sein,
- Beziehungen zu anderen Entitäten ermöglichen,
- und auch nach einem Relaunch oder Systemwechsel dieselbe Entität bezeichnen.
Dabei geht es nicht darum, sämtliche Informationen über eine Entität unveränderlich zu machen.
Im Gegenteil.
Namen können sich ändern. Beschreibungen können aktualisiert werden. Websites können wechseln. Beziehungen können entstehen oder enden.
Persistent sein sollte die Identität – nicht zwangsläufig ihre Beschreibung.
Vielleicht denken wir bei GEO eine Ebene zu weit unten
Viele aktuelle GEO-Diskussionen drehen sich um die Frage:
Was muss ich auf meiner Website ändern?
Welches Schema brauche ich? Welches Plugin? Welche strukturierten Daten? Welche Inhalte?
Das sind berechtigte Fragen.
Vielleicht sollte davor aber eine grundlegendere stehen:
Welche Entitäten existieren überhaupt – und wie werden sie dauerhaft identifiziert?
Erst danach stellt sich die Frage, auf welchen Websites und in welchen Systemen diese Entitäten beschrieben werden.
Das würde bedeuten:
Die Identität gehört zur Entität. Die Darstellung gehört zur Website.
Ein CMS wäre dann nicht mehr der Ort, an dem die digitale Identität zwangsläufig entsteht, sondern eines von möglicherweise mehreren Systemen, die diese Identität verwenden.
Warum ist das für GEO interessant?
Generative Engine Optimization beschäftigt sich unter anderem mit der Frage, wie Informationen über Unternehmen, Personen, Produkte und andere Entitäten von maschinellen Systemen verstanden und miteinander in Beziehung gesetzt werden können.
Strukturierte Daten und Knowledge Graphs sind dafür interessante technische Bausteine.
Dabei sollte allerdings zwischen einer belegbaren technischen Eigenschaft und einer SEO-Behauptung unterschieden werden:
Eine persistente Entity-ID garantiert weder Sichtbarkeit in KI-Systemen noch bessere Rankings.
Sie löst zunächst ein Architekturproblem.
Sie schafft eine stabile Referenz, über die dieselbe Entität über unterschiedliche Websites, Systeme und Zeiträume hinweg bezeichnet werden kann.
Ob und wie einzelne Suchmaschinen oder generative Systeme solche Referenzen verwenden, ist eine davon getrennte Frage.
Gerade diese Trennung halte ich für wichtig.
Eine einfache Frage als Architekturtest
Vielleicht lässt sich die Robustheit eines Entity Graphs deshalb mit einem relativ einfachen Gedankenexperiment testen:
Was passiert, wenn morgen die komplette Website verschwindet?
Nicht nur ein Plugin.
Nicht nur das Theme.
Sondern CMS und Domain.
Wären die Entity-IDs danach noch gültig?
Könnten andere Systeme weiterhin dieselben Entitäten referenzieren?
Und ließe sich der Entity Graph anschließend mit einer neuen Website weiterverwenden, ohne neue Identitäten für dieselben realen Entitäten erzeugen zu müssen?
Wenn die Antwort darauf Nein lautet, dann haben wir möglicherweise keinen persistenten Entity Graph aufgebaut.
Sondern einen Website Graph.
Fazit
Websites sind Darstellungen von Entitäten.
Sie sind nicht zwangsläufig die Entitäten selbst.
Wenn wir Entity-basierte Architekturen langfristig denken wollen, erscheint es deshalb sinnvoll, die Lebensdauer einer Entity-ID nicht automatisch an die Lebensdauer eines CMS, eines Plugins oder einer Website-Implementierung zu koppeln.
Die technische Umsetzung kann dabei unterschiedlich aussehen.
Der grundlegende Gedanke bleibt jedoch derselbe:
Websites ändern sich. Systeme ändern sich. Entitäten können bestehen bleiben. Ihre Identität sollte deshalb ebenfalls bestehen bleiben können.
Und daraus ergibt sich für mich eine der interessanteren Architekturfragen rund um GEO und Knowledge Graphs:
Wo leben eure Entity-ID und der dazugehörige Entity Graph – und würden sie einen kompletten CMS- und Domainwechsel überstehen?
