Von Keywords zu Konzepten: Semantic SEO und Entity Based Optimisation

Seit 2012 sucht Google nach Dingen, nicht mehr nach Zeichenketten

Am 16. Mai 2012 hat Google den Knowledge Graph vorgestellt. Amit Singhal, damals Senior Vice President für Engineering bei Google, begann mit einer Suchanfrage: [taj mahal]. Gut vier Jahrzehnte lang, schrieb er, sei es bei der Suche im Kern darum gegangen, Keywords mit Anfragen abzugleichen. Für eine Suchmaschine waren das einfach zwei Wörter. Ein Mensch denkt dabei vielleicht an ein Grabmal in Indien, an einen Musiker, an ein Casino in Atlantic City oder an das nächste indische Restaurant. Der Knowledge Graph war Googles Antwort darauf: ein Modell echter Dinge und ihrer Beziehungen zueinander. Singhal fasste es in drei englischen Wörtern zusammen, "things, not strings", Dinge statt Zeichenketten.¹

Zum Start enthielt er mehr als 500 Millionen Objekte und mehr als 3,5 Milliarden Fakten über diese Objekte und ihre Beziehungen. Sie stammten aus öffentlichen Quellen wie Freebase, Wikipedia und dem CIA World Factbook und wurden von dort aus erweitert.¹

Heute beschreibt Google den Knowledge Graph als "unsere Datenbank mit Milliarden Fakten über Personen, Orte und Dinge". Die Fakten kommen aus vielen Quellen, darunter lizenzierte Daten und Hinweise von Rechteinhabern, die Änderungen an einem von ihnen beanspruchten Knowledge Panel vorschlagen. Knowledge Panels, die Faktenkästen neben den Ergebnissen, erstellt der Suchalgorithmus automatisch, "wenn genügend Informationen im öffentlichen Web verfügbar sind".²

Das ist die Idee hinter dem, was die Branche Semantic SEO nennt. Im Rest dieses Artikels geht es darum, was sich dadurch für deine Seiten ändert, und was nicht.

Durchgerechnetes Beispiel: zwei Wörter, vier Dinge

Kupferkessel Kaffee ist eine erfundene Rösterei in Hamburg, zu finden unter kupferkesselkaffee.example, geführt von Jana. Niemand davon ist echt, jede Zahl ist ausgedacht. Jana röstet in einer Gewerbehalle in Bahrenfeld, verkauft Bohnen über die Theke und verschickt sie in ganz Deutschland.

Nimm die Zeichenkette "kupferkessel hamburg" und zähl, was sie alles bedeuten kann.

1. Einen Kupferkessel, den Gegenstand, den jemand in Hamburg kaufen will.
2. Ein Café oder Lokal, das zufällig auch Kupferkessel heißt.
3. Einen Antikladen, der Kupferkessel verkauft.
4. Janas Rösterei.

Eine Suchmaschine, die Buchstaben abgleicht, sieht zwei Wörter und eine Stadt. Eine Suchmaschine, die Dinge abgleicht, kann Janas Rösterei nur auswählen, wenn sie schon weiß, dass es die Rösterei gibt, dass sie in Hamburg ist, dass sie Kaffee verkauft und keine Kessel, und dass sie unter kupferkesselkaffee.example zu Hause ist. Jana kann jede dieser Tatsachen klar machen. Keine davon ist ein Keyword.

Eine Entität ist ein Ding mit Fakten und Verbindungen, und Semantic SEO macht dieses Ding unverwechselbar

Eine Entität ist schlicht ein Ding, das sich von anderen Dingen unterscheiden lässt: ein Unternehmen, eine Person, ein Ort, ein Produkt, eine Anbauregion für Kaffee. Sie hat Attribute, also Fakten über sich selbst (Kupferkessel Kaffee wurde 2019 gegründet und öffnet um 8:00 Uhr). Und sie hat Beziehungen, also Fakten, die sie mit anderen Entitäten verbinden (Kupferkessel Kaffee sitzt in Hamburg und verkauft einen Kaffee aus Yirgacheffe). Aufgeschrieben ist jeder dieser Fakten ein kleiner Satz aus drei Teilen: Subjekt, Beziehung, Objekt.

Semantic SEO heißt für mich, Seiten so zu schreiben und auszuzeichnen, dass klar ist, um welche Dinge es geht und wie diese Dinge zusammenhängen. Entity Based Optimisation ist dieselbe Idee, angewandt auf dein eigenes Unternehmen: Das Unternehmen, seine Produkte und seine Menschen werden jeweils so einheitlich beschrieben, dass eine Maschine sie überall als ein und dasselbe Ding erkennt, wo immer sie ihnen begegnet.

Eine ehrliche Einschränkung. Beide Begriffe stammen aus dem Vokabular der Branche, nicht von Google. Googles Leitfaden zu den Ranking Systemen der Suche erwähnt weder Entitäten noch den Knowledge Graph noch strukturierte Daten.³ Wer dir "Entity Optimierung" als Rankingfaktor verkauft, verkauft dir ein Wort, das Google nicht benutzt.

Durchgerechnetes Beispiel: Janas Entitätenblatt

Bevor sie eine einzige Seite anfasst, schreibt Jana die Fakten über ihr Unternehmen als Subjekt, Beziehung und Objekt auf. Das dauert eine halbe Stunde.

Subjekt	Beziehung	Objekt
Kupferkessel Kaffee	ist ein	Kaffeerösterei mit Laden
Kupferkessel Kaffee	sitzt in	Halle 4, Bahrenfeld, Hamburg
Kupferkessel Kaffee	hat die Website	kupferkesselkaffee.example
Kupferkessel Kaffee	wurde gegründet von	Jana
Kupferkessel Kaffee	verkauft	Yirgacheffe gewaschen, einen Single Origin Kaffee
Yirgacheffe gewaschen	stammt aus	Yirgacheffe, Äthiopien
Yirgacheffe gewaschen	wird aufbereitet im	gewaschenen Verfahren
Kupferkessel Kaffee	liefert nach	ganz Deutschland

Acht Zeilen, jede ein Fakt, den eine Kundin brauchen könnte und den eine Suchmaschine nutzen könnte, um die Rösterei vom Lokal gleichen Namens zu unterscheiden. Das Blatt ist die Checkliste für alles, was folgt: Ein Fakt, der nicht auf der Website, im Markup und auf ihren anderen Profilen steht, und zwar mit denselben Worten, erfüllt seinen Zweck nicht.

Googles Sprachsysteme lesen Bedeutung, und für keines davon gibt es einen Regler

Dinge erkennen ist die eine Hälfte. Einen ganzen Satz verstehen die andere, und Googles Leitfaden zu den Ranking Systemen zählt die Systeme dafür auf.³ Mit RankBrain versteht Google nach eigenen Worten besser, "wie Wörter mit Konzepten zusammenhängen", und kann so relevante Inhalte liefern, "auch wenn sie nicht genau die in einer Suche verwendeten Wörter enthalten". Der neuronale Abgleich ist ein System, mit dem Google "Darstellungen von Konzepten in Abfragen und auf Seiten erkennt und sie miteinander abgleicht". BERT, kurz für Bidirectional Encoder Representations from Transformers, hilft Google zu verstehen, "wie Kombinationen von Wörtern verschiedene Bedeutungen und Absichten darstellen".³

Als Google BERT im Oktober 2019 ankündigte, hieß es, BERT werde der Suche helfen, eine von zehn englischsprachigen Suchanfragen in den USA besser zu verstehen, vor allem längere, eher gesprochene Anfragen und solche, bei denen kleine Wörter wie "for" und "to" die Bedeutung tragen. Das Beispiel war die Anfrage "2019 brazil traveler to usa need a visa". Vor BERT lieferte Google Ergebnisse über US Bürger, die nach Brasilien reisen, weil das kleine Wort "to" unterging.⁴

MUM, das Multitask Unified Model, wurde im Mai 2021 als tausendmal leistungsfähiger als BERT vorgestellt, trainiert in 75 Sprachen und in der Lage, Text und Bilder zu verstehen.⁵ MUM wird am häufigsten überschätzt. Googles eigener Ranking Leitfaden sagt, MUM werde "derzeit nicht für das allgemeine Ranking in der Google Suche verwendet", sondern nur für bestimmte Anwendungen, etwa für bessere Suchen nach Impfinformationen während der Pandemie und für Zusatzinformationen zu hervorgehobenen Snippets.³

Für keines dieser Systeme gibt es eine Einstellung auf deiner Website. Die praktische Folge ist das Gegenteil eines Tricks: Schreib so, wie ein Mensch spricht, der sich auskennt, dann stehen die kleinen Wörter, die die Bedeutung tragen, auch für die Maschine da.

Durchgerechnetes Beispiel: das Wort "nicht"

Janas Mahlgradratgeber hatte eine Tabelle: Espresso fein, Filter mittel, French Press grob. Eine Kundin tippt "mahlgrad für espressokocher nicht siebträger". Die Frage hängt am Wort "nicht", und die Tabelle erwähnt den Espressokocher gar nicht.

Jana ergänzt einen Absatz unter einer eigenen Überschrift, "Welcher Mahlgrad für den Espressokocher?":

Ein Espressokocher braucht einen Mahlgrad, der etwas gröber ist als für Espresso und feiner als für Filter, ungefähr wie Speisesalz. Espressomahlung verstopft im Espressokocher den Trichtereinsatz und schmeckt bitter. Wenn du gemahlene Bohnen bei mir kaufst, wähl an der Kasse "Espressokocher", dann mahle ich sie genau so.

Schritt für Schritt: Die Überschrift nennt das Ding. Der erste Satz beantwortet die Frage. Der zweite kümmert sich um das "nicht", indem er sagt, was Espressomahlung im Espressokocher anrichtet. Der dritte verbindet die Antwort mit ihrem Produkt. Kein Keyword wurde wiederholt. Es ist die Antwort, die ein Mensch hinter ihrer Theke geben würde, und genau so etwas sollen die Sprachsysteme oben abgleichen.

Keyword Dichte ist ein Verhältnis, nach dem bei Google niemand gefragt hat

Die Gewohnheit, die Semantic SEO abgelöst hat, war die Keyword Dichte: die Zielphrase so oft wiederholen, bis sie einen magischen Anteil der Seite ausmacht.

$d = \frac{n \times k}{W}$

Dabei ist $d$ die Keyword Dichte, $n$ die Zahl der Vorkommen der Phrase, $k$ die Zahl der Wörter in der Phrase und $W$ die Gesamtzahl der Wörter auf der Seite. Das ist ein schlichtes Verhältnis, ein Teil geteilt durch das Ganze (Grundlagen: Verhältnisse und Raten), meist als Prozentwert angegeben (Grundlagen: Prozente).

Google hat nie einen Zielwert für $d$ veröffentlicht, und der eigene Startleitfaden zur Suchmaschinenoptimierung zeigt in die andere Richtung. Wer viel über ein Thema weiß, sucht mit anderen Wörtern als jemand, der neu ist: "Manche Nutzer könnten beispielsweise nach 'Wurstplatten' suchen, während andere nach 'Käseplatten' suchen." Jede Variante vorherzusehen sei aber nicht nötig, denn "die Systeme von Google für den Sprachabgleich sind ausgefeilt und verstehen, wie sich deine Seite auf viele Suchanfragen bezieht, auch wenn du die genauen Begriffe darin nicht explizit verwendest". Derselbe Leitfaden nennt die mehrfache Wiederholung derselben Wörter "ermüdend für Nutzer" und sagt, dass die Google Suche das Meta Tag "keywords" nicht verwendet.⁶ Googles Spamrichtlinien gehen weiter und definieren überflüssige Keywords als das Füllen einer Seite mit Keywords oder Zahlen, "um das Ranking in den Google Suchergebnissen zu manipulieren", oft ohne Kontext und nicht als natürlicher Teil des Textes.⁷

Die Dichte ist also eine Zahl zum Nachrechnen, nie ein Ziel. Wenn sie hoch ist, liest sich die Seite wahrscheinlich schlecht.

Durchgerechnetes Beispiel: Janas Startseite mit 8 %

Janas alte Startseite, 2020 von einer Agentur geschrieben, ist 600 Wörter lang. Die Phrase "beste Kaffeebohnen in Hamburg" mit vier Wörtern kommt 12 Mal vor.

$d = \frac{12 \times 4}{600} = \frac{48}{600} = 0{,}08$

Mit $n = 12$, $k = 4$ und $W = 600$ ist die Dichte $0{,}08$, also 8 %. Fast jedes zwölfte Wort auf der Seite gehört zu derselben Phrase aus vier Wörtern. Laut vorgelesen klingt die Seite wie ein Papagei nach einem Marketingseminar. Wie man so einen Anteil liest, steht in Grundlagen: Verhältnisse und Raten.

Jana schreibt sie neu. Die Phrase steht einmal im ersten Satz. Der Rest der Seite nennt die Dinge aus ihrem Entitätenblatt: die Rösterei in Bahrenfeld, die vier Kaffees, die sie diesen Monat röstet, und woher jeder kommt, wie frisch die Bohnen beim Versand sind, wie man an der Theke eine Tüte kauft. Die neue Seite hat 540 Wörter, und die Dichte ist

$d = \frac{1 \times 4}{540} = 0{,}007$

Mit $n = 1$, $k = 4$ und $W = 540$ ist die Dichte $0{,}007$, also 0,7 % (Grundlagen: Prozente). Dafür nennt die Seite jetzt Hamburg, Bahrenfeld, Äthiopien, Kolumbien, gewaschen, natural, Röstdatum und Versand.

Strukturierte Daten beschreiben die Seite, sie heben sie nicht im Ranking

Strukturierte Daten sind ein Block Code, meist im Format JSON-LD, der Fakten über die Seite in einem Vokabular festhält, das Maschinen gemeinsam nutzen. Dieses Vokabular steht auf schema.org als Sammlung von Typen und Eigenschaften. Die Einführung dort sagt, Suchmaschinen hätten nur "a limited understanding of what is being discussed" auf einer Seite, also ein begrenztes Verständnis davon, worum es geht, und Markup helfe ihnen, Inhalte besser zu verstehen und sinnvoll darzustellen.⁸

Googles Beschreibung dessen, was es damit tut, ist genau. Strukturierte Daten geben Google "explizite Hinweise zur Bedeutung der Seite". Google nutzt sie, um "die Inhalte der Seite zu verstehen und so auch Informationen über das Web und die Welt im Allgemeinen" zu erfassen, etwa "Informationen zu Personen, Büchern oder Unternehmen, die im Markup enthalten sind". Und sie können Rich Results ermöglichen, die erweiterten Einträge mit Sternen, Preisen oder Bildern, die Nutzer laut Google dazu anregen können, "stärker mit deiner Website zu interagieren".⁹

Achte darauf, was fehlt: das Ranking. Googles Dokumentation zu strukturierten Daten sagt nirgends, dass Markup eine Seite höher ranken lässt. Die allgemeinen Richtlinien sagen, dass strukturierte Daten das Vorhandensein einer Funktion "ermöglicht, jedoch nicht garantiert", und dass eine manuelle Maßnahme wegen irreführenden Markups eine Seite zwar von den Rich Results ausschließt, aber "keinen Einfluss auf das Ranking der Seite in der Google Websuche" hat.¹⁰ Auf direkte Nachfrage sagt John Mueller von Google seit Jahren dasselbe. 2018 schrieb er, es gebe keinen generellen Rankingbonus für strukturierte Daten ("There's no generic ranking boost for SD usage"), mit dem vorsichtigen Zusatz, dass sie es leichter machen können zu verstehen, worum es auf der Seite geht, und damit auch leichter, sie dort zu zeigen, wo sie relevant ist.¹¹ Im April 2025 noch deutlicher: "Structured data won't make your site rank better", strukturierte Daten lassen deine Website nicht besser ranken.¹²

In Googles eigener Darstellung kann Markup eine Seite also für Rich Results infrage kommen lassen und Google helfen, die Seite und das Unternehmen zu verstehen. Es schiebt eine Seite nicht in den normalen Ergebnissen nach oben.

Zwei weitere Korrekturen. Rich Results sind nicht von Dauer. Im August 2023 hat Google FAQ Rich Results auf "bekannte, verlässliche Behörden und Gesundheitswebsites" beschränkt und HowTo Rich Results auf Mobilgeräten abgeschaltet. Einen Monat später verschwanden sie auch auf dem Computer, und Google erklärte den Ergebnistyp für nicht mehr verfügbar.¹³ Seit dem 7. Mai 2026 zeigt Google auch FAQ Rich Results gar nicht mehr an, für niemanden, und im Juni 2026 hat es die Dokumentation dazu entfernt.¹⁴ Und Googles Fallstudien zu Rich Results, etwa Rotten Tomatoes mit einer um 25 % höheren Klickrate auf 100.000 Seiten mit strukturierten Daten, handeln von Klicks auf einen Eintrag, nicht davon, auf welcher Position der Eintrag steht.⁹

Durchgerechnetes Beispiel: das Entity Schema Paket für 1.200 €

Jana bekommt ein "Entity Schema Paket" für 1.200 € angeboten, mit vier Versprechen. Hier jedes einzeln, geprüft an Googles eigenen Worten.

1. "Schema bringt dich im Ranking nach vorn." Google: Strukturierte Daten lassen deine Website nicht besser ranken.¹² Versprechen fällt durch.
2. "FAQ Schema auf jeder Produktseite, für mehr Platz in den Ergebnissen." Google hat FAQ Rich Results 2023 auf bekannte Behörden und Gesundheitswebsites beschränkt,¹³ und eine Hamburger Rösterei ist keins von beidem. Seit dem 7. Mai 2026 erscheinen sie überhaupt nicht mehr.¹⁴ Versprechen fällt durch.
3. "Markup für deine Bewertungen von anderen Portalen." Googles Richtlinien verlangen, dass strukturierte Daten "eine realitätsgetreue Darstellung der Seiteninhalte" sind, und nennen Inhalte, die für Nutzer nicht sichtbar sind, als Problem.¹⁰ Stehen die Bewertungen nicht auf der Seite, verstößt das Markup gegen die Richtlinien. Versprechen fällt durch und könnte sie sogar die Rich Results kosten, die sie schon hat.
4. "Organization Markup, damit Google weiß, wer du bist." Google sagt tatsächlich, dass dieses Markup helfen kann, ein Unternehmen eindeutig zu identifizieren und sein Logo auszuwählen.¹⁵ Versprechen hält, und es ist etwa eine Stunde Arbeit.

Eins von vier Versprechen bleibt übrig, das kleine, und Jana erledigt es selbst.

Eine Identität überall: Organization Markup, sameAs und ein einheitlicher Name

Am meisten lohnt es sich, dein eigenes Unternehmen unverwechselbar zu machen. Googles Dokumentation zu strukturierten Daten für Organisationen sagt, dass Google damit "die Verwaltungsdetails deiner Organisation besser verstehen und deine Organisation in den Suchergebnissen eindeutig identifizieren" kann, und dass einige Eigenschaften beeinflussen können, welches Logo in den Ergebnissen und im Knowledge Panel erscheint.¹⁵ Für ein Unternehmen mit Ladenlokal kannst du mit dem Typ LocalBusiness Google "über Öffnungszeiten, verschiedene Abteilungen innerhalb eines Unternehmens" und mehr informieren.¹⁶

Die Eigenschaft, die den Großteil der Identitätsarbeit leistet, ist sameAs. Schema.org definiert sie als "URL of a reference Web page that unambiguously indicates the item's identity", also die Adresse einer Referenzseite, die eindeutig zeigt, um welches Ding es sich handelt, zum Beispiel der Wikipedia Artikel, der Wikidata Eintrag oder die offizielle Website.¹⁷ Auf gut Deutsch: Hier ist dasselbe Ding, anderswo beschrieben.

Für ein lokales Unternehmen gibt es eine zweite Front, außerhalb der Website. Google sagt, lokale Suchergebnisse "basieren hauptsächlich auf Relevanz, Entfernung und Beliebtheit", dass "Unternehmen mit vollständigen und korrekten Informationen" mit größerer Wahrscheinlichkeit in den lokalen Suchergebnissen angezeigt werden, und dass sich ein besseres lokales Ranking nicht anfordern lässt, auch nicht gegen Bezahlung.¹⁸ Das ist eine der wenigen Stellen, an denen Google korrekte Fakten direkt mit Sichtbarkeit verbindet. Unternehmensprofil und Website müssen also dasselbe sagen.

Durchgerechnetes Beispiel: Janas Identitätscheck und ihr Organization Block

Jana sucht nach ihrem eigenen Unternehmen und notiert jede Version, die sie findet.

1. Fußzeile der Website: "Kupferkessel Kaffeerösterei".
2. Unternehmensprofil bei Google: "Kupferkessel Kaffee", Halle 4, mit der alten Telefonnummer.
3. Instagram Bio: "Der Kupferkessel, Hamburg".
4. Handelsregister: der eingetragene Name der GmbH.
5. Ein Gastroverzeichnis: "Kupferkessel Café", als Café eingetragen, was es nicht ist.

Fünf Namen für ein Ding. Sie entscheidet sich für "Kupferkessel Kaffee", passt Fußzeile, Instagram Bio und Verzeichniseintrag an und korrigiert die Telefonnummer im Unternehmensprofil. Der eingetragene Name bleibt im Handelsregister, und sie nennt ihn im Markup als legalName. So sind die beiden Namen miteinander verbunden, statt miteinander zu konkurrieren.

Dann setzt sie diesen Block in den Kopf ihrer Startseite:

{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Kupferkessel Kaffee",
  "legalName": "Kupferkessel Kaffee GmbH",
  "url": "https://kupferkesselkaffee.example",
  "logo": "https://kupferkesselkaffee.example/logo.png",
  "telephone": "+49 40 66969 000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Röstereistraße 4, Halle 4",
    "addressLocality": "Hamburg",
    "postalCode": "22761",
    "addressCountry": "DE"
  },
  "openingHours": "Mo-Sa 08:00-16:00",
  "founder": { "@type": "Person", "name": "Jana" },
  "sameAs": [
    "https://social.example/kupferkesselkaffee",
    "https://directory.example/hamburg/kupferkessel-kaffee"
  ]
}

Zeile für Zeile. @context sagt, dass das Vokabular von schema.org stammt. @type wählt den genauesten Typ, der stimmt. Jana führt einen Laden, kein Café, also Store. Schema.org ordnet Store unter LocalBusiness ein, und LocalBusiness steht sowohl unter Organization als auch unter Place.¹⁹ Typen erben die Eigenschaften ihrer Eltern, bis hinauf zum allgemeinsten Typ, Thing.⁸ name ist der eine Name, für den sie sich entschieden hat, und legalName verbindet ihn mit der GmbH. url, logo, telephone, address und openingHours wiederholen genau, was in der Fußzeile und im Unternehmensprofil steht. Die Telefonnummer stammt aus dem Bereich, den die Bundesnetzagentur für Film, Fernsehen und andere Medien reserviert hat, damit das Beispiel niemanden anruft.²⁰ founder verbindet das Unternehmen mit einer Person. sameAs listet ihre anderen Profile, im echten Leben ihre Instagram Seite und den korrigierten Verzeichniseintrag, hier auf reservierten Beispieldomains.

Jeder Wert stammt aus ihrem Entitätenblatt, und jeder Wert ist irgendwo auf der Seite sichtbar, so wie Googles Richtlinien es verlangen.¹⁰ Sie erwartet eine bessere Chance, dass Google ihre Website, ihr Unternehmensprofil und ihr Instagram als ein Unternehmen behandelt. Einen Sprung im Ranking erwartet sie nicht, denn Google hat gesagt, dass es den nicht gibt.

Plane Seiten um die Dinge, nach denen deine Kunden fragen, und verlinke sie so, wie die Dinge zusammenhängen

Der nützliche Teil am Denken in Entitäten ist nicht das Markup, sondern die Planung. Statt einer Liste von Keyword Phrasen mit jeweils eigener dünner Seite fängst du bei den Dingen an, die deinen Kunden wichtig sind, und bei den Fragen, die sie stellen. Jedes wichtige Ding bekommt eine Seite, die es richtig behandelt. Seiten verlinken aufeinander, wo die Dinge selbst verbunden sind: Der Kaffee verlinkt auf seine Herkunft, die Herkunft auf die Kaffees von dort, die Zubereitungsanleitung auf den passenden Mahlgrad.

Das ist meine Praxis, keine Google Regel. In den Shops, an denen ich gearbeitet habe, hört die Website damit auf, gegen sich selbst anzutreten, weil es für jedes Ding eine klare Seite gibt statt vier fast gleicher Kopien, und die internen Links ergeben für Leser einen Sinn. Es passt auch zu dem, was Google über Sprache sagt: Wenn seine Systeme deine Seite mit Anfragen verbinden können, deren Wörter gar nicht darauf stehen,⁶ ist eine eigene Seite für jede Formulierung verschwendete Mühe.

Durchgerechnetes Beispiel: Janas Karte von einer Rösterei zu 14 Seiten

Das Diagramm läuft von oben nach unten, vom Unternehmen zu den Details. Jeder Kasten ist eine Art Seite, und jeder Pfeil ist eine echte Verbindung zwischen Dingen, genau dort gehören die internen Links hin. Der hervorgehobene Kasten wird von allen vier Zubereitungsanleitungen verlinkt. Die Entscheidung unten verhindert, dass die Website ausufert.

Zähl die Seiten. Eine Startseite, vier Kaffees, drei Herkunftsseiten, vier Zubereitungsanleitungen, ein Mahlgradratgeber und eine Seite zum Versand: 14. Ihre alte Website hatte 31, die meisten davon Varianten von "Kaffeebohnen Hamburg", "Kaffeebohnen Lieferung Deutschland" und "Kaffee online kaufen Hamburg", die alle dasselbe sagten. Die 17 Seiten, die wegfallen, leitet sie auf die Seite um, die das Thema jetzt abdeckt.

Prüf mit einem Entitätenwerkzeug, was eine Maschine liest, und nimm den Wert als Hinweis

Eine grobe Version dessen, was eine Maschine aus deinem Text herausliest, kannst du dir ansehen. Die Natural Language API von Google Cloud hat eine Entitätenanalyse. Du gibst ihr einen Text, und sie liefert die Entitäten, die sie erkennt, jeweils mit einem Typ (Person, Ort, Organisation und so weiter), mit Metadaten, die bei den meisten Entitäten eine Wikipedia URL und, falls vorhanden, eine Knowledge Graph ID enthalten, und mit einem Salienzwert. Google definiert die Salienz als Wert im Bereich von 0 bis 1,0, der etwas über die Wichtigkeit oder Zentralität der Entität für den gesamten Text aussagt ("the importance or centrality of that entity to the entire document text").²¹ Nahe eins heißt, der Text handelt vor allem von diesem Ding. Nahe null heißt, es wird nur am Rand erwähnt.

Eine Warnung, die zählt. Das ist ein Google Cloud Produkt für Entwickler. Nichts, was Google veröffentlicht, sagt, dass die Suche diese Werte nutzt oder dass eine höhere Salienz beim Ranking hilft. Ich benutze es wie eine Rechtschreibprüfung: als zweiten Leser, der mir sagt, ob die Seite von dem handelt, wovon ich glaube, dass sie handelt.

Durchgerechnetes Beispiel: die Yirgacheffe Seite vorher und nachher

Janas Seite für ihren äthiopischen Kaffee begann früher mit zwei Absätzen über die Rösterei und Hamburg, danach kam eine Zeile über den Kaffee. Sie lässt den Text durch die API laufen. Die wichtigsten Entitäten: Kupferkessel Kaffee mit 0,46, Hamburg mit 0,21, Kaffee mit 0,14 und Yirgacheffe mit 0,06. Für eine Maschine handelt die Seite von der Rösterei. Der Kaffee ist eine Randnotiz.

Sie schreibt die Seite neu. Jetzt beginnt sie mit dem Kaffee: wo er wächst, auf welcher Höhe, wie er aufbereitet wird, wie er schmeckt, wie man ihn zubereitet. Die Rösterei taucht einmal auf, gegen Ende. Sie lässt die Analyse noch einmal laufen.

Auf der waagrechten Achse stehen die fünf Entitäten, die die API am höchsten einstuft. Auf der senkrechten Achse steht der Salienzwert jeder Entität, von 0 bis 1. Die Erkenntnis steckt in der Reihenfolge: Der Kaffee und seine Herkunft stehen jetzt vorn, Rösterei und Stadt am Rand. Die Werte sind für dieses Beispiel erfunden.

Die Veränderung für den Kaffee selbst liest du am besten in Punkten, nicht als prozentuale Veränderung.

$\Delta s = s_{\text{nachher}} - s_{\text{vorher}} = 0{,}41 - 0{,}06 = 0{,}35$

Dabei ist $\Delta s$ die Veränderung der Salienz, $s_{\text{nachher}}$ der Wert nach der Überarbeitung und $s_{\text{vorher}}$ der Wert davor. Eine Differenz zwischen zwei Anteilen liest man am besten in Punkten, so wie eine Konversionsrate, die von 2,0 % auf 2,5 % steigt, um einen halben Prozentpunkt wächst (Grundlagen: Prozente). Yirgacheffe ist von einer Randbemerkung zum Thema der Seite geworden.

Was Jana nicht tut: der Zahl hinterherjagen und "Yirgacheffe" wiederholen, bis 0,6 dasteht. Das wäre Keyword Dichte unter neuem Namen. Der Wert hat ihr gezeigt, dass die Seite vom falschen Ding handelte. Sie hat das für die Leser behoben und einmal geprüft, ob die Maschine zustimmt.

KI Suche liest dieselben Seiten, ohne spezielles Schema

Die alte Fassung dieses Artikels behauptete, Inhalte, die Entitäten klar definieren und verbinden, würden von generativer Suche deutlich häufiger zitiert. Eine Quelle dafür habe ich nicht gefunden, also ist der Satz weg. Googles Leitfaden zur Optimierung für generative KI Funktionen in der Google Suche sagt: "Strukturierte Daten sind für die Suche mit generativer KI nicht erforderlich und es gibt kein spezielles schema.org Markup, das du hinzufügen musst." Für die Rich Results, die es schon gibt, empfiehlt er sie trotzdem weiter. Derselbe Leitfaden sagt, aus Sicht der Google Suche sei die Optimierung für die Suche mit generativer KI eine Optimierung für die Suche insgesamt "und damit weiterhin SEO".²² Googles Seite zu KI Funktionen sagt, dass du für Übersichten mit KI und den KI Modus "keine speziellen strukturierten schema.org Daten hinzufügen" musst.²³

Für die KI Suche ändert sich hier also nichts. Die Seite der Passagen behandle ich im Artikel über Passage Indexing, dort steht auch, warum strukturierte Daten dabei keine dokumentierte Rolle spielen. Wie KI Antworten Quellen auswählen und zitieren, steht im Artikel über AEO und GEO, die Seite von ChatGPT in wie man in ChatGPT rankt.

Was ich mache, und wofür ich kein Geld ausgeben würde

Auf jeder Website, die ich baue, ob Solidus Shop oder SaaS Produkt, beginnt die Arbeit mit dem Entitätenblatt. Ein Name für das Unternehmen, überall gleich. Organization Markup auf der Startseite, jeder Wert sichtbar auf der Seite, sameAs mit Verweisen auf Profile, die wirklich zum Unternehmen gehören. Eine Seite pro wichtigem Ding, verlinkt so, wie die Dinge zusammenhängen. Text, der die Dinge genau benennt, in den Worten, die eine Kundin verwenden würde. Ab und zu eine Entitätenanalyse als zweiter Leser.

Wofür ich nichts bezahlen würde: ein Schema Paket, das als Rankingschub verkauft wird, FAQ Markup in der Hoffnung auf ein Rich Result, das Google seit Mai 2026 gar nicht mehr anzeigt, Markup für Inhalte, die nicht auf der Seite stehen, ein Zielwert für die Keyword Dichte, oder ein Audit, das verspricht, deine "Entitäten zu optimieren", für einen Algorithmus, den Google nie mit diesen Worten beschrieben hat.

Die alte Fassung dieses Artikels erzählte auch von einem Kunden, dessen Impressionen nach einem Umbau gestiegen seien, ohne Quelle und ohne Zahlen, also habe ich das gestrichen. Seit 2012 versucht Google, Dinge zu verstehen, nicht Zeichenketten. Die beste Hilfe, die du Google geben kannst, ist dieselbe, die du einer neuen Kundin gibst: klar sagen, wer du bist, was du verkaufst, wo du bist und wie alles zusammenhängt.

Footnotes

1. Amit Singhal, Introducing the Knowledge Graph: things, not strings, Google, 16. Mai 2012, https://blog.google/products-and-platforms/products/search/introducing-knowledge-graph-things-not/

2. Google, Funktionsweise des Knowledge Graph von Google, Infobox Hilfe, abgerufen am 8. November 2026, https://support.google.com/knowledgepanel/answer/9787176?hl=de

3. Google, Leitfaden zu Ranking Systemen der Google Suche, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/ranking-systems-guide?hl=de

4. Pandu Nayak, Understanding searches better than ever before, Google, 25. Oktober 2019, https://blog.google/products-and-platforms/products/search/search-language-understanding-bert/

5. Pandu Nayak, MUM: A new AI milestone for understanding information, Google, 18. Mai 2021, https://blog.google/products-and-platforms/products/search/introducing-mum/

6. Google, Startleitfaden zur Suchmaschinenoptimierung (SEO): Grundlagen, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/fundamentals/seo-starter-guide?hl=de

7. Google, Spamrichtlinien für die Google Websuche (Überflüssige Keywords), Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/essentials/spam-policies?hl=de

8. Schema.org, Getting started with schema.org using Microdata, abgerufen am 8. November 2026, https://schema.org/docs/gs.html

9. Google, Einführung in das Markup für strukturierte Daten in der Google Suche, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=de

10. Google, Allgemeine Richtlinien für strukturierte Daten, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/structured-data/sd-policies?hl=de

11. Barry Schwartz, Google: Structured Data Doesn't Give You A Ranking Boost But Can Help Rankings, Search Engine Roundtable, 3. April 2018, mit einem Zitat von John Mueller (Google), https://seroundtable.com/google-structured-data-ranking-factor-25510.html

12. Barry Schwartz, Google Again Says Structured Data Does Not Make Your Site Rank Better, Search Engine Roundtable, 15. April 2025, mit einem Zitat von John Mueller (Google) auf Bluesky vom 13. April 2025, https://www.seroundtable.com/google-structured-data-ranking-39232.html

13. Google Search Central, Änderungen an Rich Suchergebnissen für Anleitungen und FAQs, 8. August 2023, aktualisiert am 14. September 2023, https://developers.google.com/search/blog/2023/08/howto-faq-changes?hl=de

14. Google Search Central, Neueste Änderungen an der Dokumentation zur Google Suche, Einträge "Einstellung der Funktion für FAQ Rich Suchergebnisse" vom 8. Mai 2026 und "Dokumentation für die Funktion für FAQ Rich Suchergebnisse entfernt" vom Juni 2026, abgerufen am 8. November 2026, https://developers.google.com/search/updates?hl=de#faq-deprecation

15. Google, Strukturierte Daten für Organisationen (Organization), Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/structured-data/organization?hl=de

16. Google, Strukturierte Daten für lokale Unternehmen (LocalBusiness), Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/structured-data/local-business?hl=de

17. Schema.org, sameAs, abgerufen am 8. November 2026, https://schema.org/sameAs

18. Google, Ranking in lokalen Suchergebnissen auf Google verbessern, Google Unternehmensprofil Hilfe, abgerufen am 8. November 2026, https://support.google.com/business/answer/7091?hl=de

19. Schema.org, Store, abgerufen am 8. November 2026, https://schema.org/Store

20. Bundesnetzagentur, Rufnummern für Medienproduktionen ("Drama Numbers"), abgerufen am 8. November 2026, https://bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/Nummerierung/DramaNumbers/artikel.html

21. Google Cloud, Entity (Cloud Natural Language API Referenz), abgerufen am 8. November 2026, https://docs.cloud.google.com/natural-language/docs/reference/rest/v1/Entity?hl=de

22. Google, Leitfaden von Google zur Optimierung für generative KI Funktionen in der Google Suche, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?hl=de

23. Google, KI Funktionen und deine Website, Google Search Central Dokumentation, abgerufen am 8. November 2026, https://developers.google.com/search/docs/appearance/ai-features?hl=de