Topical Maps nach Koray: Aufbau und praktische Umsetzung

Zuletzt aktualisiert: 20. August 2026

Was entsteht, wenn ich ein Hauptkeyword in ein SEO-Tool eingebe, die gefundenen Suchbegriffe clustere und daraus eine Seitenstruktur ableite? Das Ergebnis kann ein sinnvoller Content-Plan sein. Eine Topical Map nach dem Framework von Koray Tuğberk Gübür ist damit allerdings noch nicht entstanden.

Bei einer Topical Map wird zuerst geklärt, weshalb eine Website existiert, mit welcher zentralen Entität sie verbunden werden soll und welche Suchintention alle Seiten miteinander verbindet. Erst auf dieser Grundlage werden Entitäten und Attribute gesammelt. Keyword-Daten kommen später hinzu, wenn aus dem ersten Hypothesengerüst eine Processed Topical Map wird.

Der hier beschriebene Arbeitsablauf verbindet Korays Framework mit Query Templates und Visual Semantics. Für meine praktische Umsetzung kommt ein eigenes Prüfverfahren für Non-Commodity Content hinzu. Die Architektur der gesamten Website und das Briefing für eine einzelne Seite bleiben dabei getrennte Arbeitsschritte.

Der Artikel beschreibt den Stand vom 20. August 2026. Er unterscheidet zwischen Korays Framework, meiner praktischen Umsetzung und technischen Aussagen über Suchsysteme, die eine eigene Quellenprüfung benötigen.

Eine Topical Map ist mehr als ein Keyword-Cluster

Keyword-Tools gruppieren Suchanfragen meist anhand ähnlicher Wörter, Suchintentionen oder gemeinsamer Google-Ergebnisse. Derartige Cluster helfen bei der Recherche. Aus ihnen geht jedoch noch nicht hervor, welche Themen zum Geschäftsmodell einer Website passen, welche Seiten Geld verdienen sollen und in welche Richtung interne Links gesetzt werden.

Auch eine Concept Map verfolgt einen anderen Zweck. Sie ordnet Begriffe nach ihren sachlichen Beziehungen und kann beispielsweise zeigen, dass Deutschland an Frankreich grenzt oder dass eine Kreditkarte einen Verfügungsrahmen besitzt. Für eine Suchmaschine ist zusätzlich relevant, in welchen Suchkontexten Entitäten auftreten, welche Fragen Menschen nacheinander stellen und welche Ergebnisse dieselbe Aufgabe erfüllen.

Korays Topical Map verbindet deshalb eine Wissensstruktur mit Query-Daten und dem Geschäftsmodell der Quelle. Die theoretische Grundlage beschreibt er in seiner Darstellung zur Topical Authority und zum Semantic Content Network. Topical Authority ist dabei ein Modell aus der SEO-Praxis. Google stellt Websitebetreibern keine Kennzahl namens Topical Authority zur Verfügung.

Der Unterschied lässt sich an einer Visa-Beratung zeigen. Eine enzyklopädische Sammlung über Deutschland könnte von der Bundesliga über Flüsse bis zu Feiertagen reichen. Für eine Website, die Menschen bei Einreise, Studium oder Arbeit unterstützt, sind viele dieser Themen ohne geschäftlichen Bezug. Die Topical Map muss daher erklären, weshalb ein Attribut aufgenommen wird und welche Verbindung es zu den Leistungen der Beratung besitzt.

Fünf Entscheidungen stehen vor der Keyword-Recherche

In meiner praktischen Umsetzung beginnt jedes Projekt mit fünf Komponenten. Diese Entscheidungen lassen sich kaum aus einem Tool exportieren, weil hierfür das Unternehmen, seine Leistungen und die gewünschte Positionierung verstanden werden müssen.

Source Context

Der Source Context beschreibt das Geschäftsmodell und die Identität der Quelle. Bei einem Online-Shop liegt der wirtschaftliche Zweck im Verkauf. Eine B2B-Website soll dagegen womöglich qualifizierte Anfragen erzeugen, während eine lokale Praxis Termine benötigt.

Aus diesem Quellenkontext entsteht der erste Filter für die spätere Themenauswahl. Ein häufig gesuchtes Attribut kann zur zentralen Entität gehören und trotzdem ungeeignet sein, wenn es keinerlei Verbindung zu den Leistungen oder zur Positionierung des Unternehmens besitzt.

Central Entity

Die Central Entity ist die zentrale Entität, die auf allen Seiten der Map vorkommt oder den gemeinsamen Bezugspunkt bildet. Ihr Typ folgt im Framework dem Nutzerverhalten und dem Source Context. Bei einer Website für Visa und das Leben in Deutschland kann deshalb Deutschland die zentrale Entität sein, obwohl Visa auf den ersten Blick wie das naheliegendere Hauptthema wirken.

Für die Auswahl prüfe ich unter anderem Wikipedia und Wikidata, vorhandene Knowledge Panels sowie die wiederkehrenden Bestandteile realer Suchanfragen. Hat eine Website mehrere voneinander getrennte Geschäftsbereiche, können mehrere Topical Maps mit jeweils eigener Central Entity erforderlich sein.

Central Search Intent

Der Central Search Intent verbindet die zentrale Entität mit dem Zweck der Quelle. Formuliert wird er über ein oder zwei Verben. Bei der Visa-Website können dies beispielsweise Deutschland kennenlernen und nach Deutschland gehen sein.

Weshalb Verben für diese Entscheidung hilfreich sind, habe ich in meinem Artikel über den Start eines SEO-Projekts mit Entitäten und Verben ausführlicher beschrieben. Dieselbe Entität aktiviert je nach Verb einen anderen Wissensrahmen. Eine Wärmepumpe einzubauen führt daher in ein anderes Query-Netzwerk als eine Wärmepumpe zu warten.

Core Section und Outer Section

In der Core Section liegen die Seiten, die besonders nah am Source Context und an der Monetarisierung sind. Bei einer Visa-Beratung wären dies beispielsweise Seiten zu unterschiedlichen Visa-Arten oder Beratungsleistungen. Diese Seiten behandeln das wirtschaftlich wichtigste Attribut vergleichsweise tief.

Die Outer Section deckt weitere Attribute der Central Entity ab. Hierzu können bei Deutschland etwa Lebenshaltung, Sprache oder Studium zählen, sofern diese Themen mit dem Central Search Intent verbunden werden können. Interne Links führen aus dieser äußeren Sektion gezielt in die Core Section.

Wo die Grenze zwischen beiden Bereichen verläuft, hängt vom jeweiligen Unternehmen ab. Dieselbe Seite kann bei einem Geschäftsmodell zur Core Section und bei einem anderen zur Outer Section gehören. Deswegen lässt sich diese Entscheidung nicht allein aus dem Suchvolumen ableiten.

ICP oder Buyer Persona

Als fünfte Komponente lege ich fest, für wen die Map gebaut wird. Bei einem B2B-Projekt arbeite ich meist mit einem Ideal Customer Profile, kurz ICP. Für Shops und lokale Unternehmen ist eine Buyer Persona oftmals geeigneter. Diese Festlegung beeinflusst unter anderem, welche Probleme, Begriffe und Seitentypen später priorisiert werden.

Attribute werden in einer festen Reihenfolge gefiltert

Stehen die fünf Komponenten fest, werden Entitäten und ihre Attribute gesammelt. Eine Stadt besitzt beispielsweise eine Einwohnerzahl, eine Fläche, einen Bürgermeister und womöglich einen bekannten Hafen. Für die Map sind diese Eigenschaften allerdings unterschiedlich wichtig.

Korays Filtration folgt der Reihenfolge Relevance, Prominence und Popularity. Zuerst wird geprüft, ob ein Attribut zum Source Context passt. Fehlt diese Relevanz, wird es aus der Map entfernt. Danach folgt die Frage, wie stark das Attribut die Entität definiert. Erst im dritten Schritt wird anhand der Search Demand priorisiert.

Relevance ist hierbei kein gleichrangiges Kriterium neben Prominence und Popularity, sondern der vorgeschaltete Filter. Erst wenn ein Attribut zum Quellenkontext passt, werden seine Bedeutung für die Entität und die vorhandene Nachfrage bewertet. Ein populäres und prominentes Thema fällt deshalb weiterhin heraus, wenn es den Quellenkontext der Website verwässert.

Zusätzlich unterscheidet das Framework Root-, Rare- und Unique-Attribute. Root-Attribute kommen bei allen Entitäten einer Klasse vor. Rare-Attribute treffen nur auf einen Teil dieser Entitäten zu. Ein Unique-Attribut gehört zu einer einzelnen Entität. In der späteren Content-Planung werden Unique-Attribute zuerst berücksichtigt, weil sie eine Seite besonders genau qualifizieren können.

Keyword-Daten ergänzen die Raw Topical Map

Eine Raw Topical Map besteht zunächst aus den gefilterten Beziehungen zwischen Entitäten und Attributen. Sie ist ein Hypothesengerüst. An dieser Stelle wäre es ebenso falsch, Keyword-Daten vollständig auszuschließen, wie das gesamte Projekt mit einem Keyword-Export zu beginnen.

Für die Processed Topical Map sammele ich Suchanfragen aus Semrush, der Google Search Console, AlsoAsked und den Suchergebnissen. Bei einem Relaunch sind die bisherigen Suchanfragen der Website besonders wertvoll, weil sie zeigen, für welche Themen Google die Quelle bereits eingeordnet hat.

Mit diesen Daten lassen sich die zuvor gebildeten Beziehungen überprüfen. Sie zeigen beispielsweise, ob Menschen eine Frage tatsächlich stellen, welche Varianten zusammengehören und ob Google für zwei Suchanfragen überwiegend dieselben Seiten anzeigt. Bei unklaren Fällen prüfe ich deshalb den SERP-Overlap, also die Überschneidung der rankenden URLs.

Query Templates erweitern die Entity-Attribute-Methode

Im August 2026 veröffentlichte Koray eine weitere Methode für den Aufbau von Topical Authority. Sein Beitrag über Query Templates betrachtet wiederkehrende Suchmuster mit austauschbaren Bestandteilen.

Ein solches Muster wäre beispielsweise „Colocation in {Stadt}“ oder „{Dateiformat} in Text umwandeln“. Die einzelnen Städte oder Dateiformate gehören jeweils zur selben Schablone. Ihre Suchanfragen können dennoch unterschiedliche Prädikate, Aufgaben und erwartete Seitentypen besitzen.

Damit stehen zwei Wege zur Verfügung. Die klassische Methode untersucht Entitäten und ihre Attribute. Die Query-Template-Methode untersucht ein wiederkehrendes Suchformat. In einem hybriden Ansatz werden Entitäten, Attribute und Template-Variationen miteinander verbunden.

Aus einem Template folgt jedoch noch keine eigene Seite für jede denkbare Kombination. Ob aus einer Suchanfrage eine URL, eine Überschrift oder lediglich eine Passage wird, muss in einem weiteren Schritt entschieden werden.

Welche Suchanfrage benötigt eine eigene Seite?

Koray bezeichnet diese Entscheidung als Query Deserves a Page, kurz QDP. In meinem Prozess wird das Gate um Query Deserves a Heading und Query Deserves a Sentence ergänzt. Dadurch erhält jede Suchanfrage genau die Ebene, die ihrem eigenständigen Informationsbedarf entspricht.

Stufe	Umsetzung	Wann sie verwendet wird
QDP	eigene Seite	Die Suchanfrage erfüllt mindestens drei der vier QDP-Kriterien.
QDH	eigene Überschrift	Die Frage bildet einen eigenen Teilaspekt, benötigt jedoch keine separate URL.
QDS	Satz oder Absatz	Die Suchanfrage ist eine Variante ohne eigenständigen Informationsbedarf.

Für eine eigene Seite prüfe ich Search Demand, beteiligte Entitäten, die inhaltliche Ähnlichkeit der Suchanfragen und ein erkennbares wiederholbares Muster. Erfüllt eine Variante mindestens drei dieser vier Kriterien, wird sie zum Kandidaten für eine eigene URL. Bei knappen Entscheidungen können der erwartete Seitentyp und die Überschneidung der Suchergebnisse den Ausschlag geben.

Dieses Gate verhindert, dass für jede Stadt, jeden Preis, jede Definition und jede geringfügige Keyword-Variation eine eigene Seite angelegt wird. Manchmal rankt eine umfassende Seite für mehrere Varianten besser. In anderen Fällen unterscheiden sich Aufgabe und Entität so deutlich, dass getrennte Seiten sinnvoll sind.

Aus der Raw Map entsteht eine Processed Topical Map

Nach der Filterung und dem QDP-Gate wird aus den gesammelten Beziehungen eine konkrete Seitenarchitektur. Jede Zeile der Processed Topical Map entspricht einer geplanten oder vorhandenen Seite. Zu dieser Zeile gehören unter anderem Seitentyp, Core- oder Outer-Zuordnung, interne Linkziele, Publikationsreihenfolge und die untergeordneten Fragen.

Die Hierarchie kann als Root, Seed und Node beschrieben werden. Das Root-Dokument bildet den obersten thematischen Bezugspunkt. Seeds gliedern die Hauptbereiche. Darunter liegen die einzelnen Nodes, aus denen das eigentliche Seitennetzwerk entsteht. Diese Ebenen beeinflussen die URL-Struktur und die internen Links.

Ein Root-Dokument muss nicht bei jedem Projekt als erste Seite veröffentlicht werden. Bei einer jungen Marke beginne ich häufig mit Outer-Seiten zu klaren Fragen, weil sie früher Impressionen und Klicks gewinnen können. Die Core Section folgt, sobald die Quelle erste historische Daten aufgebaut hat und die zentrale Nachfrage genauer erkennbar wird.

Auch die Publikationsreihenfolge bleibt keine dauerhafte Festlegung. Nach einigen Monaten zeigen die Daten aus der Google Search Console, welche Fragen gewonnen, verloren oder zwischen mehreren Seiten geteilt werden. Auf dieser Grundlage werden Inhalte, interne Links und gegebenenfalls die Grenze zwischen Core und Outer angepasst.

Topical Map und Content-Briefing sind getrennte Arbeitsschritte

Contextual Vector, Heading-Reihenfolge und die genaue Position interner Links gehören nicht mehr zur Topical Map. Diese Entscheidungen werden im anschließenden Content-Briefing für eine einzelne Map-Zeile getroffen.

Die Topical Map beantwortet, welche Seiten benötigt werden und wie diese Seiten miteinander verbunden sind. Das Content-Briefing legt danach fest, wie eine konkrete Seite aufgebaut wird. Hierzu zählen der Macro Context, der ergänzende Micro Context, die Reihenfolge der Überschriften, Antwortformate und die genaue Position interner Links.

Der Contextual Vector beschreibt in diesem Arbeitsschritt die geordnete Folge der Fragen innerhalb eines Dokuments. Die Überschriften sollen eine verständliche Linie ergeben. Der Hauptteil behandelt den Macro Context, während angrenzende oder gegensätzliche Fragen in den späteren Supplementary Content wandern. Den Unterschied zwischen beiden Bereichen erläutere ich ausführlicher in meinem Artikel über Macro Context und Micro Context in SEO-Texten.

Visual Semantics ergänzt die Textstruktur

Im Juli 2026 ergänzte Koray diesen Prozess um eine deutlich ausgearbeitete visuelle Ebene. In seinem Beitrag über Visual Semantics und Topical Authority beschreibt er, wie Layout und funktionale Komponenten die Bedeutung einer Seite verdeutlichen.

Für das Briefing reicht es dadurch nicht mehr aus, ausschließlich Überschriften und Pflichtbegriffe festzulegen. Eine Preisfrage kann beispielsweise eine Tabelle benötigen. Bei einem Rechner bildet das Tool die wichtigste Komponente der Seite und sollte weit oben erscheinen. Verwandte Unterthemen lassen sich je nach Aufgabe in Karten, Tabs oder einem Akkordeon darstellen.

In meinem praktischen Skill wird deshalb für jede Seite ein Centerpiece bestimmt. Zusätzlich erhält jede Überschrift eine passende UI-Komponente. Seiten derselben Template-Familie verwenden an derselben Position ein vergleichbares Layout, während sich ihre inhaltliche Substanz weiterhin unterscheiden muss.

Non-Commodity Content wird vor der Produktion geprüft

Seit KI-Antworten allgemeines Wissen direkt in den Suchergebnissen zusammenfassen, reicht eine strukturell saubere Seite für sich genommen nicht mehr aus. Google empfahl Websitebetreibern im Mai 2025 ausdrücklich, einzigartige und nicht austauschbare Inhalte für die KI-Suche zu erstellen.

In der Google-Dokumentation zur Optimierung für generative Suchfunktionen wird diese Anforderung inzwischen genauer beschrieben. Inhalte sollen auf eigener Erfahrung und Wissen beruhen. Eine Zusammenfassung dessen, was bereits im Internet steht oder leicht von einem generativen Modell erzeugt werden kann, genügt demnach nicht.

Diese Google-Empfehlung habe ich für meine Topical-Map-Praxis als 6-Fragen-Check operationalisiert. Vor der Produktion einer Seite prüfe ich:

1. Kann ein aktuelles Sprachmodell den geplanten Inhalt ohne unsere Informationen vollständig erzeugen?
2. Liegen eigene Daten, Messwerte, Fälle, Bilder oder andere Erstinformationen vor?
3. Behandelt die Seite eine konkrete Situation oder nur allgemeine Regeln?
4. Sind Menschen mit nachweisbarer Erfahrung als Autoren, Experten oder Gesprächspartner sichtbar?
5. Weshalb sollte jemand trotz einer vorhandenen KI-Antwort auf das Suchergebnis klicken?
6. Enthält die Seite Aussagen, Daten oder Definitionen, auf die sich andere Quellen konkret beziehen können?

Aus den Antworten entsteht eine Einteilung in Commodity, Hybrid und Non-Commodity. Eine Hybrid-Seite geht erst in die Produktion, wenn mindestens eine konkrete Substanzquelle feststeht. Das können Projekterfahrungen, Servicedaten, Expertenaussagen, Messungen oder eigenes Bildmaterial sein. Fehlt diese Grundlage, wird die Seite konsolidiert, auf einen konkreteren Fall begrenzt oder bewusst als schlanke Stützseite freigegeben.

Gerade bei Query Templates ist diese Prüfung nötig. Hundert Seiten, auf denen lediglich die Stadt oder ein Produktname ausgetauscht wird, erzeugen keine hundert eigenständigen Beiträge. Google bezeichnet die massenhafte Erstellung unorigineller Seiten ohne Mehrwert in seinen Spamrichtlinien als Scaled Content Abuse. Dabei ist unerheblich, ob die Seiten von Menschen, mit KI oder durch andere automatische Verfahren erstellt wurden.

Non-Commodity Content ist in dieser Form meine operative Ergänzung. Sie verbindet Googles aktuelle Vorgaben mit Korays Regeln zu Unique Attributes, Human Effort und funktionalen Seiten. Der 6-Fragen-Check selbst stammt daher nicht aus einer einzelnen Veröffentlichung von Koray.

Korays Framework ist ein eigenständiges Praxismodell

Viele Begriffe dieses Artikels stammen aus Korays Kursen, Veröffentlichungen und Fallstudien. Dazu zählen Source Context, Central Search Intent, die Core- und Outer-Architektur sowie der Contextual Vector. Diese Konzepte sind für die praktische SEO außerordentlich nützlich. Ihre Qualität zeigt sich an einer schlüssigen Seitenarchitektur und später an den Projektdaten, nicht daran, ob Google dieselben Begriffe verwendet.

Suchverhalten und Query-Pfade können bei der Einordnung thematischer Zusammenhänge berücksichtigt werden. Für meine Planung sind sie ein Datenbereich unter mehreren: Inhalte, Links, Entitäten, Seitentypen und die Entwicklung einzelner Suchanfragen müssen gemeinsam betrachtet werden. Eine praktische Analyse sollte deshalb weder jede Veränderung aus Nutzersessions erklären noch nach einem Core Update automatisch neu berechnete semantische Abstände voraussetzen.

Auch Begriffe aus Google-Patenten oder dem 2024 bekannt gewordenen Content Warehouse dürfen nicht automatisch als bestätigte Ranking-Faktoren behandelt werden. Ein Patent zeigt zunächst, dass ein Verfahren beschrieben und geschützt wurde. Ob Google es aktuell einsetzt und welches Gewicht es gegebenenfalls besitzt, lässt sich daraus allein nicht ableiten.

Deswegen kennzeichne ich bei der Arbeit, ob eine Regel aus einer offiziellen Google-Quelle, aus Korays Framework oder aus meiner eigenen Operationalisierung stammt. Diese Trennung macht eine Topical Map nicht weniger praktisch. Sie verhindert allerdings, dass aus einem hilfreichen Modell eine vermeintlich gesicherte Beschreibung des Google-Algorithmus wird.

So erstelle ich eine Topical Map heute

Aus den beschriebenen Regeln ergibt sich für meine Projekte ein mehrstufiger Ablauf:

1. Zuerst werden Source Context, Central Entity, Central Search Intent, Core und Outer sowie die Zielgruppe festgelegt.
2. Danach sammele ich relevante Entitäten, Attribute und mögliche Authority Sources innerhalb der Knowledge Domain.
3. Die Attribute werden in der Reihenfolge Relevance, Prominence und Popularity gefiltert.
4. Suchanfragen aus Semrush, Google Search Console, AlsoAsked und den Suchergebnissen ergänzen und überprüfen die Raw Topical Map.
5. Wiederkehrende Suchmuster werden als Query Templates erfasst. Mit QDP, QDH und QDS entscheide ich anschließend über Seite, Überschrift oder Passage.
6. Aus den bestätigten Seiten entsteht die Processed Topical Map mit Hierarchie, URLs, internen Links und Publikationsreihenfolge.
7. Vor der Produktion erhält jede Seite eine Commodity-Klasse und eine benannte Quelle für eigene Informationen.
8. Erst danach wird aus einer Map-Zeile ein Content-Briefing mit Contextual Vector, Antwortformaten, UI-Komponenten und Quellenhinweisen.

Automatisieren lassen sich dabei vor allem Recherche, Datenabfragen, Vorstrukturierung und die Erstellung der Arbeitsdateien. Die wichtigsten Entscheidungen bleiben urteilsabhängig. Ein Tool kennt weder das Geschäftsmodell eines Unternehmens vollständig noch kann es zuverlässig entscheiden, welche Themen außerhalb des Source Context liegen oder ob für eine geplante Seite ausreichende eigene Informationen vorhanden sind.

Aus diesem Grund enthält mein eigener Topical-Map-Skill mehrere feste Checkpoints. Bevor Queries gesammelt werden, prüfe ich die fünf Komponenten. Nach dem Clustering werden Core und Outer sowie die Merge- und Split-Entscheidungen kontrolliert. Eine finale Prüfung folgt erst, wenn jede Seite eine nachvollziehbare Funktion innerhalb der gesamten Architektur besitzt.

Eine Topical Map bleibt ein Arbeitsmodell

Eine gute Topical Map ist kein bunter Export aus einem Keyword-Tool. Sie verbindet das Geschäftsmodell einer Quelle mit Entitäten, Attributen, Suchanfragen und einer begründeten Seitenarchitektur. Query Templates, Visual Semantics und die Prüfung auf Non-Commodity Content gehören für mich zu diesem Arbeitsmodell.

Ebenso wenig ist die Map nach ihrer Fertigstellung abgeschlossen. Reale Suchanfragen, Rankings und Klicks zeigen später, welche Annahmen zutrafen und an welchen Stellen Seiten zusammengeführt, erweitert oder anders verlinkt werden sollten. Bei einer deutlichen Veränderung der Nachfrage kann sich sogar die Core Section verschieben.

Für mich ist eine Topical Map deshalb eine dokumentierte Hypothese über die beste Content-Architektur einer Website. Ihr Wert liegt darin, dass jede Seite, jede Verbindung und jede Produktionsentscheidung begründet werden kann. Ob diese Entscheidungen funktionieren, wird anschließend anhand der Daten geprüft und über die weitere Content Configuration angepasst.