Wikidata und der Google Knowledge Graph: Die Entitätsschicht hinter Knowledge Panels und KI-Antworten

Die meisten Menschen, die uns nach einem „Google Knowledge Panel" oder einer „korrekten Darstellung in ChatGPT" fragen, denken, sie stellen eine Frage über Inhalte. Das tun sie nicht. Sie fragen nach Entitäten — ob die Systeme hinter Suche und KI ihr Unternehmen, ihren Gründer oder ihr Produkt als eigenständiges Ding in der Welt erkennen, mit einer stabilen Identität und einem bekannten Satz an Fakten.

Diese Erkennungsschicht hat einen Namen. Mehrere Namen sogar — und die meisten verwenden sie austauschbar, obwohl sie sehr unterschiedliche Dinge bedeuten. Wikipedia ist nicht Wikidata. Wikidata ist nicht der Google Knowledge Graph. Und keines davon garantiert ein Knowledge Panel.

Dieser Artikel entwirrt all das. Es ist der Leitfaden, den wir Kunden schicken, die überzeugt ankommen, sie bräuchten einen Wikipedia-Artikel — obwohl sie, zumindest zuerst, eine saubere Wikidata-Entität brauchen. Er ist ehrlich darüber, was die Entitätsschicht leisten kann, und klar darüber, was sie nicht kann.

Drei verschiedene Dinge, klar definiert

Trennen wir die drei Systeme, die ständig durcheinandergebracht werden — denn fast jeder Fehler im weiteren Verlauf entsteht durch ihre Verwechslung.

Wikipedia ist eine Enzyklopädie. Es sind Texte — von Menschen verfasste Artikel, Absätze, Quellenangaben, neutraler Standpunkt. Um einen Wikipedia-Artikel zu haben, muss ein Thema Relevanz (Wikipedia:Notability — engl. „Beachtlichkeit") nachweisen: erhebliche Berichterstattung in unabhängigen, zuverlässigen Sekundärquellen. Die Hürde ist hoch und wird immer höher. Die meisten Unternehmen erfüllen die Kriterien nicht — und das ist so gewollt. Wikipedia ist für Themen, über die die Welt bereits ausführlich geschrieben hat.

Wikidata ist eine strukturierte Datenbank. Es sind keine Texte; es sind Fakten in einem maschinenlesbaren Format. Während Wikipedia einen Artikel über den Eiffelturm hat, hat Wikidata einen Eintrag — einen Datensatz mit einer Kennung (Q243) und einer Liste von Aussagen: Es ist eine Instanz von „Turm", es befindet sich in Paris, es wurde von Gustave Eiffel entworfen, seine Höhe beträgt 330 Meter usw. Jeder dieser Fakten ist ein Eigenschaft-Wert-Paar, im Idealfall mit einer Quellenangabe belegt. Wikidata ist ein Schwesterprojekt von Wikipedia, betrieben von derselben Wikimedia Foundation — aber es ist grundlegend anders, und entscheidend: es hat eine niedrigere Aufnahmehürde. Dazu mehr weiter unten.

Der Google Knowledge Graph ist Googles eigene, private Datenbank von Entitäten und den Beziehungen zwischen ihnen. Er wurde 2012 mit dem Satz „things, not strings" (deutsch: „Dinge, nicht Zeichenketten") eingeführt — Google hörte auf, „Apple" als eine fünfbuchstabige Zeichenkette zu behandeln, und begann, es als eine Entität zu behandeln, die die Frucht, das Unternehmen oder das Plattenlabel sein kann — jeweils mit eigenen Fakten und Verbindungen. Der Knowledge Graph speist das Knowledge Panel (das Kästchen rechts in einem Suchergebnis) und informiert das Entitätsverständnis über alle Google-Produkte hinweg. Er wird von Wikipedia und Wikidata informiert, unter anderem — aber Google besitzt ihn, kontrolliert ihn, und man kann ihn nicht direkt bearbeiten.

Die Beziehung in einem Satz: Wikipedia und Wikidata sind offene, öffentliche, bearbeitbare Quellen, die Google in seinen eigenen proprietären Knowledge Graph einspeist — den es dann (nach eigenem Ermessen) nutzt, um Knowledge Panels darzustellen und KI-Antworten zu informieren.

Die Verwechslung dieser drei führt zu vorhersehbaren Fehlern. Menschen versuchen, ihr Knowledge Panel direkt zu „bearbeiten" — das geht nicht; man kann es nur beanspruchen und Änderungen vorschlagen. Menschen nehmen an, ein Wikidata-Eintrag werde einen Wikipedia-Artikel erzeugen — das wird er nicht; es sind getrennte Prozesse mit getrennten Hürden. Und Menschen nehmen an, irgendeines davon garantiere ein Panel — das tut es nicht; Google trifft immer die endgültige Entscheidung.

Wie strukturierte Daten Google und LLMs speisen

Um zu verstehen, warum Wikidata über seine Gewichtsklasse hinausschlägt, muss man verstehen, wie es aufgebaut ist — denn die Struktur ist genau das, was Maschinen wollen.

Jeder Wikidata-Eintrag hat eine QID (engl. für „Wikidata-Kennung"), einen eindeutigen Bezeichner wie Q95 (Google), Q312 (Apple Inc.) oder Q42 (Douglas Adams). Die QID ist die permanente Adresse der Entität. Sie ändert sich nie, auch wenn sich das Label ändert — und sie ist sprachunabhängig: Q42 ist Douglas Adams, ob die Benutzeroberfläche auf Englisch, Japanisch oder Arabisch eingestellt ist. Das ist das Wichtigste, was Wikidata liefert: einen stabilen, eindeutigen Bezeichner für ein Ding.

Auf der QID aufbauend sitzen Aussagen (engl. statements), aufgebaut aus Eigenschaften (engl. properties) und Werten (engl. values). Eigenschaften sind selbst identifiziert (P31 ist „ist ein/eine", P159 ist „Hauptsitz", P1448 ist „offizieller Name", P856 ist „offizielle Website"). Der Fakt „Apple Inc. hat seinen Hauptsitz in Cupertino" wird also gespeichert als Q312 → P159 → Q190080 (Cupertino). Maschinen müssen keinen Satz parsen; sie lesen ein Tripel.

Das ist für zwei Konsumenten relevant:

• Google. Der Knowledge Graph ist selbst ein Graph von Entitäten und Tripeln. Das Format von Wikidata bildet sich fast direkt darauf ab — weshalb Google Wikidata in großem Maßstab einspeist und warum ein gut aufgebauter Wikidata-Eintrag eines der klareren Signale ist, die man über die Identität, den Typ und die Kernattribute einer Entität senden kann. Google stützt sich auch auf Wikidata zur Disambiguierung — um Ihr Unternehmen von den fünf anderen Unternehmen mit ähnlichem Namen zu unterscheiden.
• Große Sprachmodelle (LLMs). Wenn ein LLM antwortet „Wer hat [Unternehmen] gegründet?" oder „Wo hat [Unternehmen] seinen Hauptsitz?", zieht es Muster aus seinen Trainingsdaten heran. Wikipedia ist die am stärksten gewichtete Textquelle in den meisten Trainingskorpora, und Wikidata erscheint zunehmend in den strukturierten Datensätzen, die für Verankerung, Retrieval und Wissensdatenbank-Abfragen verwendet werden. Eine konsistente, gut referenzierte Entität wird mit weit höherer Wahrscheinlichkeit korrekt dargestellt — und weit seltener mit einer gleichnamigen Entität verwechselt — als eine, die nur als verstreute, unstrukturierte Erwähnungen im offenen Web existiert.

Das ist die ehrliche Version von „KI-Sichtbarkeit", und sie ist die Grundlage von entitätsbasiertem SEO und Knowledge-Graph-Arbeit: Man injiziert keine Inhalte in ChatGPT oder Gemini. Niemand kann das. Was man tun kann, ist saubere, maschinenlesbare, gut belegte Infrastruktur aufbauen, die es wahrscheinlicher macht, dass die Maschinen die eigene Entität korrekt beschreiben. Wir haben mehr über diese Unterscheidung in unserer KI-Sichtbarkeits-Arbeit geschrieben — der Hebel ist Quellenqualität und strukturierte Daten, nicht Prompt-Manipulation.

Die niedrigere Relevanzhürde von Wikidata

Das ist der Teil, den die meisten Menschen nicht kennen — und der Teil, der den Kreis der tatsächlich Begünstigten erweitert.

Wikipedia erfordert Relevanz (Wikipedia:Notability) — das Thema muss bekannt genug sein, sodass unabhängige Quellen es ausführlich behandelt haben. Wikidata erfordert etwas weit Schwächeres: grob gesagt nachweisbare Existenz und Identifizierbarkeit, plus entweder einen Sitelink zu einer bestehenden Wikimedia-Seite, einen Verweis auf eine seriöse externe Quelle oder strukturelle Notwendigkeit zur Beschreibung anderer Einträge.

Das noch einmal lesen — denn der Unterschied ist der eigentliche Punkt. Wikipedia fragt: „Ist dieses Thema wichtig genug, dass die Welt darüber geschrieben hat?" Wikidata fragt: „Können wir nachweisen, dass dieses Ding existiert, und auf eine Quelle verweisen, die das bestätigt?" Das sind völlig verschiedene Schwellen.

In der Praxis bedeutet das: Ein mittelgroßes Unternehmen, das bei Wikipedia abgelehnt würde — nicht genug unabhängige redaktionelle Berichterstattung — kann oft einen legitimen Wikidata-Eintrag haben, sofern seine Existenz und seine Kernfakten durch glaubwürdige Quellen nachweisbar sind: ein Handelsregistereintrag, eine Regulierungsmeldung, ein Authority-Record, etablierte externe Datenbanken. Der Eintrag macht das Unternehmen nicht bekannt und fabriziert keine Relevanz. Aber er gibt der Entität eine QID, eine stabile Identität und einen Satz maschinenlesbarer Fakten, die der Knowledge Graph und LLMs lesen können.

Ein paar ehrliche Einschränkungen, damit niemand das überinterpretiert:

• „Niedrigere Hürde" bedeutet nicht „keine Hürde". Wikidata hat weiterhin Relevanzrichtlinien, und Einträge für nicht-relevante Themen ohne seriöse Quellen werden gelöscht. Man kann keinen Eintrag für eine Ein-Personen-Beratung mit null externem Fußabdruck anlegen und erwarten, dass er bestehen bleibt.
• Wikidata ist kein Werberaum. Es ist eine sachliche Datenbank. Für Marketingsprache ist kein Platz — und das zu Recht.
• Ein Wikidata-Eintrag allein ist ein schwächeres Signal als ein Wikipedia-Artikel. Er ist ein Fundament, kein Ziel.

Aber für eine große Gruppe von Unternehmen und Einzelpersonen, die real und nachweisbar sind, aber noch nicht Wikipedia-relevant — ist Wikidata der erreichbare Schritt auf der Entitätsebene, der heute tatsächlich machbar ist. Deshalb empfehlen wir ihn so oft als ersten Schritt.

Anatomie eines Google Knowledge Panels

Wenn ein Knowledge Panel erscheint, werden seine Felder aus mehreren Quellen zusammengestellt. Keine einzige Quelle „besitzt" das Panel. Zu verstehen, welches Feld typischerweise woher kommt, hilft zu erkennen, was es wert ist zu korrigieren — und wo Wikidata tatsächlich Einfluss hat.

Die folgende Tabelle ist ein allgemeiner Leitfaden, kein Vertrag. Google kombiniert Quellen, überschreibt sie und ändert sein Verhalten im Laufe der Zeit. Behandle sie als „woher dieses Feld üblicherweise stammt", nicht als „woher es immer kommt".

Zwei Schlussfolgerungen. Erstens: Das Panel ist ein Komposit — eine Quelle zu verbessern, verbessert einen Ausschnitt. Wenn die Beschreibung falsch ist, ist das meist ein Wikipedia-Einleitungsproblem; wenn die Adresse falsch ist, ist das ein Google-Business-Profile-Problem; wenn das Gründungsdatum oder der Entitätstyp falsch ist, ist das oft ein Wikidata-Problem. Zweitens: Ob ein Panel überhaupt erscheint, ist Googles Entscheidung — getrieben hauptsächlich davon, ob Google zuversichtlich ist, dass die Entität real, eindeutig und relevant genug ist, um eines zu rechtfertigen. Wikidata und Wikipedia erhöhen dieses Vertrauen. Sie erzwingen das Ergebnis nicht.

Grundlagen des Entity-SEO: sameAs, Schema und Authority Records

Wikidata operiert nicht isoliert. Es sitzt in einem breiteren Netz von Identitätssignalen — und je mehr davon übereinstimmen, desto sicherer kann eine Suchmaschine die eigene Entität auflösen. Die Kernidee ist Bestätigung: dieselben Fakten, dieselben Bezeichner, die von mehreren unabhängigen Stellen auf dasselbe Ding zeigen.

Die praktischen Bausteine:

• schema.org-strukturierte Daten auf der eigenen Website. Die Startseite oder die Über-uns-Seite mit Organization- oder Person-Schema (in JSON-LD) zu markieren, teilt Google direkt mit, welche Entität die Seite repräsentiert — Name, Logo, Gründungsdatum und Schlüsselpersonen. Das ist der einzige Teil der Entitätsschicht, den man vollständig kontrolliert, auf Infrastruktur, die man besitzt.
• Die sameAs-Eigenschaft. Innerhalb dieser Schema-Auszeichnung ist sameAs ein Array von URLs, die auf andere autoritative Darstellungen derselben Entität verweisen — den Wikipedia-Artikel, den Wikidata-Eintrag, verifizierte soziale Profile, den Crunchbase- oder Branchendatenbank-Eintrag. sameAs ist im Wesentlichen die Aussage an Google: „All das verweist auf dasselbe Ding." Es ist das Bindegewebe zwischen der eigenen Website und dem offenen Entitätsgraphen.
• Authority Records (Normdaten). Das sind formale, institutionelle Bezeichner, die von Bibliotheken, Normungsgremien und Registern gepflegt werden. Sie sind externer Nachweis dafür, dass eine anerkannte Institution die eigene Entität katalogisiert hat. Die gebräuchlichsten:

Wikidata ist der Ort, an dem viele davon zusammenlaufen: Ein gut aufgebauter Eintrag verlinkt auf VIAF, ISNI, ORCID, LEI, GRID/ROR und andere über eigene Eigenschaften. Das verwandelt den Wikidata-Eintrag in einen Hub — einen einzigen Ort, an dem eine Maschine bestätigen kann, dass „diese QID" gleich „diesem LEI" gleich „diesem ORCID" gleich „diesem Wikipedia-Artikel" entspricht. Jeder übereinstimmende Bezeichner ist eine weitere Stimme dafür, dass die Entität real und einzigartig ist.

Man braucht nicht alle davon. Ein Forschungsinstitut sollte GRID/ROR haben; ein börsennotiertes Unternehmen sollte einen LEI haben; ein einzelner Wissenschaftler sollte eine ORCID haben. Der Punkt ist nicht, Abzeichen zu sammeln — sondern dass die Bezeichner, für die man sich legitimerweise qualifiziert, vorhanden und konsistent sein sollten, damit der gesamte Graph mit sich selbst übereinstimmt.

Typische Fehlerquellen

Die meisten Wikidata-Einträge, die nichts Nützliches bewirken, scheitern aus einer kleinen Zahl wiederkehrender Gründe. Wir sehen immer wieder dieselbe Handvoll.

• Verwaiste Einträge. Der Eintrag existiert, aber nichts verlinkt darauf, und er verlinkt auf nichts. Es ist ein schwebender Datensatz ohne Beziehungen. Der Knowledge Graph ist ein Graph — Entitäten erhalten Bedeutung durch ihre Verbindungen. Ein Eintrag ohne eingehende oder ausgehende Links zu anderen Entitäten ist für die Systeme, die Wikidata konsumieren, nahezu unsichtbar.
• Fehlende Quellenangaben. Aussagen ohne Quellen sind schwach und löschgefährdet. „Hauptsitz: Berlin" ohne Quellenangabe ist eine Behauptung; „Hauptsitz: Berlin" mit Verweis auf ein Handelsregister ist ein Fakt. Nicht belegte Einträge werden markiert, und unbelegte Aussagen werden von vorsichtigen nachgelagerten Konsumenten gestrichen oder ignoriert.
• Kein englischer Sitelink (oder gar kein Sitelink). Ein Sitelink verbindet den Wikidata-Eintrag mit einem Wikipedia-Artikel in einer bestimmten Sprache. Viele hochwertige Integrationen und ein Großteil von Googles Vertrauen stützen sich auf die englischsprachige Verbindung. Ein Eintrag ohne Sitelink zu irgendeiner Wikipedia-Ausgabe ist dünner und schwerer für Systeme zu vertrauen. (Deshalb ist ein Wikidata-Eintrag auch kein Ersatz für einen Wikipedia-Artikel, wenn einer erreichbar ist.)
• Ambige oder doppelte Entitäten. Zwei Einträge für dasselbe Unternehmen. Ein Gründer, verwechselt mit einem gleichnamigen Athleten. Ein Produkt, das im Unternehmenseintrag aufgegangen ist — oder aufgeteilt wurde, obwohl es das nicht sollte. Duplikate und Ambiguität sind Gift für die Entitätsauflösung — genau das Problem, das das QID-System verhindern soll. Das Zusammenführen von Duplikaten und die Disambiguierung kollidierender Entitäten ist oft die wertvollste Bereinigungsarbeit an einem bestehenden Eintrag.

Nichts davon ist exotisch. Es ist der Unterschied zwischen einem Eintrag, der existiert, und einem, der funktioniert — und diese Fehler zu erkennen ist der Großteil dessen, was sorgfältige Wikidata-Arbeit ausmacht.

Realistischer Zeitplan und was ein sauberer Eintrag auslösen kann — und was nicht

Lassen wir die Erwartungen ehrlich managen, denn hier entsteht der meiste Frust.

Einen gut aufgebauten Wikidata-Eintrag zu erstellen ist an sich nicht langsam — der Eintrag kann innerhalb eines Tages live sein. Was Zeit braucht, ist die nachgelagerte Weitergabe, und dieser Zeitplan liegt außerhalb jeder Kontrolle außer der von Google.

• Eintragserstellung: Stunden bis einen Tag für einen ordentlich strukturierten, belegten Eintrag.
• Indexierung und Aufnahme durch Google: typischerweise Wochen. Google nimmt Wikidata nach eigenem Zeitplan auf.
• Sichtbarer Effekt auf ein Knowledge Panel (falls eines erscheint): Wochen bis Monate — und nur, wenn Google entscheidet, dass die Entität ein Panel verdient.

Was ein sauberer Wikidata-Eintrag kann:

• Eine stabile QID und eine maschinenlesbare Identität für die Entität etablieren.
• Disambiguierung verbessern — die Wahrscheinlichkeit verringern, mit einer gleichnamigen Entität verwechselt zu werden.
• Genaue strukturierte Fakten beitragen (Entitätstyp, Gründer, Hauptsitz, offizielle Website, Bezeichner), die Google und LLMs lesen können.
• Das sameAs-Netz stärken, indem das eigene Schema auf der Website mit einem autoritativen externen Hub verbunden wird.
• Das Datengerüst für einen späteren Wikipedia-Artikel sauberer gestalten.

Was ein sauberer Wikidata-Eintrag nicht kann:

• Ein Knowledge Panel garantieren. Google trifft immer die endgültige Entscheidung, und viele einwandfreie Entitäten bekommen nie eines.
• Relevanz erschaffen. Er dokumentiert nachweisbare Fakten; er macht nicht wichtig — und ersetzt nicht die unabhängige Berichterstattung, die ein Wikipedia-Artikel erfordert.
• KI-Output injizieren oder kontrollieren. Er verbessert die Wahrscheinlichkeit einer korrekten Darstellung. Er erlaubt nicht, zu diktieren, was ein Modell sagt.
• Google-Business-Profile-Daten überschreiben. Adresse, Öffnungszeiten und Bewertungen kommen von anderswo.
• Überleben, wenn er werbend oder unbelegt ist. Wikidata ist eine sachliche Datenbank mit aktiven Redakteuren und Bots; ein minderwertiger Eintrag wird bereinigt.

Wenn eine Agentur behauptet, ein Wikidata-Eintrag garantiere ein Knowledge Panel oder kontrolliere, wie ChatGPT das Unternehmen beschreibt — das ist dieselbe Luft, vor der wir überall warnen. Das ehrliche Versprechen ist probabilistisch: Saubere Entitätsinfrastruktur erhöht die Wahrscheinlichkeit einer genauen, berechtigten Darstellung. Es ist kein Schalter, den man umlegt.

Wann Wikidata der richtige erste Schritt ist

Wikidata ist der richtige erste Schritt — bevor man einen vollständigen Wikipedia-Artikel anstrebt — in einer erkennbaren Reihe von Situationen:

• Das Thema ist real und nachweisbar, aber noch nicht Wikipedia-relevant. Der häufigste Fall. Es gibt einen Handelsregistereintrag, einen regulatorischen Fußabdruck, vielleicht etwas Fachpresseberichterstattung — aber nicht die 3–5 unabhängigen, ausführlichen Berichte, die ein Wikipedia-Artikel benötigt. Wikidata gibt der Entität jetzt eine legitime maschinenlesbare Identität, während man die Quellenbasis für Wikipedia später aufbaut.
• Es gibt ein Entitäts-Verwechslungsproblem. Google oder ein LLM vermischt das Unternehmen mit einem gleichnamigen Unternehmen, einer Person oder einem Produkt. Ein sauberer, disambiguierter Eintrag mit den richtigen Bezeichnern ist oft das direkteste Korrektiv.
• Man möchte das Entity-SEO-Fundament legen, bevor man größer ansetzt. Schema-Markup, sameAs und ein sauberer Wikidata-Hub sind das Fundament, auf dem ein Wikipedia-Artikel aufbauen sollte — kein Ersatz, sondern die Schicht, die alles andere kohärenter macht.
• Man ist unsicher, ob man sich überhaupt für Wikipedia qualifiziert. Genau dafür ist ein Wikipedia-Relevanz-Audit da. Wenn der Audit ergibt, dass die Quellen einen Artikel tragen, gut — dann Wikipedia-Seitenerstellung anstreben, mit Wikidata als Teil desselben Arbeitsablaufs. Wenn er ergibt, dass die Quellen nicht ausreichen, ist Wikidata der erreichbare Schritt, der die Entitätsebene dennoch voranbringt, während man die Berichterstattungslücke schließt.

Die Logik der Reihenfolge ist einfach. Wikidata hat die niedrigere Hürde und den schnelleren Weg zu einem legitimen Ergebnis — daher ist es der Ausgangspunkt für nachweisbare, aber noch nicht bekannte Themen. Wikipedia hat die höhere Hürde und das stärkere Signal — daher geht man dorthin, wenn die Quellen tatsächlich vorhanden sind. Den Wikipedia-Weg zuerst zu gehen, wenn man die Kriterien nicht erfüllt, verschwendet Wochen und riskiert eine Löschung, die den nächsten Versuch erschwert. Wikidata zuerst aufzubauen kostet wenig, hilft in jedem Fall und schadet dem Wikipedia-Vorhaben nie.

Was es nicht ist: ein Trick, eine Abkürzung zu Bekanntheit oder ein garantiertes Panel. Es ist die Entitätsschicht — das unspektakuläre, strukturierte, gut belegte Fundament, das Maschinen dazu bringt, die eigene Entität korrekt zu beschreiben. Für viele Unternehmen und Einzelpersonen ist es sowohl der erreichbarste als auch der am meisten übersehene Schritt im gesamten Gespräch über KI-Sichtbarkeit.

Nicht sicher, ob die eigene Entität mit Wikidata beginnen oder direkt einen Wikipedia-Artikel anstreben sollte? Schreib uns an team@wikibusines.com — wir geben eine ehrliche Einschätzung, welcher Schritt zur aktuellen Situation passt.