Entity Salience Score: Verstehen, was Google in deinem Text für zentral hält

von

Du gibst Google einen Text. Google gibt dir eine Liste der „Dinge“ zurück, die es darin erkannt hat – Personen, Marken, Orte, Produkte, Konzepte – und für jedes eine Zahl zwischen 0 und 1. Diese Zahl heißt Salience Score, und sie beantwortet genau eine Frage: Wie sehr dreht sich dieser eine Text um dieses eine Ding, im Vergleich zu den anderen Dingen, die auch im Text vorkommen?

Mehr nicht. Keine Verbindung zu Rankings, keine Aussage über „gute SEO“ – nur: Innerhalb dieses einen Textes, was ist am zentralsten.

Ein Beispiel, das die Zahl greifbar macht

Nimm diesen Satz:

„Tim Cook stellte das neue iPhone im Apple Park vor.“

Google gibt zurück (ungefähr):

  • Tim Cook → 0,41
  • Apple Park → 0,32
  • iPhone → 0,27

Tim Cook steht oben, weil er das Subjekt ist – die Handlung geht von ihm aus. Apple Park ist „nur“ der Ort, iPhone „nur“ das Objekt. Die drei Werte konkurrieren um denselben Kuchen und ergeben ungefähr 1.

Wichtig: Speist du statt des reinen Satzes eine ganze Webseite mit Navigation, Footer, Cookie-Banner und Newsletter-Formular ein, taucht plötzlich „Datenschutzerklärung“ mit überraschend hohem Wert auf – das Tool weiß nicht, dass das Navigations-Müll ist. Es zählt einfach, was im Text vorkommt und wo.

Wofür ist das konkret nützlich?

Fall 1 – Content-Audit: Erzählt meine Seite wirklich das, was ich will?
Du hast einen Artikel geschrieben, der zentral um ein bestimmtes Thema gehen soll. Reinen Artikeltext (nicht die ganze HTML-Seite) durchs Tool laufen lassen. Steht dein Ziel-Thema nicht unter den Top 3–5, sondern z. B. „über mich“ oder „Newsletter“ ganz oben – dann redet die Seite mehr über drumherum als über das eigentliche Thema. Ein konkreter Schreibhinweis, kein abstraktes Ranking-Versprechen.

Fall 2 – Boilerplate-Check nach dem Veröffentlichen
Vor dem Go-live mit sauberem Text getestet – alles gut. Nach dem Go-live die live gerenderte Seite testen (mit allem drumherum, so wie ein Crawler sie sieht). Taucht jetzt ein Sidebar-Widget oben auf, verwässert dein Template das Thema stärker als gedacht. Ein QA-Schritt, kein Optimierungsziel.

Fall 3 – Wettbewerbsvergleich
Eine gut rankende Konkurrenzseite zum selben Thema durchs Tool laufen lassen, eigenen Text daneben. Nicht um Wörter zu klauen, sondern um zu sehen: Erwähnen die Nebenentitäten, die bei dir fehlen, deutlich prominenter?

Fall 4 – Saubere Verlinkung statt Rateversuche
Für jede erkannte, Google bekannte Entität liefert das Tool eine Google-eigene ID (mehr dazu unten) und oft einen Wikipedia-Link mit. Den kannst du direkt für dein Schema-Markup (sameAs) übernehmen, statt selbst zu raten, welcher Wikipedia-Artikel „wirklich“ zu dir gehört.

Wofür es NICHT taugt: Die Zahl selbst hochzutreiben, indem man ein Wort öfter wiederholt. Erstens ist nicht belegt, dass dieser Wert irgendetwas mit Rankings zu tun hat. Zweitens ist er nicht zwischen einer 500-Wörter- und einer 3.000-Wörter-Seite vergleichbar (andere „Konkurrenz“ im selben Text). Wer 0,3 als Zielwert verfolgt, optimiert gegen die falsche Sache.

Wann mache ich das – neun konkrete Momente

  • Vor Veröffentlichung: Entwurfstext testen, Ziel-Thema muss unter Top 3–5 stehen
  • Nach Go-live: dieselbe Seite jetzt gerendert testen, Verschiebung gegenüber Schritt 1 = Template-Problem
  • Vor der Content-Erstellung: 2–3 Top-Konkurrenzartikel gegen eigenen Entwurf gegenchecken
  • Für Schema-Markup: gelieferte Google-ID direkt in sameAs übernehmen
  • Regelmäßig, nicht einmalig: IDs im Schema quartalsweise gegenprüfen – Google baut seinen Knowledge Graph laufend um, alte IDs können ins Leere zeigen
  • Sammelliste führen: Wenn keine ID geliefert wird, kennt Google die Entität (noch) nicht eigenständig – Kandidat für gezielte PR, Wikidata-Eintrag oder zumindest konsistente Profile auf LinkedIn/Crunchbase
  • Bei mehrsprachigen Seiten: Sprache im Tool-Aufruf explizit angeben statt raten lassen
  • Bei Vergleichs-/Review-Content: zusätzlich die Tonalität pro Entität prüfen – wird über das „unterlegene“ Produkt in der Wortwahl trotzdem zu wohlwollend geschrieben?
  • In Kombination mit einem Crawl-Audit: Seiten, bei denen die Ziel-Entität nicht unter den Top 3–5 landet, sind oft dieselben, die auch strukturell schwach eingebunden sind (wenig interne Links, zu breiter Content) – beides zusammen prüfen

So findest du deine Google-ID – ganz ohne Programmieren

Der ganze Weg über Text-Analyse lohnt sich vor allem, wenn du nicht weißt, welche Entitäten in einem fremden Text überhaupt wichtig sind. Für den eigenen Blog weißt du das meistens schon: dein eigener Name, deine Marke, dein Buchtitel. Dann kannst du den Umweg komplett überspringen und direkt nach der ID suchen – kostenlos, ohne Account, ohne eine Zeile Code.

Weg 0 – ein Tool, das beides für dich bündelt

Bevor du die beiden manuellen Wege unten von Hand durchgehst (oder bevor bei mir die Motivation überhaupt entstehen konnte selbst was zu basteln): René Dhemant stellt mit dem Entity Explorer ein kostenloses Tool bereit, das genau das automatisiert. Namen eingeben, und das Tool fragt Google Knowledge Graph, Wikipedia und Wikidata gleichzeitig ab – inklusive der kgmid, zusammengeführter Beschreibung und Kennzeichnung, aus welcher Quelle welche Angabe stammt. Keine Anmeldung nötig.

Praktischer Zusatznutzen gegenüber der reinen ID-Suche: Das Tool zeigt auch an, wenn eine Marke über mehrere, nicht konsolidierte Einträge zersplittert ist (viele Treffer, aber keiner davon dominant) – ein Signal dafür, dass die eigene Entität für Google noch nicht eindeutig ist. Genau das Naming-Drift-Problem also, nur von der Identitäts- statt der Schema-Seite aus betrachtet.

Für alle, die verstehen wollen, was dabei im Hintergrund passiert (oder falls das Tool einmal nicht erreichbar ist), hier die beiden manuellen Einzelwege, aus denen sich das Prinzip zusammensetzt:

Weg 1 – über die Google-Suche

  1. Den Namen der Entität bei Google suchen (z. B. den eigenen Namen oder die eigene Marke)
  2. Erscheint eine Karte oder ein Panel: auf das Drei-Punkte-Menü neben dem Titel klicken, dann „Teilen“
  3. Den entstehenden share.google-Kurzlink im Browser öffnen
  4. In der Adresszeile steht jetzt die volle URL – darin findet sich kgmid=/m/... oder kgmid=/g/..., das ist die gesuchte ID

Manchmal ist die ID URL-codiert (%2Fm%2F... statt /m/...) – ein beliebiger Online-URL-Decoder macht daraus die lesbare Form.

Weg 2 – über Wikidata

  1. Auf wikidata.org nach der Entität suchen
  2. Den passenden Eintrag öffnen
  3. Im Eigenschaften-Bereich nach „Google Knowledge Graph ID“ oder (bei älteren Einträgen) „Freebase ID“ suchen

Das funktioniert teils sogar für Entitäten ohne eigenes sichtbares Google-Knowledge-Panel, solange sie in Wikidata gepflegt sind.

Gegenprüfen: https://www.google.com/search?kgmid=DEINE-ID in den Browser eingeben – erscheint das erwartete Panel, ist die ID korrekt.

Grenze dieser Methode: Sie setzt voraus, dass Google oder Wikidata die Entität überhaupt schon kennt. Für eine neue, noch unbekannte Marke ohne Wikipedia-/Wikidata-Eintrag lässt sich so keine ID finden – das ist dann kein Tool-Problem, sondern ein Bekanntheitsproblem, das sich erst durch PR-Arbeit, einen Wikidata-Eintrag oder Ähnliches löst.

Der technische Weg: Wann sich die Google API lohnt

Die manuelle Methode oben reicht für einzelne, bekannte Entitäten. Willst du dagegen systematisch analysieren, welche Entitäten in einem beliebigen Text überhaupt vorkommen und wie zentral sie sind (z. B. um eigene Texte zu prüfen oder Wettbewerbsartikel zu vergleichen), braucht es die eigentliche Google Cloud Natural Language API. Drei Aufwandsstufen, je nachdem wie tief du gehen willst:

Stufe 0 – nur mal reinschnuppern (2 Minuten, kein Vorwissen):
Die Web-Demo unter cloud.google.com/natural-language öffnen, Text reinkopieren, Ergebnis ansehen. Kein Setup, keine Kreditkarte nötig. Einschränkung: keine Google-IDs sichtbar, nur eine Seite auf einmal.

Stufe 1 – IDs fürs eigene Schema holen (ca. 20 Minuten einmalig, kein Programmieren):
Google-Cloud-Konto anlegen (läuft über den normalen Google-Login), ein Projekt benennen, die Natural-Language-API mit einem Klick aktivieren, einen API-Key generieren. Der Key kommt dann in ein fertiges Copy-Paste-Kommando – kein eigener Code nötig, aber ein erstes Mal Terminal-Luft schnuppern.

Stufe 2 – mehrere Seiten automatisiert durchlaufen (Python-Grundkenntnisse):
Ein Skript liest eine Sitemap aus, ruft jede Seite ab, bereinigt den Text um Navigation/Footer und schickt ihn automatisch an die API. Lohnt sich erst, wenn du das regelmäßig für viele Seiten brauchst – für einen einzelnen Blog unverhältnismäßig viel Aufwand.

Stolperstein: Seit 2023 gibt es neben v1 auch die v2-API mit einem neueren Modell für Entity Analysis – die liefert aber kein Salience-Feld mehr und auch keine Wikipedia-URL. Für dieses Vorhaben bleibst du bei v1, dem Standard, den auch alle drei Stufen oben nutzen.

Die Kosten im Überblick

Die ersten 5.000 Einheiten pro Monat sind kostenlos (1 Einheit = bis zu 1.000 Zeichen, aufgerundet). Eine 2.000-Wörter-Seite braucht ungefähr 12 Einheiten – für einen privaten Blog mit einer überschaubaren Artikelzahl bleibst du im Gratis-Kontingent. Danach kostet es 1 $ pro 1.000 Einheiten. Neue Google-Cloud-Konten bekommen zusätzlich ein Startguthaben.

Kannst du dir das selbst bauen?

Teilweise. Offene Werkzeuge (z. B. spaCy, Hugging-Face-Modelle) erkennen Entitäten in Text ebenfalls, teils sogar auf den eigenen Anwendungsfall trainierbar. Was sie nicht liefern: die Verknüpfung zu Googles eigenem Knowledge Graph – also genau die ID, die du für sameAs im Schema brauchst. Das lässt sich nicht selbst nachbauen, weil du keinen Zugriff auf Googles internen Graphen hast, nur über deren eigene Schnittstelle (oder die manuellen Wege oben, sofern die Entität dort schon gelistet ist).

KI (LLM) dazuschalten – sinnvoll?

Als Ersatz für die Google-Daten nicht sinnvoll: Ein Sprachmodell sagt dir, was es selbst aus dem Text herausliest, nicht was Google über deine Seite denkt. Als Ergänzung dagegen schon – etwa um sauberen Artikeltext aus einem eigenwilligen Seitentemplate zu extrahieren, fehlende Wikipedia-/Wikidata-Kandidaten vorzuschlagen (die du danach manuell gegenprüfst), oder um eine größere Export-Tabelle mit vielen Zeilen schneller auszuwerten.

Fazit

Der Salience Score ist kein Rankingfaktor und kein Zielwert, den du erreichen solltest. Er ist ein Diagnosewerkzeug: Er zeigt, wovon ein Text aus Google-Sicht tatsächlich handelt – und ob das mit dem übereinstimmt, was du eigentlich sagen wolltest. Für den eigenen, überschaubaren Blog reicht oft schon die kostenlose Web-Demo zum Verstehen und der manuelle Weg über die Google-Suche oder Wikidata, um an die passende ID fürs eigene Schema zu kommen. Die volle API-Automatisierung lohnt sich erst, wenn du das regelmäßig für viele Seiten wiederholst.