Die Keyword-Recherche war jahrzehntelang das Fundament jeder Content-Strategie. Tools wie Ahrefs, Semrush und Sistrix lieferten Keyword-Listen mit Suchvolumen, Wettbewerb und Klickpotenzial, und Marketing-Teams bauten daraus Redaktionsplaner. Das funktionierte, solange Google Queries als isolierte Token-Strings verarbeitete.
Seit BERT (2019), MUM (2021) und dem Helpful Content System (2022, seit März 2024 laut Google Teil der Core-Ranking-Systeme) operiert Google strukturell anders. Queries werden als semantische Intent-Repräsentationen verstanden, nicht als Keyword-Matches. Mit den AI Overviews und der Integration generativer Modelle (2024-2026) hat sich dieser Wandel radikalisiert. Content wird heute nicht mehr für Keywords gemacht, sondern für Themen-Verständnis.
Was ist eine Topical Map?
Eine Topical Map ist die strukturierte Karte aller Themen, Entitäten und Fragen, die eine Domain zu einem Kernthema abdecken muss, samt ihrer internen Verlinkung. Sie gliedert ein Core Topic in Cluster mit je einer Pillar-Page und in Detailseiten und legt fest, welche Seite welche Suchintention bedient. So wird sichtbar, wie vollständig eine Domain ein Thema abdeckt.
Der Begriff Topical Authority wurde im SEO-Diskurs stark von Koray Tuğberk GÜBÜR geprägt. Google selbst hat ein „Topic Authority“-System öffentlich nur für Nachrichtenergebnisse beschrieben (Mai 2023). Für generative Suche dokumentiert Google das Verfahren „Query Fan-out“: Das Modell stellt parallel verwandte Suchanfragen, um weitere relevante Ergebnisse abzurufen (Google-Leitfaden zu generativen KI-Funktionen). Eine Topical Map beantwortet genau diese Folgefragen im Voraus, auf einer Domain und sauber verlinkt. Laut demselben Leitfaden müssen Inhalte dafür nicht in Kleinstteile zerlegt werden. Für die Topical Map heißt das: Entscheidend ist die thematische Vollständigkeit, nicht die Zahl einzelner Seiten.
Sie besteht aus drei Ebenen:
1. Core Topic
Das zentrale Themenfeld, für das die Domain Autorität aufbauen soll (z. B. „KI-gestütztes SEO" für eine Agentur, „Nachhaltige Architektur" für ein Planungsbüro).
2. Cluster (Subtopics)
Hauptthemen-Cluster, die das Core Topic in vollständige Aspekte gliedern. Jeder Cluster hat eine Pillar-Page als zentralen Hub.
3. Satellites (Contextual Terms)
Detail-Inhalte, die spezifische Facetten eines Clusters behandeln. Sie verlinken zurück zur Pillar-Page und untereinander nach semantischer Logik.
„Eine gute Topical Map ist kein Content-Kalender. Sie ist eine Landkarte des Wissens, die erklärt, warum diese Domain die beste Quelle für dieses Thema ist: für Crawler, für Algorithmen und für LLMs."
Warum Keyword-Listen strukturell versagen
Eine traditionelle Keyword-Liste hat ein fundamentales Problem: Sie behandelt jede Query als isolierten Datenpunkt. Zwei Queries mit hohem Suchvolumen können semantisch redundant sein oder Teil völlig verschiedener Themenwelten. Eine Liste sieht das nicht.
Konkrete Fehlfolgen aus der Praxis:
- Kannibalisierung: Mehrere Seiten werden für semantisch überlappende Queries erstellt. Die Folge: Keine einzelne Seite baut klare Autorität auf, Google weiß nicht, welche zu ranken ist.
- Lücken: Wichtige Entity-Verbindungen fehlen, weil niemand ein relevantes Suchvolumen dafür gefunden hat, obwohl sie für die thematische Vollständigkeit entscheidend sind.
- Falsche Priorisierung: Seiten mit hohem Volumen werden priorisiert, auch wenn sie für die Topical Authority irrelevant sind. Seiten mit niedrigem Volumen, aber hohem semantischem Wert werden vernachlässigt.
- Keine semantische Hierarchie: Hub-Authority wird nicht aufgebaut, interne Verlinkung bleibt flach.
Die Methodik: Topical Map in 6 Schritten
Schritt 1: Core Topic definieren
Kein Brainstorming, sondern eine datenbasierte Entscheidung. Analysiert wird: welche Themen erzeugen die höchste Relevanz für das Business-Modell? Welche haben den höchsten strategischen Wachstums-Hebel? Welche sind realistisch dominierbar gegenüber dem Wettbewerb?
Schritt 2: Entity-Graph aufbauen
Das Core Topic wird in seine zugehörigen Entitäten zerlegt. Tools: Google Knowledge Graph API (Doku), WikiData SPARQL, InLinks, manuelles Entity-Mapping. Ergebnis: Ein Graph mit 30-150 zentralen Entitäten und deren Relationen.
Schritt 3: Query-Fan-Out pro Entität
Für jede Entität werden alle relevanten Informations-Queries ermittelt. Nicht aus Volumen-Sicht, sondern aus Vollständigkeits-Sicht: Was muss eine Quelle zu diesem Konzept sagen, um als umfassend zu gelten?
Schritt 4: Cluster-Bildung
Die Queries werden zu semantischen Clustern gruppiert. Pro Cluster: eine Pillar-Page + 5-15 Support-Artikel. Die Pillar definiert den Cluster, die Supports vertiefen Aspekte.
Schritt 5: Interne Link-Architektur
Eine Matrix wird erstellt, die für jede Seite definiert: Welche Pillar verlinkt sie? Welche Sibling-Artikel? Welche Cross-Cluster-Beziehungen? Die Link-Architektur ist nicht „viel Verlinkung", sondern gezielte semantische Gewichtung.
Schritt 6: Publikations-Reihenfolge
Die Reihenfolge der Content-Veröffentlichung folgt der Topical Map, nicht dem Redaktionskalender. Zuerst die Pillar-Seiten, dann systematisch die Supports, um Cluster-Authority schnell aufzubauen.
höhere Wachstumsraten bei cluster-basierten vs. Keyword-basierten Content-Strategien (SUMAX-Kundenanalyse, Evidenz C)
kürzere Time-to-Rank für Long-Tail-Queries in gut strukturierten Topical Maps (eigene Kundendaten)
höhere LLM-Citation-Rate für Domains mit klarer Entity-Architektur (eigene Messung)
Warum Topical Maps in der LLM-Ära noch wichtiger werden
Für klassische SEO war Topical Authority ein Ranking-Vorteil. Für GEO ist sie eine Existenzbedingung. Google betont, dass für AI Overviews und AI Mode dieselben SEO-Grundlagen gelten wie für die klassische Suche, weil diese Funktionen auf den Kern-Ranking-Systemen aufsetzen (Google-Leitfaden). In unseren Citation-Audits bevorzugen LLMs zudem Quellen mit hoher Entity-Abdeckung und semantischer Tiefe. Eine Domain, die ein Thema vollständig und strukturiert abdeckt, wird systematisch als autoritative Quelle erkannt. Eine Domain mit vereinzelten Artikeln zu Teilaspekten nicht.
Konkret verbessert eine solide Topical Map drei GEO-Metriken:
- Entity Clarity: Durch konsistente Verwendung klar definierter Entitäten über alle Seiten hinweg.
- Semantische Ko-Okkurrenz: Indem die Domain die Marken-Entität immer in Nähe zu thematisch relevanten Begriffen positioniert.
- Trust Density: Durch Tiefe und Vollständigkeit, die mit hoher Wahrscheinlichkeit als Expertensignal interpretiert werden.
Die unterschätzte Frage
Die wichtigste Diagnose-Frage für jede Content-Strategie: „Wenn ein Nutzer zu unserem Thema exakt eine Quelle lesen sollte, warum sollte das unsere sein?" Wenn die Antwort nicht in fünf Sätzen aus der Struktur der Domain erklärbar ist, hat die Topical Map ein fundamentales Problem. Keyword-Rankings sind dann nur Symptome, keine Diagnose.
Typische Fehler in der Umsetzung
- Über-Granularität: Die Map wird in 500 Micro-Artikel zerschlagen, die einzeln keine Substanz haben. Besser: weniger Artikel, mehr Tiefe pro Artikel.
- Fehlende Pillar-Hierarchie: Pillar-Seiten sind nur etwas längere Artikel statt echte Hubs mit umfassender Abdeckung.
- Interne Verlinkung als Nachgedanke: Links werden ad hoc gesetzt, nicht nach der Link-Architektur der Map.
- Keyword-Rückfall: Die Map wird erstellt, dann aber wieder aus Keyword-Volumen-Sicht priorisiert. Ergebnis: wieder das alte Problem.
- Keine Fortschreibung: Maps sind lebendige Dokumente. Sie müssen an neue Entitäten, neue Produkt-Themen, neue Marktentwicklungen angepasst werden.
Topical Authority Score: wie man Vollständigkeit quantifiziert
Topical Authority klingt weich. Sie lässt sich aber mit drei messbaren Komponenten annähern. Wir arbeiten mit dem Topical Authority Score (TAS), unserem eigenen Framework (Evidenz D), der für jede Domain-Thema-Kombination einen Wert zwischen 0 und 100 liefert.
TAS = 0,40 × EntityCoverage + 0,35 × InternalLinkCohesion + 0,25 × ExternalSignal
mit:
EntityCoverage = Anteil abgedeckter Entitäten / Gesamt-Entity-Graph × 100
InternalLinkCohesion = Verhältnis tatsächlicher zu möglicher semantischer Links × 100
ExternalSignal = Summe(Backlinks × TopicalRelevance) normalisiert × 100
Interpretation:
TAS < 40 = kein Autoritätssignal
TAS 40-65 = Sichtbarkeit vorhanden, aber ersetzbar
TAS 65-85 = Topical Authority
TAS > 85 = Category Leadership
Wichtig ist die Gewichtung: Entity Coverage dominiert mit 40 %, weil Vollständigkeit in unserem Modell der härteste Autoritätsindikator ist. Externe Signale zählen nur 25 %, denn Backlinks sind notwendig, aber nicht hinreichend für moderne Topical Authority. Das ist eine der größten strategischen Umstellungen gegenüber Link-Building-zentrierten SEO-Modellen.
Entity-Extraction-Workflow: so entsteht der Graph
Der Entity Graph ist das operationalisierte Fundament jeder Topical Map. Der Workflow, den wir bei Kundenmandaten anwenden, kombiniert vier Quellen und bleibt deterministisch reproduzierbar:
Source 1: Wikidata SPARQL-Query
Ausgehend vom Core-Topic-Entity holt eine SPARQL-Query alle verknüpften Entities über P279 (subclass of), P361 (part of), P527 (has part) und P1269 (facet of). Ergebnis: ein formaler Skelett-Graph mit 40-120 Knoten.
Source 2: SERP-Extraction
Für die Top-30-Queries des Core Topics werden die Top-10-SERP-Ergebnisse gescraped und durch die Google Natural Language API auf Entities analysiert. Entities, die in mindestens 40 % der Top-Ergebnisse auftauchen, gehen in den Graph.
Source 3: Competitor-Delta
Die Top-5-Wettbewerber werden auf ihren Entity-Footprint analysiert (NLP über deren Top-50-Seiten). Entities, die bei 3+ Wettbewerbern auftauchen, aber auf der eigenen Domain fehlen, sind kritische Lücken.
Source 4: LLM-Expansion
Ein Prompt gegen Claude oder GPT-5: „Liste alle Teilkonzepte, Methoden, Werkzeuge und angrenzenden Disziplinen zu [Core Topic]." Die Antwort wird dedupliziert und mit den anderen Quellen konsolidiert. LLMs liefern Konzept-Nachbarschaften, die Wikidata noch nicht kennt.
Die vier Quellen werden in einem Reconciliation-Step zusammengeführt. Jede Entity erhält einen Coverage-Score (0-1) basierend auf Anzahl der Quellen, die sie nennen. Entities mit Coverage ≥ 0,5 gehen in den Ziel-Graph; der Rest wird als Kandidaten-Liste parkiert.
Link-Architecture: die Silo-vs-Mesh-Entscheidung
Zwei Architektur-Paradigmen konkurrieren in der Praxis: Strict Silos und Semantic Mesh. Beide haben Berechtigung, aber die Wahl ist keine Geschmacksfrage, sie folgt aus dem Entity-Graphen.
Strict Silo arbeitet mit harten Grenzen: Pillar A verlinkt nur auf Supports A1-A12. Cross-Cluster-Links werden vermieden. Stark bei Themen mit klar getrennten Subfeldern und niedriger konzeptioneller Überlappung (z. B. „Produkt A" vs. „Produkt B" bei disjunkten Use Cases).
Semantic Mesh arbeitet mit kontrollierter Cross-Linking: Pillar A verlinkt auf die konzeptionell nächsten 2-3 Supports aus anderen Clustern. Stark bei Themen mit überlappenden Konzepten (z. B. „KI-SEO" und „GEO" teilen viele Entitäten).
Entscheidungskriterium: Der Jaccard-Koeffizient zwischen Entity-Sets zweier Cluster. Unsere Schwellenwerte aus der Projektpraxis: J > 0,25 → Mesh; J < 0,10 → Silo; dazwischen → Hybrid. Die Entscheidung folgt damit aus dem Graphen, nicht aus dem Bauchgefühl.
Jaccard-Schwelle für Mesh-Architektur
empfohlene interne Links pro Support-Seite
Pillar mit 25+ internen Verlinkungen nach 6 Monaten
Tutorial: Pillar-Page-Anatomie, die LLMs zitieren
Pillar-Pages sind keine langen Blog-Artikel. Sie sind strukturelle Hubs. Die folgende Anatomie hat sich bei uns als Citation-Magnet bewährt:
- Definition-Block (200-300 Wörter): direkt nach der H1. Enthält eine kanonische Definition des Core Topics, die als Passage zitierbar ist. Schema:
DefinedTerm. - Historische/konzeptionelle Einordnung (400-600 Wörter): warum existiert dieses Thema? Wer hat es geprägt? Welche angrenzenden Disziplinen?
- Struktur-Übersicht (visuell): eine Tabelle oder strukturiertes Layout, das die Cluster-Kinder zeigt. Tabellen werden in unseren Tests von LLMs besonders zuverlässig als Antwortstruktur übernommen.
- Cluster-Deep-Dives (je 300-500 Wörter pro Subtopic): in-page, bevor auf Supports verlinkt wird. Jeder Deep-Dive ist selbst eine zitierfähige Passage.
- Methodische Tiefe: mindestens eine Formel, ein Framework oder ein Entscheidungsbaum, der die Domain als originelle Quelle qualifiziert.
- Experten-Quotes: 2-3 originale Zitate mit Autor-Schema. Zitate stärken E-E-A-T-Signale und werden in unseren Citation-Audits häufig wörtlich übernommen.
- Verwandte Ressourcen: strukturierte Link-Sektion mit allen Support-Artikeln des Clusters.
- FAQ-Abschnitt: 6-10 Q&A als klar extrahierbare Frage-Antwort-Passagen. Das
FAQPage-Markup dient nur noch als semantische Deklaration — ein FAQ-Rich-Result in der SERP erzeugt es laut Google seit dem 7. Mai 2026 nicht mehr; der Zitierwert liegt in der Passagen-Struktur, nicht im Markup.
Länge einer exemplarischen Pillar in unseren Projekten: 3.500-5.500 Wörter. Das ist ein Erfahrungswert, kein Zielwert: Google hat laut eigener Doku keine bevorzugte Wortanzahl und nennt auch für generative Suche keine ideale Seitenlänge. Entscheidend ist, ob die Pillar das Thema vollständig abdeckt, nicht die Zahl der Wörter.
Case-Snapshot: SaaS-Domain, 9 Monate Topical Authority
Eigenes Kundenprojekt, anonymisiert (Evidenz C). Ausgangspunkt (Q2/2025, DACH-SaaS für Logistik-Digitalisierung): 340 existierende Artikel, verstreut, keine klare Cluster-Struktur. Monatlicher Non-Brand-Traffic: 28.000 Sessions. Top-10-Rankings: 412 Keywords.
Maßnahmen: Audit aller 340 Artikel, Klassifikation in (a) Pillar-Kandidaten, (b) Support-Kandidaten, (c) Low-Value-Content. 82 Artikel wurden zusammengefasst, 47 ersatzlos deindexiert, 120 in neue Cluster-Struktur überführt. 14 neue Pillar-Pages und 73 neue Support-Artikel produziert. Interne Verlinkung nach Mesh-Architektur (Jaccard des Entity-Graphs war 0,31).
Ergebnis nach 9 Monaten: Non-Brand-Traffic auf 71.000 Sessions (+154 %). Top-10-Rankings: 1.180 (+186 %). TAS für Core Topic: von 31 auf 79. Wichtigste Nebenwirkung: LLM-Citation-Rate für Brand-relevante Prompts stieg von 11 % auf 48 %. Die Topical Authority in klassischer SEO übersetzte sich in diesem Projekt weitgehend in GEO-Sichtbarkeit.
Aktualisierungs-Disziplin: die Topical Map als Living Document
In unserer Erfahrung sterben die meisten Topical Maps nach rund 6 Monaten, nicht weil sie falsch waren, sondern weil niemand sie pflegt. Der nötige Minimal-Turnus:
- Monatlich: Entity-Audit-Delta (neue Entitäten in SERPs/Wikidata, die im Graph fehlen).
- Quartalsweise: TAS-Neuberechnung, Identifikation der 3 schwächsten Cluster, Content-Sprint für Lücken.
- Halbjährlich: Wettbewerbsgraph-Refresh. Welche Entitäten haben Wettbewerber aufgenommen? Welche wurden irrelevant?
- Jährlich: Core-Topic-Review. Hat sich das Geschäftsmodell verschoben? Muss die Map strategisch neu ausgerichtet werden?
Fazit
Keyword-Recherche ist nicht tot. Sie ist ein Hilfsinstrument geworden, nicht mehr das Fundament. Das Fundament ist die strukturierte Darstellung von Wissen. Organisationen, die das verstehen und ihre Content-Prozesse entsprechend umstellen, bauen schneller Topical Authority auf, ranken stabiler über Algorithmus-Updates hinweg und werden häufiger von LLMs als Quelle ausgewählt.
Die anderen produzieren weiter Content für Keyword-Listen und wundern sich, warum die Rankings volatil bleiben, obwohl das Volumen wächst.
Quellen
- Understanding searches better than ever before (BERT), Google Blog, 25. Oktober 2019
- MUM: A new AI milestone for understanding information, Google Blog, Mai 2021
- Leitfaden zu Ranking-Systemen der Google Suche, Google Search Central, Stand Dezember 2025
- Importance of Topical Authority for SEO, Koray Tuğberk GÜBÜR, Holistic SEO
- Understanding news topic authority, Google Search Central Blog, Mai 2023
- Leitfaden von Google zur Optimierung für generative KI-Funktionen in der Google Suche, Google Search Central, Stand Juli 2026
- Hilfreiche, vertrauenswürdige, nutzerorientierte Inhalte erstellen, Google Search Central, Stand Dezember 2025
- Neueste Änderungen an der Dokumentation zur Google Suche (FAQ-Rich-Results eingestellt), Google Search Central, Mai 2026
- Google Knowledge Graph Search API, Google for Developers
- Entity Analysis, Cloud Natural Language API, Google Cloud
- Property P1269: facet of, Wikidata