Foundational3 min read

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.

hub

Run the Topical Authority Checker on your site — free, no account.

Check your cluster structure free

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.

Cluster anatomy

                 [ 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).

The shape matters more than the count. A pillar with twelve supporting pages that never link back is twelve orphans; four that link up properly is a working cluster.

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.

warning

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

Three structures, ranked

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)

Most sites are the left structure and call it the right one. The jump from 'OK' to 'GOOD' is the pillar linking back down and supporting pages linking across — the bidirectional wiring that lets authority circulate instead of pooling.

Common mistakes

chevron_rightNo 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.
chevron_rightThe pillar as a dead end — it receives links but links nowhere, trapping authority instead of circulating it back down to support.
chevron_rightCannibalizing pages inside the cluster — two supporting pages targeting the same subtopic compete with each other; one can even outrank the pillar. See keyword cannibalization.
chevron_rightGeneric anchors — linking 'read more' instead of the subtopic wastes the relevance signal the cluster exists to send.
chevron_rightMistaking 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?expand_more

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?expand_more

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?expand_more

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.