A topic cluster is a pillar page covering a broad subject, surrounded by supporting pages covering its subtopics in depth, all interlinked. It is the dominant content architecture for a reason: it matches how search engines evaluate topical expertise and how readers actually explore a subject.
Why it works
Search engines assess whether a site is a credible source on a topic, not just whether a page matches a query. Comprehensive coverage of a subject area, clearly interlinked, is the observable version of expertise.
There is a practical mechanism underneath. Supporting pages each attract links and traffic for their specific long-tail terms, and the internal links concentrate that authority on the pillar, which then has a chance at the competitive head term. A single page attacking the head term directly has no such support.
Choosing the pillar
The pillar targets the broad, competitive term. It should be comprehensive enough to stand alone, structured so each major section corresponds to a supporting article, and written for someone who wants an overview rather than a deep dive.
Length follows from coverage rather than from a target. A pillar that covers eight subtopics adequately is usually substantial; padding it to hit a word count helps nobody.
Format matters more than most people expect. A pillar that is a wall of text performs worse than one with a clear structure, a table of contents, and obvious entry points to each subtopic.
Choosing the supporting pages
Each supporting page should answer one specific question completely, target a distinct long-tail term, and have an obvious reason to exist separately from the pillar.
The test for whether something deserves its own page: could a reader arrive here from search, get a complete answer, and leave satisfied without reading the pillar? If not, it is a section of the pillar rather than a page.
The opposite test is equally useful: if two planned pages would answer essentially the same question, they are one page. This is where cannibalisation starts.
How big should a cluster be?
Five to fifteen supporting pages is the practical range.
Fewer than five and the structure does not signal much depth. More than fifteen and the subtopics start to overlap, the pillar becomes an unreadable index, and the cluster is probably two clusters.
When a cluster grows past fifteen, the usual fix is to promote one subtopic into a pillar of its own, with its own supporting pages, linked from the original pillar. This creates a hierarchy rather than a flat sprawl.
Planning one from scratch
- Pick the topic from business value, not volume. The cluster should cover something your product or service relates to. Traffic on a topic you cannot monetise is a hobby.
- Gather the question space. Keyword tools, search suggestions, the questions in your own support inbox, and what sales get asked. The support inbox is the most underused source.
- Group by intent, not by keyword. Twenty phrasings of the same question are one page. Different questions are different pages, even when they share words.
- Assign each group a page and decide which is the pillar.
- Define the internal links before writing. Which page links to which, with what anchor. Doing this afterwards means it does not get done.
- Write the supporting pages first where you can. They are easier to rank and they give the pillar something to link to on publication.
Retrofitting a cluster onto existing content
Most sites have a pile of posts rather than a structure. Converting is largely an editing exercise.
Inventory everything with its target topic and current performance. Group related pieces. Within each group, identify the best candidate for a pillar — usually the broadest piece, or the one with the most existing links.
Then merge the overlapping pieces, update the survivors, and build the internal links. Merging is the uncomfortable part: consolidating four mediocre posts into one strong page usually outperforms keeping all four, and it requires redirecting the three you remove.
Where clusters fail
Supporting pages that are too thin. A 400-word page that exists to point at the pillar adds nothing and may dilute quality signals.
Overlapping subtopics. Two pages targeting near-identical intent compete with each other and both underperform.
Missing return links. Supporting pages must link back to the pillar, or the authority flows one way and the pillar gains nothing.
No maintenance. A cluster built once and left alone decays as the subject moves. See content refresh strategy.
Choosing a topic too broad to own. A new site attempting a cluster on “marketing” will not win. Narrow until the head term is plausibly reachable.
Measuring a cluster
Measure at the cluster level, not per page. Total organic traffic to all URLs in the cluster, the pillar’s position for its head term, the number of distinct queries the cluster ranks for, and conversions attributable to it.
Expect a sequence rather than a step change: supporting pages rank first for long-tail terms, usually within two to four months, and the pillar’s position on the head term improves later as internal and external authority accumulates. Judging a cluster at six weeks will always look like failure.
A worked cluster plan
An example makes the sizing concrete. Take a cluster on email marketing for a B2B software audience.
The pillar covers email marketing end to end: list building, segmentation, sequences, deliverability, measurement. It targets the broad term and gives each area a section of several hundred words with a link out.
The supporting pages then go deep on one question each: deliverability authentication, segmentation strategies, the welcome sequence, subject line testing, list hygiene, measuring email revenue, re-engagement campaigns, and compliance requirements. Eight pages, each answering a question someone genuinely searches for, each able to stand alone.
Notice what is not in the cluster: “best email marketing software” belongs to a different intent and probably a different cluster, and “what is email marketing” is a definition the pillar already covers. Keeping those out is what prevents the cluster competing with itself.
Clusters and site architecture
The cluster should be visible in the URL structure and the navigation, not only in the links.
A URL path that groups the cluster together makes the relationship explicit and makes reporting straightforward, since you can filter analytics and search console by path. Breadcrumbs reinforce the hierarchy for both readers and crawlers.
Navigation matters too: if the pillar is reachable only from a blog index sorted by date, it will drift out of reach as you publish. Hub pages belong in the main navigation or in a topics index linked from it, so they stay two clicks from the homepage permanently.
Clusters and the commercial funnel
A cluster built purely around search volume will cover the top of the funnel well and leave the bottom empty, because comparison, pricing and implementation queries have lower volume and higher value.
Mapping the cluster against the B2B content funnel is what prevents that. Every cluster should contain at least one piece aimed at someone close to a decision, even where its traffic potential is a fraction of the informational pieces around it.
Frequently asked questions
How long does a topic cluster take to work?
Supporting pages typically show movement in two to four months on a site with some existing authority. The pillar competing for a head term usually takes six to twelve, and may need external links.
Should the pillar be a blog post or a landing page?
Either. What matters is that it covers the topic comprehensively and links to the cluster. Landing-page pillars convert better; article pillars attract links more easily.
Can one page belong to two clusters?
Yes, where the subtopic genuinely sits at the intersection. Do this sparingly, since a page belonging to everything belongs to nothing.
Do I need to publish the whole cluster at once?
No, and publishing over several weeks is usually more practical. Publish the pillar early enough that supporting pages have something to link to, and update it as each new piece goes live.
