Fallbeispiel: Knowledge-Graph-Setup für eine Person

Suchsysteme arbeiten nicht mit Namen, sondern mit Entitäten — eindeutig unterscheidbaren Dingen, denen Eigenschaften und Beziehungen zugeordnet sind. Ein Name allein leistet das nicht: Mehrere Personen können ihn tragen, dieselbe Person erscheint in verschiedenen Quellen unterschiedlich geschrieben, und eine Rolle in einem Profil widerspricht der in einem anderen.

Solange diese Mehrdeutigkeit besteht, ordnet ein System Erwähnungen nicht zusammen. Presse, Website, Profile und Firmenangaben bleiben getrennte Fundstücke statt Belege über dieselbe Person. Der Aufbau einer Personen-Entität besteht deshalb vor allem darin, Mehrdeutigkeit zu beseitigen.

Dieses Fallbeispiel beschreibt das Setup an unserem eigenen Gründer. Das hat einen praktischen Grund: Wir können hier offenlegen, was wir tatsächlich getan haben, ohne Kundendaten auszubreiten.

Den Kern bildet eine einzige, dauerhafte Kennung für die Person: eine domainbasierte canonical @id im strukturierten Datenblock, die auf allen Seiten der Website identisch ist und sich nicht ändert. Sie ist der Ankerpunkt, auf den alle anderen Knoten verweisen.

Wichtiger als ihr konkreter Wortlaut ist die Regel dahinter: Es gibt genau einen Person-Knoten, nicht mehrere. Werden auf einzelnen Seiten zusätzliche Person-Knoten ohne stabile Kennung ausgegeben, entstehen aus einer Person mehrere Kandidaten — und das Setup arbeitet gegen sich selbst. Die Organisation verweist über ihre Gründerangabe auf denselben Anker zurück, sodass die Beziehung zwischen Person und Unternehmen für einen Parser eindeutig auflösbar ist.

Alle Knoten liegen dafür in einem gemeinsamen Graphen statt in getrennten Blöcken. Getrennte Blöcke stellen keine Beziehung zueinander her; erst ein gemeinsamer Kontext macht Verweise zwischen ihnen auflösbar.

Strukturierte Daten beschreiben, was auf einer Seite steht — sie ersetzen es nicht. Angaben, die ausschließlich im Markup auftauchen und für den Leser nirgends sichtbar sind, gelten als unbestätigt und können als irreführend gewertet werden.

Deshalb gehören Name, Rolle, Unternehmenszugehörigkeit und Ort zuerst sichtbar auf die Seite, in derselben Schreibweise wie im Markup. Auf unserer Website ist Esat Beluli als Gründer von Hypex Media genannt; die Angabe im strukturierten Datenblock spiegelt genau diese Formulierung, statt eine eigene zu erfinden.

Dieselbe Disziplin gilt für Rollenbezeichnungen insgesamt: Wer eine Funktion im Markup ausweist, muss sie auch zeigen können — und darf nur ausweisen, was rechtlich zutrifft.

Eine Entität wird durch unabhängige Quellen bestätigt. Im sameAs-Feld stehen deshalb kontrollierte Profilseiten: bei uns unter anderem der Wikidata-Eintrag, das LinkedIn-Profil und der Crunchbase-Eintrag zur Person.

Der Wikidata-Eintrag zu Esat Beluli wird unter der Kennung Q141065524 geführt. Wir haben ihn am 19. September 2026 gegen die Wikidata-Schnittstelle geprüft: Label „Esat Beluli“, Beschreibung „deutscher Unternehmer und Gründer“. Geprüft wurde damit, ob der Eintrag tatsächlich diese Person bezeichnet. Ein Verweis auf die falsche Entität wäre schädlicher als gar keiner, weil er zwei verschiedene Personen zu einer verschmilzt.

Ergänzend prüfen wir in der Google Search Console, ob die Seite mit dem Personen-Markup abgerufen wird, ob die strukturierten Daten fehlerfrei erkannt werden und ob die ausgelieferte Fassung der entspricht, die wir veröffentlicht haben. Das ist eine technische Kontrolle des Setups — kein Nachweis darüber, wie Google die Entität bewertet.

Bei der Recherche tauchen regelmäßig Google-interne Kennungen für Knowledge-Graph-Einträge auf, erkennbar als kgmid-Parameter in einer Google-Such-URL. Es liegt nahe, sie als Beleg in sameAs aufzunehmen. Genau das tun wir nicht.

Zwei Gründe. Erstens ist eine Such-URL keine kontrollierte Profilseite, sondern eine Trefferansicht — sie erfüllt nicht, wofür sameAs gedacht ist. Zweitens belegen mehrere gleichnamige Treffer nicht, dass es dieselbe Person ist; wer sie verknüpft, behauptet eine Identität, die er nicht geprüft hat.

Solche Kennungen sind für uns interne Diagnosewerte: nützlich, um zu beobachten, wie ein Suchsystem eine Person gerade einordnet, aber nichts, was ausgeliefert wird. Sie bleiben in der internen Dokumentation und erscheinen auf keiner Seite.

Ein Knowledge Panel lässt sich nicht bestellen und nicht herbeiarbeiten. Ob Google für eine Person ein Panel ausspielt, entscheidet Google allein — abhängig von der Datenlage, von unabhängiger Berichterstattung und von Kriterien, die nicht offengelegt sind. Wer ein Panel zusagt, verspricht eine fremde Entscheidung.

Was ein sauberes Setup leistet, ist etwas anderes: Es macht eine Person für Systeme eindeutig auflösbar und sorgt dafür, dass vorhandene Belege derselben Entität zugeordnet werden können. Ob und wann daraus etwas Sichtbares entsteht, ist damit nicht gesagt.

Ebenso wenig ersetzt das Setup öffentliche Relevanz. Strukturierte Daten beschreiben eine Person korrekt; sie erzeugen keine Berichterstattung und keine Bedeutung, die es nicht gibt.