Content clusters
A content cluster is a group of pages on one topic, wired together with internal links around a central pillar. It's the structural expression of expertise: instead of one page trying to rank for everything, a pillar covers the topic broadly and supporting pages go deep on subtopics, all linked so authority and relevance reinforce each other. This is the architecture pattern; the build playbook and the detection methodology each get their own article.
Run the Topical Authority Checker on your site — free, no account.
The pillar model
The model is simple to state and easy to get wrong. One pillar page covers a broad topic at a high level. Around it, supporting pages each cover one subtopic in depth. Supporting pages link up to the pillar; the pillar links down to its key supporting pages; related supporting pages link across where relevant. The result is a hub-and-spoke shape where the pillar is the hub.
[ PILLAR ]
broad topic
/ | | \
(down links to key support)
/ | | \
[sub] -- [sub] [sub] -- [sub]
^ \____/ ^ ^ \____/ ^
| cross | | cross |
\___ all link UP to pillar __/
Pillar = hub (receives + sends). Supporting pages =
spokes (deep on one subtopic, link up + sometimes across).Why the structure works
Two effects compound. First, coverage: a cluster demonstrably answers the full range of questions on a topic, which is the substance of topical authority. Second, authority flow: supporting pages concentrate internal equity on the pillar, the pillar lends authority back down, and the whole group ranks better than its parts would alone.
Crucially, clusters compound over time. Each new supporting page that links in strengthens the pillar, which lends authority back to every page in the cluster. A pile of unconnected articles on the same subject has the raw material for this and captures none of it — the difference is entirely the wiring.
Hub pages and the role of navigation
A hub page is any page whose job is to collect and link out to a set of related pages — a pillar is a topical hub, a category page is a catalog hub. Hubs are where authority is meant to gather and redistribute, so they're the highest-leverage pages to get right.
Navigation is not a cluster. Global menus and footers link sitewide with generic anchors and are heavily discounted. A cluster is held together by contextual, in-body links with descriptive anchors. If the only thing connecting your 'cluster' is the nav, you don't have one — see how clusters are detected for why that gets rejected.
Good vs bad cluster structures
BAD: flat feed OK: star, one-way GOOD: bidirectional
(no pillar) (support->pillar only) + cross-links
p1 p2 p3 p4 [ PILLAR ] [ PILLAR ]
| | | | ^ ^ ^ ^ ^ ^ | |
v v v v | | | | | | v v
"back to blog" p1 p2 p3 p1<->p2<->p3
(pillar is a (pillar links back,
no hub, no topical dead end, traps support cross-links,
links, equity leaks authority it authority circulates
to the feed receives) and concentrates)Choosing what the pillar covers
Most cluster failures are scoping failures, decided before a word is written.
The pillar should cover a subject broad enough that several distinct questions sit under it, and narrow enough that one page can genuinely address the whole of it. Too broad and the pillar is a directory nobody reads; too narrow and the supporting pages are really the same page split up.
- Too broad — a pillar on marketing. Nothing links to it naturally, and it competes with every page on the site.
- About right — a pillar on internal linking. Several real subquestions, one coherent overview.
- Too narrow — a pillar on anchor text for footer links. That is a supporting page inside a larger cluster.
A practical test: can you write a genuinely useful overview of the subject that stands on its own, without simply summarising the supporting pages? If the pillar only makes sense as a table of contents, the subject is too broad. If you cannot think of five separate questions under it, it is too narrow.
Scope the pillar to the query someone would type when they do not yet know what to ask specifically. The supporting pages take the queries people type once they do.
Clusters are not silos
The two get used interchangeably and they are close to opposites in the one respect that matters.
A silo, as it was originally taught, deliberately isolates a section: pages within it link to each other and cross-links to other sections are avoided, on the theory that this concentrates topical relevance. A cluster concentrates linking around a subject without forbidding anything — pages link across subjects wherever the relationship is genuine.
- Silo — enforced isolation. Cross-links treated as leakage to be prevented.
- Cluster — concentrated linking. Cross-links welcome where they are relevant.
The difference matters because strict siloing costs you real relevance signals and creates dead ends at every section boundary. If two subjects genuinely relate, a link between them helps a reader and tells a search engine something true. Silo structures, myth vs reality goes into where the idea came from and what survives of it.
The workable rule: link by relevance, not by section. A cluster is where the density of relevant links happens to be highest, not a wall around a folder.
How big should a cluster be?
There is no correct number, but the failure modes at each end are predictable.
- Two or three supporting pages — usually too thin to read as coverage of a subject. The pillar has little to consolidate and the cluster does not signal depth.
- Five to fifteen — the range most clusters settle in. Enough to cover a subject's real subtopics without the pillar becoming a link dump.
- Thirty or more — the pillar now divides what it passes across thirty links, and the subtopics have usually drifted far enough apart that they are really two subjects. Split it.
Size should follow the subject rather than a target. The honest test is whether each supporting page answers a question someone actually asks separately — if two of them could be one page, they should be, and if the pillar covers a subtopic adequately in a paragraph, that subtopic may not need a page at all.
Publishing supporting pages to hit a cluster size is how keyword cannibalization gets manufactured. Two thin pages splitting one query are worse than one page that answers it.
Building a cluster from content you already have
Most clusters are assembled from an existing library rather than planned from nothing, and the assembly is mostly linking rather than writing.
- Pick the subject and find everything you have already published on it. Site search is usually enough.
- Choose the pillar. Prefer the page with the broadest scope and the most existing authority — you can rewrite a page, but not manufacture its link history.
- Check for overlap before linking anything. Two supporting pages on the same subtopic need merging first, or the cluster starts by competing with itself.
- Link every supporting page up to the pillar, in body copy, with descriptive anchors.
- Link the pillar down to each supporting page. This is the half most sites skip, and it is what turns the pillar from a dead end into a distributor.
- Add cross-links between supporting pages where genuinely relevant — not exhaustively.
- Identify the gaps last. Now you know what the subject needs that you have not written.
Step 7 last is deliberate. Wiring what exists usually produces more improvement than adding pages, and it tells you what to write next based on a real gap rather than a guess.
Telling whether a cluster is working
- The pillar's internal authority rises relative to the rest of the site — it is now receiving from every supporting page.
- Supporting pages hold steady or improve rather than falling. If they drop, the pillar is cannibalizing them and the scoping is wrong.
- The pillar starts ranking for broader head terms while supporting pages hold the specific ones. That division is the cluster doing its job.
- Impressions rise across the group in Search Console, not just on the pillar.
- Every supporting page has at least one inbound link from within the cluster and one from the pillar.
Expect months rather than weeks, and watch the group rather than any single page. A cluster is a bet that a subject as a whole becomes more credible, and that is not a change any one URL reports.
Common mistakes
- No back-links to the pillar — the single most common reason clusters underperform. Supporting pages exist but never link up, so the pillar gets no cluster authority.
- The pillar as a dead end — it receives links but links nowhere, trapping authority instead of circulating it back down to support.
- Cannibalizing pages inside the cluster — two supporting pages targeting the same subtopic compete with each other; one can even outrank the pillar. See keyword cannibalization.
- Generic anchors — linking 'read more' instead of the subtopic wastes the relevance signal the cluster exists to send.
- Mistaking a folder for a cluster — shared URL path with no internal links between the pages is filing, not structure.
For the step-by-step build, see how to build topic clusters; for how strong each pillar's support actually is, see measuring pillar strength.
FAQ
How many supporting pages does a cluster need?
There's no fixed number — enough to genuinely cover the topic's subtopics, all wired to the pillar. Four well-linked, on-topic supporting pages beat twelve that never link back. Coverage breadth and the linking matter more than raw count.
Can clusters link to each other?
Yes. Relevant cross-links between clusters help users and authority flow. The rigid, fully-isolated silo is mostly a myth — keep the dominant structure topical, but don't amputate every useful horizontal link.
Is a URL folder the same as a cluster?
No. A shared folder shows how your CMS filed pages; a cluster requires the pages to actually link to each other around a pillar. Without the internal links, a folder is filing, not a cluster, and won't behave like one.
How many pages should a topic cluster have?
Most workable clusters land between five and fifteen supporting pages. Two or three rarely reads as coverage; past about thirty the pillar dilutes what it passes to each and the subtopics have usually drifted into being two subjects. Let the subject decide rather than a target number.
Should the pillar page link to every supporting page?
Yes — and this is the half most sites miss. A pillar that receives links from its cluster but links nowhere becomes a dead end that accumulates authority and passes none back down. Links in both directions are what make the structure work.
Can a page belong to two clusters?
It can, and it is often legitimate for genuinely cross-cutting subjects. Do it sparingly: a page linked up to two pillars splits the signal it sends about what it is about, and if several pages sit in both clusters, the two subjects are probably one.
Do topic clusters still work?
The underlying mechanics have not changed: concentrating relevant links around a subject routes authority to the page you want ranking for the broad term, and signals coverage of the subject. What has aged is the mechanical version — publishing twenty thin posts to point at a pillar. Clusters work when the pages are individually worth reading.
Should supporting pages link to each other?
Where the relationship is genuine, yes, and it strengthens the cluster. Do not cross-link exhaustively for its own sake — every extra link on a page reduces what the others carry, so a supporting page linking to fifteen siblings passes each of them very little.
What is the difference between a topic cluster and a category?
A category is an organisational label, usually rendered as an archive listing every page tagged with it. A cluster is a linking pattern: supporting pages linking up to a pillar that answers the broad query, and the pillar linking back down. A category archive can serve as the hub, but only if it is a page worth ranking rather than a paginated list.
How long does a topic cluster take to work?
Months rather than weeks, and you should watch the group rather than any single page. A cluster is a bet that a subject as a whole becomes more credible, which is not a change any one URL reports. Impressions across the group usually move before positions do.
Put this into practice
Run the Topical Authority Checker to see this on your own site, or run the full structural audit for the complete picture — both free, no account required.