KI-Keyword-Clustering: Suchanfragen in Content-Serien und interne Links überführen

Eine keywords.csv enthält 300 Suchanfragen zu Astro, Docker und Cloudflare. Die KI bildet daraus 42 Cluster. Bei der manuellen Prüfung liegen jedoch astro seo und astro vs next.js for seo gemeinsam in Cluster #1. Das erste Keyword steht für eine Anleitung, das zweite für einen Vergleich. Eine Seite wird beide Aufgaben kaum gleich gut erfüllen.

Genau dort scheitert Keyword-Clustering häufig: Die KI fasst semantisch ähnliche Begriffe mit unterschiedlicher Intention zusammen. Das erhöht das Risiko von Content Cannibalization, weil mehrere fast gleiche Beiträge um dieselbe Nachfrage konkurrieren. Eine Liste von „Keyword-Gruppen“ beantwortet außerdem nicht, welche Gruppe einen neuen Beitrag, eine Aktualisierung, eine FAQ oder nur einen internen Link braucht.

Der folgende Ablauf kombiniert GSC-Queries, Themenkarten und den vorhandenen Content-Bestand in einer Tabelle. Er normalisiert und dedupliziert die Daten, lässt nach der KI-Vorgruppierung eine menschliche Prüfung folgen und ordnet jedes Cluster einer Aktion zu: neuer Beitrag, Aktualisierung, FAQ, interner Link oder discard. Zu den Ergebnissen gehören Datenquellen, Normalisierungslogik, Methodenvergleich, KI-Prompt, Cluster-Map, Aktionsrahmen und Linkstruktur.

1. Die richtigen Datenquellen für das Keyword-Clustering zusammenführen

Die Eingabe besteht nicht aus von der KI erfundenen Begriffen, sondern aus eigenen query/page-Daten, Themenkarten und dem Artikelbestand. Erst diese Kombination zeigt, welche Themen sich lohnen, wo bereits eine Zielseite existiert und welche Formulierungen aus echten Community-Fragen stammen.

Die Datenquellen sehen so aus:

Schritte:

1. GSC-query/page-Daten exportieren. Der Performance-Bericht zeigt standardmäßig die letzten drei Monate, der Zeitraum lässt sich aber an die Aufgabe anpassen.
2. Die Themenkarten des Recherche-Agenten ergänzen.
3. Den Content-Bestand mit vorhandenen Artikeln, Serien und Performance auslesen.
4. Quick Wins markieren: viele impressions bei niedriger CTR und Chancen zur Aktualisierung alter Beiträge.
5. Eine gemeinsame Tabelle ausgeben, deren Zeilen query, vorläufige Intention, Quelle, Treffer auf einen alten Beitrag und quickWins-Markierung enthalten.

2. Keywords vor dem Clustering normalisieren

Die gemeinsame Tabelle enthält viele Duplikate, ähnliche Varianten und unterschiedliche Schreibweisen. Ohne Bereinigung kann die KI sie als eigene Keywords behandeln und eine Intention auf mehrere Cluster verteilen.

Checkliste zur Deduplizierung:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

• Exaktes Duplikat: astro seo vs astro seo → eine Zeile behalten
• Schreib- oder Konfigurationsvarianten: docker host.docker.internal vs docker host-gateway vs docker 127.0.0.1 → als Kandidaten derselben Intention markieren und manuell bestätigen
• Synonyme: cloudflare pricing vs cloudflare Preise vs cloudflare cost → als eine Intention markieren
• Flexion einer Entität: astro blog vs astro blogs → als eine Intention markieren

Normalisierungsregeln:

• Begriffe vereinheitlichen: nextjs → next.js, cloudflare workers → Cloudflare Workers
• Groß- und Kleinschreibung vereinheitlichen: Astro vs astro → astro
• Satzzeichen vereinheitlichen: astro, seo vs astro seo → astro seo

Vorläufige Intent-Labels:

• Informativ: how to, what is, guide, tutorial
• Navigationsorientiert: Markenname, Produktname, bestimmte URL
• Vergleichend: vs, compare, alternative
• Transaktional: pricing, cost, buy, download

Schritte:

1. Exakte Duplikate aus der gemeinsamen Tabelle entfernen.
2. Schreibvarianten und Synonyme erkennen und als Kandidaten derselben Intention markieren.
3. Begriffe, Groß- und Kleinschreibung sowie Satzzeichen normalisieren.
4. Jede query als informativ, navigationsorientiert, vergleichend oder transaktional markieren.
5. Eine normalisierte Tabelle mit query, normalized_query, intent_tag, source und old_post_match ausgeben.

3. Drei Methoden für Keyword-Clustering vergleichen

Bei der Auswahl müssen Kosten, Genauigkeit und Risiko zusammenpassen. Die drei verbreiteten Methoden eignen sich für unterschiedliche Betriebsphasen.

Empfohlener Ablauf:

• Kleines Team / frühe Phase: semantische Vorgruppierung + GSC/page-Prüfung + menschliche Kontrolle riskanter Cluster
• Größeres Team / etablierte Inhalte: Hybrid aus semantischer Gruppierung, SERP/GSC-Prüfung und menschlicher Kontrolle
• Ausreichendes Budget + Entscheidung über Seitenüberschneidungen: SERP-based + menschliche Kontrolle

Ich verwende die Hybrid-Variante: Zuerst entsteht eine Gruppierung nach semantischer Ähnlichkeit. Danach zeigt GSC page, welche Queries bereits eine Zielseite haben. Zum Schluss löst ein Mensch Konflikte zwischen Suchintentionen.

4. KI-Clustering mit einem festen Ausgabeformat ausführen

Beim Übergeben der normalisierten Keywords muss der Prompt die Ausgabefelder und Intent-Regeln klar benennen. Das folgende Format ist dafür geeignet.

Beispiel für einen KI-Prompt:

Du bist ein SEO-Content-Planer. Gruppiere die folgenden normalisierten Keywords nach Suchintention in Cluster. Gib für jedes Cluster Folgendes aus:
1. primary_intent
2. canonical_page (empfohlener Zieltyp: new article / old post refresh / FAQ / discard)
3. suggested_action
4. internal_link_targets (vorhandene Artikel oder Serien, die verlinkt werden sollen)
5. risk_notes (mögliche Cannibalization oder notwendige menschliche Prüfung)

Keywords:
- astro seo
- astro vs next js for seo
- cloudflare pricing
- docker host.docker.internal
- docker host-gateway
...

Gib ein JSON-Array zurück. Jedes Cluster folgt diesem Format:
{
  "cluster_id": 1,
  "keywords": ["astro seo", ...],
  "primary_intent": "informativ - Anleitung",
  "canonical_page": "new article",
  "suggested_action": "Astro-SEO-Anleitung erstellen",
  "internal_link_targets": ["astro-guide-Serie", "cloudflare-bindui-Serie"],
  "risk_notes": "Menschliche Prüfung nötig: astro vs next js for seo hat Vergleichsintention und darf nicht zusammengeführt werden"
}

Beispiel einer Cluster-Map:

Checkliste für die menschliche Prüfung:

• Gemischte Intention: Ein Cluster enthält Tutorial- und Vergleichsqueries → aufteilen
• Konflikt mit einer vorhandenen Seite: Ein Cluster ist „new article“, obwohl eine verwandte Seite existiert → auf old post refresh oder FAQ ändern
• Zu starke Aufteilung: Eine Intention liegt in mehreren Clustern → zusammenführen
• Zu starke Zusammenfassung: Verschiedene Intentionen liegen in einem Cluster → aufteilen

Schritte:

1. Die normalisierte Tabelle an Claude, ChatGPT oder einen internen KI-Clustering-Ablauf übergeben.
2. Mit dem obigen Prompt die Vorgruppierung ausführen.
3. Die Cluster-Map exportieren.
4. Intent-Konflikte, Treffer auf alte Beiträge, zu starke Aufteilung und zu starke Zusammenfassung prüfen.
5. Die Cluster-Map korrigieren und riskante Cluster markieren.

5. Jedes Cluster einer Content-Aktion zuordnen

Ein fertiges Cluster braucht eine umsetzbare Aktion statt einer weiteren Keyword-Liste. Dafür verwende ich diese Entscheidungstabelle.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Definitionen der Aktionen:

• Neuer Beitrag: Eine Seite erstellen, die alle Queries mit derselben Intention im Cluster abdeckt.
• Pillar-Seite: Einen Serien-Hub erstellen, der auf die anderen Cluster-Seiten verweist.
• Aktualisierung: Eine vorhandene Seite um die neuen Queries erweitern.
• FAQ: Eine fokussierte Antwort in einem vorhandenen Artikel ergänzen.
• Interne Verlinkung: Kontextbezogene Links zur kanonischen Seite hinzufügen.
• Discard: Keinen Inhalt erstellen; als niedrigen Wert oder außerhalb der Zielgruppe markieren.

Schritte:

1. Jedes Cluster anhand der Entscheidungsfaktoren bewerten.
2. Die Bewertung einer Aktion zuordnen.
3. Eine Aktionsliste im Format cluster_id → suggested_action ausgeben.
4. Risikoreiche Aktionen wie neue Beiträge und Pillar-Seiten manuell prüfen.

Die Query-Anzahlen in der Tabelle sind Beispielsignale und keine festen Schwellenwerte. Die endgültige Aktion hängt weiterhin von Intention, Bestand, eigenem Mehrwert und Wartungskosten ab.

6. Interne Links als Navigationskarte des Clusters planen

Beziehungen zwischen Clustern müssen zu umsetzbaren internen Links werden und dürfen nicht in einem allgemeinen Block „Ähnliche Artikel“ enden. Dafür eignet sich folgende Struktur.

Grundsätze für interne Links:

• Bidirektionale Pillar-/Cluster-Links: Die Pillar-Seite verlinkt alle Cluster-Seiten, und jede Cluster-Seite verlinkt zurück.
• Beschreibender Ankertext: Die Zielintention benennen, statt „hier klicken“ zu schreiben.
• Kanonische Ziele: Nicht auf doppelte oder fast identische Seiten verlinken, sondern auf die bevorzugte kanonische URL.
• Keine verwaisten Artikel: Für jeden Beitrag mindestens einen kontextbezogenen eingehenden Link planen und bei passender Seitenstruktur weitere Wege ergänzen.
• internal_link_targets in der Cluster-Map: Speichern, welche vorhandenen Artikel oder Serien verlinkt werden sollen.

Interner Linkplan:

Schritte:

1. Pillar- und Cluster-Seiten bestimmen.
2. Die bidirektionale Linkstruktur planen.
3. Für jeden Link einen beschreibenden Ankertext wählen.
4. Nach verwaisten Artikeln suchen.
5. Den internen Linkplan in die Content-Aufgabentabelle exportieren.

Google behandelt Redirects und rel="canonical" derzeit als starke Signale für die Kanonisierung und die Aufnahme in eine Sitemap als schwächeres Signal. Mehrere Signale können sich verstärken, doch Google wählt die kanonische URL weiterhin selbst. Interne Links sollten konsequent auf die bevorzugte URL zeigen.

7. Qualitätsgrenzen gegen die Massenproduktion ähnlicher Seiten setzen

Keyword-Clustering darf nicht zum Generator vieler Seiten werden. Ein solcher Ablauf entfernt sich schnell von nutzerorientierten Inhalten.

Risikogrenzen:

• Nicht für jede Keyword-Variante eine Seite erstellen. Queries mit derselben Intention gehören auf eine Seite oder zu einem kanonischen Ziel.
• Eine Prüfung des eigenen Mehrwerts verlangen. Jedes Cluster muss ein Leserproblem, den Themenfokus der Website und einen sinnvollen Zusatz gegenüber vorhandenen Inhalten abbilden.
• Queries mit derselben Intention um ein kanonisches Ziel konsolidieren. Bei doppelten oder sehr ähnlichen Seiten können Redirects, rel="canonical" und Sitemaps eine Präferenz ausdrücken, doch die Signale sind unterschiedlich stark und garantieren Googles Auswahl nicht.
• Search-engine-first-Content vermeiden. Der Hauptzweck ist Hilfe für Leser und nicht die Manipulation von Rankings.
• Cannibalization-Risiken senken. Viele Seiten für nahezu identische Keywords können mehrere URLs um dieselbe Suchintention konkurrieren lassen.
• Riskante Cluster markieren. Über das Feld risk_notes in der Cluster-Map wird eine menschliche Prüfung verlangt.

Qualitative rote Linien:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• Bei einem passenden alten Beitrag eine Aktualisierung oder FAQ vor einer weiteren ähnlichen Seite bevorzugen.
• Jede Clustering-Ausgabe muss Themenfit und eigenen Mehrwert bewerten.
• Interne Links auf den kanonischen Artikel und nicht auf doppelte oder ähnliche Seiten richten.

8. Den Ablauf an Astro SEO, Cloudflare Pricing und Docker prüfen

Drei Beispiele machen den gesamten Ablauf greifbar.

Beispiel 1: astro seo vs. astro vs next.js for seo (unterschiedliche Intention, daher trennen)

• Ursprüngliche Queries: astro seo, astro vs next.js for seo, astro blog seo
• Normalisiert: astro seo, astro vs next js for seo, astro blog seo
• KI-Vorgruppierung: cluster_id=1, keywords=[astro seo, astro vs next js for seo, astro blog seo]
• Menschliche Prüfung: astro seo hat Tutorial-Intention, astro vs next js for seo Vergleichsintention; daher trennen.
• Endgültige Cluster-Map:
  • cluster_id=1: [astro seo, astro blog seo] → Astro-SEO-Anleitung erstellen
  • cluster_id=2: [astro vs next js for seo] → Astro-vs.-Next.js-SEO-Vergleich erstellen

Beispiel 2: cloudflare pricing (alten Beitrag aktualisieren)

• Ursprüngliche Queries: cloudflare pricing, cloudflare cost, cloudflare Preise
• Normalisiert: cloudflare pricing, cloudflare pricing, cloudflare pricing
• KI-Vorgruppierung: cluster_id=3, keywords=[cloudflare pricing, cloudflare pricing, cloudflare pricing]
• Treffer im Bestand: vorhandener Artikel /cloudflare-pricing
• Endgültige Cluster-Map:
  • cluster_id=3: [cloudflare pricing, cloudflare cost, cloudflare Preise] → /cloudflare-pricing aktualisieren

Beispiel 3: docker host.docker.internal (verwandte technische Queries normalisieren)

• Ursprüngliche Queries: docker host.docker.internal, docker host-gateway, docker 127.0.0.1
• Normalisiert: als Kandidatengruppe derselben Konfigurationsintention markieren.
• KI-Vorgruppierung: cluster_id=4, keywords=[docker host.docker.internal, docker host-gateway, docker 127.0.0.1]
• Treffer im Bestand: vorhandene Docker-Serie
• Endgültige Cluster-Map:
  • cluster_id=4: [docker host.docker.internal, docker host-gateway, docker 127.0.0.1] → nach menschlicher Intent-Prüfung als FAQ oder Abschnitt in einen Beitrag der Docker-Serie aufnehmen

9. Die Content-Map an den nächsten Ablauf übergeben

Nach dem Clustering wird die Cluster-Map in die Content-Aufgabentabelle übertragen. Dort folgen Felder, Bewertung, Statusmaschine und Veröffentlichungsplan. Der nächste Serienbeitrag „Content-Aufgabentabelle entwerfen: Felder, Bewertungen, Status und Veröffentlichungsplan“ behandelt diesen Schritt.

Wie aus einer Cluster-Map eine schreibbare Gliederung entsteht, erklärt „KI-Gliederung: Von der Cluster-Map zum umsetzbaren Artikelaufbau“. Die spätere Anleitung „Automatische interne Verlinkung: Links stapelweise erzeugen und Fehler vermeiden“ behandelt die Linkeinfügung im Detail.

Für Aktualisierungen alter Beiträge gibt es außerdem „GSC-Strategie für Content-Updates: Von Quick Wins zur Überarbeitung“.

Bereits veröffentlichte verwandte Artikel:

• Quartalsplanung für technische Blogs mit dem Pillar-Cluster-Modell
• Wöchentlicher GA/GSC-Ablauf: Von Daten zu Maßnahmen
• Fortgeschrittene GSC-Techniken für Content-Chancen