SEO Topic Clusters: How to Build, Interlink, and Maintain Them Without Cannibalisation
A maintenance-first operating procedure for SEO leads whose clusters were built 12-18 months ago and are now competing with themselves - covering prerequisites, six build steps, and the failure modes that quietly erode a cluster.
Most SEO topic clusters do not fail at research. They fail nine to fifteen months after launch, when the pillar has absorbed the queries its spokes were built to own, three spokes rank for the same terms, and nobody remembers why half the URLs exist. This is a maintenance-first procedure for SEO leads and content managers whose clusters are already live and competing with themselves. The running example is a South African solar installer building around home backup power.
Why Most SEO Topic Clusters Rot From the Inside
A cluster is a set of URLs with deliberate internal linking and distinct jobs. Rot sets in when links are maintained but roles are not: two spokes ranking on page two for the same query, a pillar ranking for a long-tail definition it should have handed to a spoke, and spokes linked only from a footer widget. Google's guidance on duplicate and near-duplicate content explains why overlapping spokes compete rather than reinforce.
A cluster is healthy when every URL can answer one question: which search does this page own and no other page on the site owns?
Prerequisites: What Has to Be in Place
- One canonical pillar per cluster, with breadth duty and link-down responsibility.
- A cluster registry mapping URL to role, target cluster, and internal-link target.
- Crawl access via Screaming Frog or Sitebulb so interlinking is verified, not assumed.
- An editorial rule: no new URL publishes without a cluster assignment.
- A cluster ID convention so reporting groups cleanly - for example
backup-01.
Step 1: Write the Pillar's Scope as One Sentence
The pillar's job is breadth, not depth. Write one sentence defining what it covers and what it hands to the spokes: "The pillar covers what home backup power is, the three backup types, and how to choose - but not detailed cost breakdowns, inverter comparisons, or compliance paperwork, which live on their own pages."
If the pillar ranks for long-tail queries its spokes were built to own, it is eating them. Re-scope, don't re-write from scratch.
Step 2: Map the Cluster as Entities, Not a Synonym Set
Build spokes around distinct entities and use-cases: product (5kVA inverter), audience (household size), comparison (inverter vs generator), procedural (CoC paperwork), and edge case (rental property). A synonym set - "backup power", "backup electricity", "power backup" - is one concept with three spellings, not a cluster.
The Cluster Registry: A Table You Actually Maintain
| URL | Role | Target query cluster | Internal-link target | Job type |
|---|---|---|---|---|
| /home-backup-power | Pillar | home backup power | all spokes | Breadth |
| /battery-cost-per-kwh | Spoke | battery cost ZAR | pillar; battery-sizing | Definitional |
| /inverter-vs-generator | Spoke | inverter vs generator | pillar; 5kVA comparison | Comparison |
Step 3: Give Every Spoke One Job
Five job types cover most clusters: definitional ("what is a CoC certificate"), comparison, procedural, commercial (indicative ZAR ranges and buying guidance), and edge-case (a rental property where the tenant pays the electricity bill). Decide the job before the brief. If two spokes share a job type and a query cluster, you have a merge candidate, not a cluster.
