A topic cluster is a deliberate hierarchy of pages. One page — the pillar — covers a subject broadly. Around it sit supporting pages that each go deep on one question the pillar only mentions. Every supporting page links to the pillar. The pillar links back to every one of them.
That is the whole mechanism. What makes it work is not length and not volume — it is that a search engine, and increasingly an answer engine, can see that one site covers a subject completely rather than incidentally. Coverage is the signal. Structure is how you declare it.
pages of technical, search-optimised content in a single industrial library — the volume it took to move organic traffic 164% over twelve months.Source: Narrative Brand Labs engagement data.
Technical buyers do not search the way marketers write. An engineer evaluating an injection moulder does not query “best manufacturing partner.” They query a tolerance, a resin, a cycle time, a certification. Each of those is a distinct page, and almost none of them exist on the average industrial website.
That gap is the opportunity. The questions are narrow, the competition is thin, and the person asking is already in a buying process. A consumer-facing category has a thousand sites fighting over one head term. An industrial category has forty specific questions nobody has bothered to answer properly.
“The deal that started with a Bing search on a Friday evening was not a marketing accident. It was the fortieth page in a cluster doing exactly what the first thirty-nine were built to do.”
— Placeholder attribution. Confirm before publish.
Order matters more than pace here. Three of the four failed clusters we have inherited failed on sequence, not on writing quality.
Choose the one question your sales team answers on every first call. That question is the pillar. Not a keyword with volume — a question with money behind it.
List every downstream question a technical buyer asks before requesting a quote. Interview sales. Read the inbox. Each question becomes one supporting page.
Validate volume and intent so you are not writing pages nobody queries. Cut anything with neither search demand nor a direct sales use.
Spokes teach you what the pillar should say. Writing the pillar first produces a summary of pages that do not exist yet, and it always needs rewriting.
Every supporting page links up to the pillar. The pillar links down to all of them. Siblings link across only where the question genuinely continues.
Track impressions and query coverage across the whole cluster. Individual pages move in and out of position. Cluster coverage is the line that matters.
These get conflated constantly, and the conflation is expensive. A calendar tells you when. A cluster tells you how the pages relate. You need both, but only one of them creates topical authority.
| Dimension | Topic cluster | Content calendar |
|---|---|---|
| Organising unit | Relationship between pages | Publication date |
| Output when done well | Compounding topical authority | Consistent publishing cadence |
| Failure mode | Overlapping pages cannibalise each other | Unconnected posts that never accumulate |
| Primary metric | Query coverage across the cluster | Posts shipped per month |
| Time to signal | 90–120 days on an established domain | Immediate, but not directional |
Stop reporting page-level rankings to leadership. They fluctuate, they invite the wrong questions, and they hide the trend. Report three cluster-level numbers instead:
The third one is new and most teams are not tracking it yet. It is worth starting now, because the pages that get cited are not always the pages that rank.
A gated pillar cannot be crawled, cited, or linked to. Gate a derivative asset instead — a calculator, a spec template — and link to it from the open pillar.
A keyword with 2,400 monthly searches and no buying intent is worth less than a question with 40 searches that your sales team fields weekly.
Pages that exist in the sitemap but receive zero internal links are, structurally, not part of a cluster at all. They are isolated documents with a URL.
Clusters compound. The eleventh page performs better than the first because the linking scaffold is already load-bearing. Most teams quit right before the curve turns.
Between 8 and 15 supporting pages per pillar. Below 8, the cluster reads as a handful of loose posts and does not signal depth. Above 15, the supporting questions usually start overlapping, which causes keyword cannibalisation between your own pages.
Expect first meaningful movement in 90 to 120 days on a site with existing domain authority, and 6 to 9 months on a site publishing technical content for the first time. Clusters compound: the eleventh page performs better than the first because the internal linking is already in place.
No. A gated pillar cannot be crawled, cannot be cited by an answer engine, and cannot receive links. Gate a derivative asset instead — a spec sheet, calculator or template — and link to it from the ungated pillar.
Yes, and the mechanism is slightly different. Answer engines retrieve self-contained passages rather than whole pages, so a cluster built from discrete, clearly-headed answers gives the model more retrievable units. Clear headings, short paragraphs and named sources matter more than total word count.
A content calendar sequences publication dates. A topic cluster defines the structural relationship between pages — which page is the authority and which pages support it. A calendar without a cluster produces unconnected posts that never accumulate into topical authority.