Pillar-Pages: Hub-and-Spoke-SEO im echten Kanzlei-Repo

Würdigung — guter Inhalt ohne Struktur verpufft#

Eine Kanzlei, die regelmäßig Fachinhalte veröffentlicht, leistet echte Arbeit — und verschenkt sie oft an der Struktur. Zwanzig gute Einzelartikel, die nirgends zusammengeführt werden, lesen sich für Google wie zwanzig zufällige Stimmen, nicht wie eine zusammenhängende Kompetenz zu einem Thema. Und für den Besucher sind sie ein Stapel, kein Weg: Er findet vielleicht einen Artikel, aber nicht den Faden, der ihn vom „worum geht es überhaupt?" zur konkreten Vertiefung und am Ende ins Gespräch führt.

Die Hub-and-Spoke-Architektur ist die Antwort darauf, und sie ist keine Marketing-Spielerei. Sie ist eine Bauentscheidung wie die Wahl des Renderings oder der Typsicherheit: Sie bestimmt, ob aus Einzelteilen ein System wird. Der Hub übernimmt die Erzählung, die Spokes die Tiefe — und beide sind über Code so verbunden, dass die Beziehung nicht im Kopf eines Redakteurs lebt, sondern im Repository nachweisbar ist.

Hub und Spokes: was eine Pillar-Page wirklich ist#

Eine Pillar-Page ist keine Übersicht mit Kacheln. Sie ist eine eigenständig argumentierende Long-Form-Seite, die ein Cluster-Thema als zusammenhängende These erzählt — in vier bis fünf Sektionen, von denen jede ein eigenes Teilargument trägt (etwa: die Bauweise, die Werkzeuge, die Schranken, die Kontrolle). Jede dieser Sektionen verlinkt auf ein bis vier Detail-Artikel, die genau dieses Teilargument vertiefen. Das ist die Hub-and-Spoke-Beziehung: Der Hub erzählt das große Bild, die Spokes liefern die Tiefe.

Für Suchmaschinen ist diese Struktur lesbar. Google erkennt an der Dichte interner Verlinkung und an den Anker-Bezügen, dass ein Themenfeld zusammengehört, und bewertet Hub und Spokes als zusammenhängende Autorität — nicht als verstreute Einzelseiten. Für den Besucher entsteht derselbe Effekt menschlich: Er kann oben einsteigen und sich nach unten in genau die Frage durchklicken, die ihn betrifft.

TypeScript als Vertrag: was Hub und Spoke zusammenhält#

Im Repo ist diese Architektur kein Layout-Zufall, sondern ein typisierter Vertrag. Zwei TypeScript-Typen halten alles zusammen. Eine PillarSection bündelt, was eine Hub-Sektion ausmacht: die Überschrift, ein Kurz-Label für die Navigation, eine stabile Anker-ID für Sprünge, den eigentlichen Argumentations-Text und — entscheidend — die relatedSlugs, also die Liste der Detail-Artikel, die diese Sektion vertieft. Ohne relatedSlugs ist eine Sektion kein echter Hub-Knoten; sie hätte keine Spokes.

Darüber liegt der Typ ClusterPillar, der die ganze Seite beschreibt: die zentrale These, den Lead-Absatz, ein paar Quick-Wins, die Sektionen, einen Eigenpraxis-Absatz und den abschließenden Lead-Magnet. Weil das strikt typisiert ist, blockt der Build jede unvollständige Sektion: Fehlt ein Pflichtfeld, kompiliert es nicht. Die Verbindung zwischen Übersicht und Tiefe ist damit nichts, das man pflegen muss und vergessen kann — sie ist strukturell erzwungen. Warum strikte Typen generell weniger Fehler bedeuten, vertieft der TypeScript-Insight; wie die Datei-Architektur insgesamt aufgebaut ist, zeigt die Tour durch das Repo.

Lesbarkeit: Sticky-Inhaltsleiste und Cluster-Farben#

Eine Long-Form-Seite ohne Navigation ist auf dem Mobilgerät unlesbar. Deshalb trägt jede Pillar-Page eine mitlaufende (sticky) Inhaltsleiste: eine schlanke Navigation, die die Sektionen als Anker-Sprünge anbietet und die gerade sichtbare Sektion hervorhebt. Auf dem Smartphone scrollt sie horizontal mit, die Sprungziele sind als ausreichend große Tippflächen ausgelegt.

Dazu kommt eine ruhige Form der Orientierung: Jedes Cluster hat eine eigene Akzentfarbe. Diese Farben sind nicht nach Geschmack vergeben, sondern so gewählt, dass sie auf weißem Hintergrund ein Kontrastverhältnis von mindestens 4,5:1 erreichen — die Schwelle für lesbaren Text nach WCAGWCAG · zum GlossarWeb Content Accessibility Guidelines des W3C — internationaler Barrierefreiheits-Standard. 2.1 AA. Aktive Zustände werden zusätzlich über Schriftstärke und sichtbare Ränder markiert, nicht allein über Farbe, damit auch Menschen mit Farbsehschwäche der Orientierung folgen können. Barrierefreiheit ist hier kein nachträglicher Anstrich, sondern Teil der Bauweise.

Der Linter, der die Drift verhindert#

Die größte Gefahr einer Hub-and-Spoke-Struktur ist die schleichende Drift: Ein neuer Artikel wird geschrieben, aber keiner Pillar-Sektion zugeordnet. Ein Detail-Artikel wird umbenannt, aber der Hub zeigt weiter auf den alten Namen. Ein Lead-Magnet verspricht „sieben Fragen", das tatsächliche Quiz hat aber sechs. Jeder dieser Fehler ist still — er wirft keinen Build-Fehler, er fällt nur irgendwann einem Besucher auf.

Genau deshalb läuft ein Pre-Commit-Linter, der diese Brücken prüft: Jeder Artikel muss einem Cluster zugeordnet sein, jede Pillar-Sektion muss auf existierende Detail-Artikel verweisen, und jedes Zahl-Versprechen einer Lead-Magnet-Überschrift muss zur echten Frage-Anzahl passen. Stimmt etwas nicht, scheitert der Commit. Die Konsistenz zwischen Hub und Spokes wird damit nicht gepflegt, sondern erzwungen — dieselbe Mechanik-vor-Aufmerksamkeit-Logik, die auch hinter unseren übrigen Pre-Commit-Hooks steht.

Was Kanzleien davon haben#

Aus der Architektur ergibt sich ein konkreter Nutzen:

• Sichtbarkeit aus Bestand: Vorhandene Fachinhalte werden als zusammenhängende Kompetenz lesbar — für Google und für Besucher —, statt einzeln zu verpuffen.
• Ein Weg statt eines Stapels: Der Besucher findet vom großen Bild zur konkreten Frage und von dort ins Gespräch — ein sauberer Pfad statt einer Sackgasse aus Einzelseiten.
• Konsistenz ohne Pflege-Disziplin: Die Verbindung zwischen Übersicht und Tiefe ist im Code erzwungen, nicht der Aufmerksamkeit überlassen — sie bricht nicht still.
• Barrierefrei und mobil von Anfang an: Navigation und Farbgebung sind nach WCAG 2.1 AA gebaut, nicht nachgerüstet.

Für eine strukturierte Bewertung, ob Ihre Inhalte als Themen-Cluster tragen oder als lose Liste liegen bleiben, empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Eine Pillar-Page ist keine Kachel-Übersicht, sondern eine eigenständig argumentierende Seite, die ein Thema als These erzählt und in vertiefende Detail-Artikel verzweigt — Hub und Spokes. Im fahoch2.de-Repo ist diese Beziehung typisiert: PillarSection und ClusterPillar halten Titel, Anker, Text und relatedSlugs als verbindlichen Vertrag zusammen, den der Build erzwingt. Eine mitlaufende Inhaltsleiste und WCAG-2.1-AA-konforme Cluster-Farben halten die Long-Form-Seite lesbar, gerade mobil. Und ein Pre-Commit-Linter verhindert die stille Drift zwischen Hub und Spokes. So wird aus einzelnen Fachbeiträgen ein System, das Besucher führt und von Suchmaschinen als zusammenhängende Autorität gelesen wird.

Quellen#

• Google Search Central — Best Practices für interne Verlinkung — abgerufen 2026-06-08
• Schema.org — Article (hasPart / isPartOf) — abgerufen 2026-06-08
• W3C — WCAG 2.1, Erfolgskriterium 1.4.3 Kontrast (Minimum) — abgerufen 2026-06-08

Disclaimer: Beschreibung der tatsächlichen Pillar-Architektur von fahoch2.de zum Zeitpunkt der Veröffentlichung. Allgemeine fachliche Information, keine Rechtsberatung. SEO-Wirkungen hängen von vielen Faktoren ab und lassen sich nicht garantieren; die hier beschriebene Struktur ist eine Bauweise, kein Ranking-Versprechen.