Topic clusters: own a subject, not a keyword

A store selling trail shoes publishes one genuinely excellent guide to choosing them, and it sits on page two for a year. Above it are sites that each have twenty pages about trail running: the guide, the shoe comparisons, the sizing questions, the care instructions, the beginner routes. Their guide isn't better. Their site knows more.

Google and AI assistants judge authority at the level of a subject, and a cluster of linked pages tells them you cover it in a way a single page cannot. Here's how to build one deliberately.

Google ranks subjects, and it reads your links to find them

Google works out what a page is about, what the site around it is about, and how the two relate. Its own description of how Search works talks about understanding the meaning of queries and pages rather than matching strings.

Internal links are the main way it reads that relationship on your site. A guide that links to six pages on the same subject, and gets links back from each, reads as the centre of something. When Google weighs whether a site is credible on a subject, the sites with a connected body of pages on it have the evidence; the sites with one page are asking to be trusted on a sample of one.

AI assistants add a second reason. When an assistant answers a question it retrieves passages from several pages, and it connects a brand name to a subject over repeated encounters. A cluster gives it many passages to find and one consistent name behind them. Brand mentions and entity SEO covers the entity side.

Google's guidance on creating helpful content says the same from the other direction: one of its self-assessment questions asks whether you're producing lots of content on many different topics in the hope that some of it performs. A site that does that looks like a content farm; a site that goes deep on a few subjects looks like it knows them.

The shape of a cluster

A cluster has three parts, and the parts have different jobs.

1. The pillar page answers the broad question, the one with the most searches and the least specific intent: "trail running shoes guide". It covers every sub-topic briefly and links to the page that covers each one properly.
2. The supporting pages each answer one narrower question fully: "trail shoes for wet rock", "how to size trail shoes", "trail shoes vs road shoes". Each targets its own primary keyword, the rule from Mapping keywords to pages applied to a whole subject.
3. The links tie it together in both directions: every supporting page links up to the pillar, the pillar links down to every supporting page, and supporting pages link sideways where a reader would genuinely want the next page.

The pillar isn't the biggest traffic page, and treating it that way is the usual mistake. The specific questions usually add up to more searches than the broad one, because specific questions are what people type. The pillar's job is to be recognised as the centre and to pass the authority the supporting pages earn around the set.

Build one cluster at a time

Start with the subject closest to what you sell, not the one with the biggest numbers. A subject you have real expertise in produces supporting pages that say something; a subject chosen for volume produces twenty rewordings of what already ranks.

1. Write the subject as a plain phrase and pull every keyword around it: related terms, questions, comparisons, the long tail.
2. Group the keywords by the question they share, not by the words they share. "Trail shoes for wet rock" and "grippy trail shoes" are one page; "trail shoes for wet rock" and "trail shoes for wet weather" probably aren't.
3. Each group is a page candidate. Name the broad one as the pillar and the rest as supporting pages, then check which you already have. A page that half-covers a group gets rewritten to cover it fully; two pages that cover the same group get merged.
4. Write the supporting pages first and the pillar once you know what it's summarising; a pillar written first tends to be vague because the detail doesn't exist yet.
5. Add the links as you publish, with anchor text that says what the destination page answers, and go back to older pages in the cluster to link forward to new ones.

Where clusters go wrong

Supporting pages that are thin. Clustering is not permission to publish ten short pages where one good page would do. If two groups can't each sustain a page that says something different, they're one page.

Pillars that are link lists. A pillar with a sentence and a link per sub-topic reads as a navigation page. It should answer the broad question on its own and link out for depth.

Links in one direction. Pillars that link down but supporting pages that never link up leave the pillar cut off from the authority the cluster earns.

Too many clusters at once. Three half-built clusters look like a scattered site. One complete cluster, then the next, compounds, which is the sequence the content engine lesson in the 90-day plan follows.

What to take away

• Google and AI assistants judge whether a site knows a subject, and a connected set of pages is the evidence a single page can't provide.
• A cluster is a pillar page for the broad question, supporting pages for each specific one, and links running in both directions.
• The specific questions usually carry more searches than the broad one; the pillar's job is to be recognised as the centre and to pass authority around the set.
• Build one cluster completely before starting the next, and merge or rewrite existing pages rather than adding thin ones.

Next

Clusters need maintenance as well as building. Continue with Refreshing content that slipped.