how to build topic clusters

A topic cluster is a group of pages covering one subject properly: a hub page owning the broad query, and supporting pages owning the specific questions within it, all linked deliberately to each other.

The reason to build them is not that clusters are fashionable. It is that a single page cannot rank for a broad commercial term and also answer twenty specific questions well, and twenty unconnected pages do not establish that you cover the subject.

What a cluster consists of

  • A hub page owning the broad query, explaining the subject and linking down to everything beneath it.
  • Supporting pages each owning one specific question or subtopic.
  • Links down from hub to supporting pages, in the body rather than only in navigation.
  • Links up from each supporting page to the hub, which is what establishes the relationship.
  • Selective links across between genuinely related supporting pages.

The upward links matter more than people expect. Without them, the hub is just a page that links out and nothing marks it as the centre of the topic.

Building one

1. Define the boundary

Decide what the cluster covers and, more usefully, what it does not. Clusters that expand indefinitely end up overlapping neighbouring clusters, which reintroduces the competition you were avoiding.

2. Assign queries before writing

Each page owns one primary query. Two pages targeting the same query inside a cluster is cannibalisation within your own structure, which is worse than having no cluster. This is keyword mapping and it happens first.

3. Build the hub properly

The hub should be genuinely useful on its own, not a table of contents. A hub that is only links has nothing to rank with and gives visitors no reason to stay.

4. Write the supporting pages to their own question

Each answers one thing thoroughly. Resist the instinct to have each page introduce the whole subject, which is how supporting pages end up competing with the hub.

5. Link deliberately

Contextual links in body copy, with descriptive anchors. Automated related-content modules are weaker because they carry no context. See internal linking services.

Where clusters fail

  • The hub is thin. A links page cannot own a competitive term.
  • Supporting pages duplicate each other, usually because queries were not assigned first.
  • No upward links, so nothing establishes the hub as the centre.
  • The cluster is built half-way and abandoned. A partial cluster rarely establishes authority on the subject.
  • Pages exist for queries nobody searches, added to make the cluster look complete.
  • Two clusters overlap at their edges and compete.

How many pages

As many as there are genuine distinct questions, which is usually fewer than a content plan suggests. Five well-differentiated supporting pages beat fifteen where ten are thin variations. Completeness matters more than count: a cluster that covers its subject properly is stronger than a larger one with gaps and repetition.

Frequently asked questions

Do topic clusters actually work?

The underlying mechanics do: covering a subject thoroughly, assigning queries so pages do not compete, and linking so relationships are visible. Those are sound regardless of what the approach is called.

Should the hub target the highest-volume term?

Usually the broadest commercially relevant one, which is often but not always the highest volume. The hub should own the term someone uses before they know their specific question.

How do I avoid supporting pages competing?

Assign one primary query per page before writing, and record what each page must not cover. Doing this afterwards is far harder than doing it first.

Can a page belong to two clusters?

It can be linked from both, but it should have one home and one owner. Pages belonging equally to two clusters usually indicate the boundaries were drawn badly.

Consulting CTA

If your content covers a subject without ranking for it, book an SEO consultation to review coverage, ownership and linking.