Executive summary
A topic cluster organises a pillar page and its supporting articles into a linked structure that concentrates relevance. Done well, it lifts the whole group and signals depth to both search engines and AI answer engines that reward comprehensive coverage.
What this helps you decide
Which subtopics to publish, how to interlink them, and when the cluster is complete enough to compete.
Business problem
Isolated articles compete with each other and never accumulate authority. Sites publish widely but shallowly, so no single topic reads as an area of genuine expertise.
Step-by-step process
-
1
Define the core topic
Choose a theme broad enough to support many pages but narrow enough that you can genuinely own it. Write it as the promise the pillar will keep.
-
2
Map the subtopics
Use query gap analysis to list every meaningful sub-question. Group them with the Topic Cluster Framework into pillar-level and supporting-level intents.
-
3
Assign pages to intents
One page per distinct intent. Merge overlapping ideas now to avoid cannibalisation later, and mark which pages exist versus need writing.
-
4
Build the pillar
Create or upgrade a comprehensive pillar page that introduces the whole topic and links out to every cluster page with descriptive anchors.
-
5
Wire the internal links
Link every supporting page up to the pillar and across to closely related siblings. Ensure no cluster page is orphaned.
-
6
Fill and measure coverage
Publish missing pages in priority order and track coverage as a percentage of mapped intents. Aim for depth before breadth.
Worked example
Checklist
- Core topic defined as a single ownable promise
- Subtopics mapped from real demand, not assumption
- One page per intent, overlaps merged
- Pillar links to every supporting page and vice versa
- No cluster page orphaned
- Coverage tracked as a percentage of mapped intents
Common mistakes
- Publishing supporting pages before the pillar exists to anchor them
- Creating two pages for the same intent and splitting authority
- Chasing breadth across many shallow subtopics instead of finishing one cluster well
30-minute experiment
KPIs to track
- Cluster coverage as percentage of mapped intents
- Combined organic traffic across the cluster
- Number of cluster pages ranking on page one
FAQs
How many supporting pages does a cluster need?
Enough to cover the meaningful sub-questions, not a fixed number. Some topics need six pages, others thirty. Coverage of intent matters more than count.
Can a page belong to two clusters?
It can, but give it one clear home cluster for its primary intent and link to it from the second. Ambiguous ownership weakens both clusters.
Recommended next steps
Where this fits - and what's next
The SearchScore path from a problem you feel to visibility you can measure.