Semantischer Cocoon: die Methode, angewendet auf 144 Seiten

Was ein semantischer Cocoon ist, ohne Fachjargon

Ein semantischer Cocoon (der Begriff „cocon sémantique“ stammt aus der französischen SEO-Szene, im Deutschen spricht man auch von Themensilos) ist eine Art, eine Website so zu organisieren, dass eine Suchmaschine versteht, worüber Sie sprechen, und dass der Traffic informativer Inhalte zu den Seiten fließt, die verkaufen. Drei Elemente genügen, um ihn zu beschreiben:

• Eine Pillar-Seite: die Seite, die die kommerziellste Suchanfrage des Themas trägt. Meist eine Angebots- oder Leistungsseite.
• Satelliten: die Artikel, die die Fragen beantworten, die sich ein Interessent vor dem Kauf stellt (was es kostet, wie es abläuft, was man vergleichen sollte).
• Links, die Regeln folgen: vom Artikel zur Pillar-Seite (aufwärts), von der Pillar-Seite zu ihren Artikeln (abwärts), zwischen benachbarten Artikeln desselben Themas (seitlich) und fast nie zu einem themenfremden Bereich.

Das Schema ist einfach. Weniger einfach ist es, es auf einer echten Website umzusetzen, die eine jahrelange Geschichte, Dubletten, Seiten, die niemand verlinkt, und ein Menü hat, das jede Hierarchie plattdrückt. Wir haben das dieses Jahr auf zwei Websites gemacht: bei einem Kunden, einer Digitalagentur mit rund zwanzig Mitarbeitenden (mehrere hundert Seiten unter Drupal 7), und bei uns selbst. Hier ist die Methode, so wie sie gelaufen ist.

Schritt 1: die tatsächliche Verlinkung ansehen, bevor man irgendetwas zeichnet

Man baut einen Cocoon nicht auf einem Idealplan, sondern ausgehend von dem, was die Website bereits tut. Wir beginnen mit einem vollständigen Crawl, dann mit einem Graphen, der jede Seite nach ihren tatsächlichen Links platziert, mit einer unverzichtbaren Vorsichtsmaßnahme: Template-Links (Menü, Fußzeile, wiederholte Buttons) von redaktionellen Links trennen, also denen, die im Text stehen. Ohne diese Trennung verfälscht das Menü alles: Auf der Website unseres Kunden erhielt jede Leistungsseite rund 275 identische Links aus dem Mega-Menü, und alle wirkten gleich wichtig.

Sobald das Template herausgerechnet ist, steht die Diagnose schnell fest. Auf dieser Website erfasste der Crawl vom 28. August mehrere hundert Seiten, und der Graph zeigte Muster, die man fast überall findet:

• Inhalt und Angebot, die sich ignorieren: 29 Artikel verlinkten keine einzige Leistungsseite. Der Blog zog Leser an, schickte sie aber nirgendwohin.
• Das ausgehungerte Ziel: Manche Leistungsseiten erhielten einen einzigen redaktionellen Link, während andere, für die Agentur weniger wichtige, Dutzende bekamen.
• Der Stern: 34 Einträge eines Glossars, jeder nur mit seiner Indexseite verbunden, die Hälfte ganz ohne ausgehenden Link.
• Der abgekoppelte Beweis: 16 von 39 Leistungsseiten verlinkten keine einzige Fallstudie.

Diese erste Erhebung ergab ein Backlog von rund 89 zu setzenden Links. Eine Sicherheitsregel begleitete sie, und wir behalten sie bei: Der Graph rechtfertigt das Hinzufügen von Links, er reicht nie aus, um eine Seite zu löschen. Eine Löschung wird mit den Daten der Search Console entschieden, nicht allein anhand der Form des Graphen.

Schritt 2: ein schriftlicher Plan, eine Zeile pro Seite

Diesen Schritt überspringen die meisten Projekte, und genau er macht den Unterschied. Für jede Seite legt der Plan schriftlich fest:

• ihren Cocoon und ihre Pillar-Seite;
• ihre Ziel-Suchanfrage und ihre Absicht (lernen, vergleichen oder kaufen), dazu einige sekundäre Suchanfragen;
• die Leistung, die sie fördert, und drei oder vier Formulierungen für den Ankertext zu dieser Leistung, damit nicht derselbe Satz auf dreißig Seiten steht;
• ihre seitlichen Links zu Schwesterseiten;
• bei einer Pillar-Seite ihre abwärts gerichteten Links und ihre Belege (Referenzen);
• die geplante Maßnahme: überarbeiten, leichte Überarbeitung, Zusammenlegung vorgeschlagen, Entfernung vorgeschlagen.

Der Plan ist eine Datendatei, keine Präsentation. So lässt er sich per Skript prüfen, und die nützlichste Prüfung ist die einfachste: Keine Ziel-Suchanfrage wird von zwei Seiten anvisiert. Zwei Seiten auf derselben Suchanfrage machen sich Konkurrenz, und die Suchmaschine behält nur eine. Auf der Website unseres Kunden brachte diese Lektüre Kannibalisierungen auf mehreren Ebenen ans Licht, darunter zwei Leistungsseiten zum selben Produkt, die nebeneinander existierten.

Der endgültige Plan ordnet 144 Seiten (113 Artikel und 31 Leistungsseiten) in acht Cocoons, dazu vier Artikel außerhalb jedes Cocoons. Eine strukturelle Entscheidung beschäftigte uns mehr als alle anderen: Ein Thema, das für die Agentur wichtig ist, hatte keine Leistungsseite. Statt seine acht Artikel ohne Pillar-Seite zu lassen, lässt der Plan sie vorübergehend auf die nächstliegende Leistung zeigen und schlägt vor, die fehlende Seite anzulegen. Ein Cocoon ohne Ziel ist ein Cocoon, der nichts verkauft.

Schritt 3: benannte Prinzipien, damit sich jede Änderung begründen lässt

Wir haben zweiundzwanzig nummerierte Prinzipien geschrieben, und jede Änderung an der Website zitiert mindestens eines davon. Diejenigen, die den Cocoon selbst tragen:

• Eine Seite, eine Suchanfrage, eine Absicht.
• Der aufwärts gerichtete Link zu dem, was verkauft wird: Jeder Artikel verlinkt die Leistung, der er dient, in der Einleitung, wenn der Satz es erlaubt, und im Fazit als nächsten Schritt. Der Ankertext nennt die Leistung und trägt ihre Suchanfrage.
• Der abwärts gerichtete Link: Die Leistungsseite verteilt auf die Artikel, die die Fragen des Interessenten beantworten.
• Der seitliche Link zwischen nahen Geschwistern: einer oder zwei, nie ein Abfluss zu einem anderen Thema.
• Jeder Link sagt die Wahrheit: Der Ankertext beschreibt die Zielseite. Kein „hier klicken“, kein alter Link, der „Webdesign“ auf eine E-Commerce-Seite schickt.
• Die semantische Gleitbewegung: Ein Artikel übernimmt das Vokabular der Seite, die er stützt, und führt natürlich zu ihr.
• Entkannibalisieren: zwei ähnliche Seiten über die Absicht unterscheiden oder ihre Zusammenlegung mit dauerhafter Weiterleitung vorschlagen.

Die Prinzipien zu benennen hat eine unerwartete Wirkung: Die Durchsicht wird möglich. Der Kunde liest nicht mehr „einen geänderten Text“, er liest eine Änderung, ihr Prinzip und ihren Grund. Das macht eine Überarbeitung dieser Größe Zeile für Zeile diskutierbar, und wir kommen im Artikel über die Methode zum Auffrischen alter Artikel darauf zurück.

Schritt 4: auf der ganzen Website kontrollieren, nie nach Augenmaß

Eine Verlinkung verschlechtert sich geräuschlos: ein Link auf eine geänderte Adresse, ein dreißigmal kopierter Ankertext, ein Artikel ohne Link zu seiner Pillar-Seite. Daher eine Regel: Jeder Durchgang endet mit Kontrollen, die über alle Seiten laufen, nicht über eine Stichprobe.

Bei der Überarbeitung für unseren Kunden ergab das automatische Audit der Checkliste (sechzehn Punkte pro Seite, auf 144 Seiten) vor der Arbeit 938 nicht erfüllte Punkte von 2 304, und keine einzige Seite ohne Mangel. Danach: null. Das aussagekräftigste Ergebnis betrifft den Cocoon selbst: Die Artikel, die keine Leistung verlinkten, sanken von 33 auf 2, und diese beiden sind zur Entfernung vorgeschlagen. Die sieben Leistungsunterseiten, die kein Artikel verlinkte, erhalten nun jeweils drei oder vier Links.

Diese Zahlen messen den Aufwand und die Konformität der Verlinkung, nicht ihre Wirkung. Die neue Version der Website ist noch nicht online: Die Vorher-nachher-Messungen in der Search Console werden nach dem Livegang veröffentlicht, nicht vorher.

Was wir auf unserem eigenen Blog gemacht haben

Die Methode gilt auch für uns selbst, und wir mussten sie unterwegs korrigieren.

Im September fand unser Strukturaudit auch bei uns das häufigste Muster: Unsere Angebotsseiten verlinkten weder ihre Pillar-Seite noch ihre Artikel. Die Pillar-Seiten erhielten Navigationslinks, aber keinen von einem Angebot. Der Linkjuice floss vom Blog zu den Angeboten, nichts floss zurück. Wir haben jedem Angebot einen aus den Daten generierten Block „Weiterführend“ hinzugefügt, der seine Pillar-Seite und seine neuesten Artikel verlinkt: Der Anteil der Pillar-Seiten mit einem Link von einem Angebot stieg von null auf alle.

Dasselbe Audit sagte noch etwas Unbequemeres: Sechs von neun Cocoons hatten keinen einzigen Artikel. Eine Pillar-Seite und ein Call-to-Action sind kein Cocoon, sondern eine leere Seite mit Ambitionen. Wir hatten zu viele Cocoons für die Inhalte gezeichnet, die wir hatten. Am 2. Oktober gingen wir von zehn auf acht Cocoons zurück, indem wir die sich überschneidenden zusammenlegten, und fügten der Website eine Regel hinzu: Ein Cocoon ohne Artikel wird nicht mehr aufgelistet, seine Seite erhält noindex und verlässt die Sitemap. Sie bleibt für alte Links erreichbar und taucht beim ersten veröffentlichten Artikel von selbst wieder auf.

Die Lehre ist einfach: Ein Cocoon wird nach den Inhalten dimensioniert, die man produzieren und gegenlesen kann, nicht nach der Karte der Themen, die man gern abdecken würde.

Die Grenzen, die Sie vor dem Start kennen sollten

• Der Graph hat eine Fehlermarge. Ein im Text geschriebener Link mit genau dem Ankertext des Menüs gilt als Template-Link, und ein Button mit einzigartigem Text kann als redaktionell durchgehen. Die Größenordnungen stimmen, die Grenzfälle prüft man auf der Seite.
• Zusammenlegungen werden nicht ohne Entscheidung umgesetzt. Bei unserem Kunden sind sieben Zusammenlegungen und zehn Entfernungen vorgeschlagen, keine ist umgesetzt: Die Entscheidung liegt beim Eigentümer der Website, mit den Daten in der Hand, und jede Zusammenlegung erfordert ihre dauerhafte Weiterleitung.
• Der Cocoon ersetzt keinen Inhalt. Eine Pillar-Seite mit 24 Wörtern, und wir haben eine gefunden, rettet man nicht durch eingehende Links. Man muss sie schreiben.

Wenn Sie wissen möchten, wo Ihre eigene Verlinkung steht, ist genau das Gegenstand eines SEO-Audits mit priorisiertem Maßnahmenplan. Und wenn die Methode dauerhaft laufen soll, mit vor der Veröffentlichung gegengelesenen Entwürfen, ist das die Aufgabe unserer SEO- und GEO-Engine. Die anderen Artikel des Cocoons sind auf der Seite SEO und Sichtbarkeit in KI-Systemen versammelt.

Häufige Fragen