Building a pillar-and-cluster content hub from scratch

Two sites can publish the same number of articles, of the same quality, on the same topic, and rank completely differently — and the usual reason is structure. One site has a scattered pile of posts, each written in isolation, linking nowhere in particular, with no sense of how they relate. The other has the same posts organised into a deliberate hub: a comprehensive central page on the topic, surrounded by deep posts on each sub-topic, all interlinked so the whole thing reads, to a search engine and a human alike, as thorough coverage of a subject by someone who clearly knows it. The second site is demonstrating topical authority; the first is just publishing. Same effort, very different result, and the difference is the pillar-and-cluster model.

The encouraging part is that this structure is something you design and build, not something you have to be big to earn. A small site that covers one topic thoroughly and organises that coverage into a coherent hub can outrank a large, unfocused site on that topic, because depth and structure beat scattered breadth. This article is a practical guide to building such a hub from scratch: what the model is, why it works, how to choose a pillar and map the cluster around it, why the internal links are the actual structure rather than an afterthought, how to build it so it stays coherent as it grows, and the mistakes that quietly undermine hubs. The underlying concept is the topic cluster, explained in /product-blog/topic-clusters-explained; here we turn it into a build.

The model has two kinds of page playing two distinct roles. The pillar is a single, comprehensive page covering a broad topic at a high level — broad enough to be the natural home for the whole subject, but not so detailed that it tries to say everything. The clusters are the deep posts, each taking one specific sub-topic that the pillar mentions and treating it thoroughly, going far deeper on that one thing than the pillar does. The pillar is the map; the clusters are the detailed exploration of each region the map shows. Together they cover the topic both broadly and deeply, which is precisely the combination that reads as authority.

The third ingredient, and the one that turns two piles of pages into a hub, is the linking: the pillar links out to each cluster post, and every cluster post links back to the pillar, so the whole set is bound into a single navigable structure. A reader on the pillar can dive into any sub-topic; a reader who arrives on a cluster post can climb back up to the overview and across to siblings. That web of links is what makes the collection legible as a unit rather than a coincidence of related titles, and it is the part most people underbuild. The model is simple to state — one pillar, many clusters, all interlinked — and most of the skill is in executing the linking properly.

Search engines are trying to identify which sources genuinely know a topic, and a well-built hub is a strong signal of exactly that. Comprehensive coverage of a subject — a pillar plus deep treatment of its sub-topics — demonstrates that the site has real expertise rather than a one-off post chasing a keyword, and the interlinking shows the engine how the pieces relate, which helps it understand and rank the whole set. A scattered pile of posts on the same topic provides none of this: no evident comprehensiveness, no structure to read, no signal that the site is an authority rather than an occasional commenter. The structure is information the search engine uses, and the pile withholds it.

There is a human payoff that matters just as much and reinforces the ranking one. A reader who lands on any page in a well-built hub finds a clear path to everything else they might want on the topic, which keeps them on the site, deepens their trust, and makes the site their reference for that subject. That engagement and return behaviour is itself a positive signal, and more importantly it is the actual goal — being genuinely useful — that the ranking is supposed to reward. A hub serves the reader and the search engine with the same structure, which is why it is not a trick: it works because organised, comprehensive, well-linked content is simply better content, and better content is what the whole system is built to surface.

The pillar topic is the foundational decision, and getting its scope right is most of the battle. Too broad, and the pillar is impossibly vague and the cluster is endless and unfocused; too narrow, and there are not enough genuine sub-topics to build a cluster around, and you have a single post pretending to be a hub. The right pillar is a topic substantial enough to support a meaningful set of distinct, deep sub-topics, but coherent enough that all those sub-topics clearly belong together under one umbrella. It should be something your site has a real reason to be authoritative about — connected to what you actually do — rather than a topic chosen purely for its search volume.

A useful test is whether you can immediately list a handful of distinct sub-topics, each meaty enough to deserve its own thorough post, all of which a reader interested in the pillar would plausibly also care about. If that list comes easily and the sub-topics are genuinely separate rather than overlapping rephrasings, the pillar is well-scoped. If you struggle to find distinct sub-topics, the pillar is too narrow; if the sub-topics sprawl in every direction with no coherence, it is too broad. Choosing a pillar tied to your actual expertise also means the depth will be real, which matters because a hub built on a topic you do not genuinely know will read as thin no matter how it is structured.

With a pillar chosen, the next step is to map the cluster deliberately rather than writing posts as they occur to you, because the structure should be planned, not emergent. The mapping exercise is to enumerate the sub-topics that surround the pillar — ideally the real questions and needs that someone interested in the pillar topic actually has — and treat each as a candidate cluster post. Thinking in terms of the questions a person searches, rather than abstract sub-headings, keeps the cluster anchored to genuine demand and ensures each post has a clear reason to exist and a clear audience to serve.

Mapping first has compounding benefits over writing ad hoc. It reveals the shape and the gaps of your coverage before you have written a word, so you can see whether the cluster is comprehensive or lopsided; it lets you plan the internal links in advance, since you know what will link to what; and it prevents the overlap problem where two posts end up competing for the same ground. A mapped cluster is a plan you execute against, filling in posts over time while always knowing how each fits the whole. This planning is also what lets you build the hub incrementally without it feeling incoherent — every new post slots into a structure that was designed up front, rather than being bolted onto a pile.

The most common failure in building a hub is treating the internal links as a finishing touch rather than the structure itself. The links are not decoration added at the end; they are the thing that makes a collection of pages a hub at all. Every cluster post must link up to the pillar, the pillar must link down to every cluster post, and related cluster posts should link across to each other where the connection is genuine. Without this web, you do not have a hub — you have separate pages that happen to be about related things, which is exactly the scattered pile the model is supposed to replace, and the search engine reads it that way.

Good internal linking does double duty: it guides readers naturally to the next relevant thing, and it tells search engines how the pages relate and which are most important. The pillar, receiving links from all its clusters, is signalled as the central, authoritative page; the clusters, linked from the pillar and each other, are bound into its orbit. The discipline of linking with descriptive, honest anchor text — links that actually tell the reader where they go — is its own subject, covered in /product-blog/internal-linking-that-moves-the-needle, but the point for hub-building is foundational: plan the links as part of the structure, build them deliberately, and treat a missing or broken internal link as a structural defect, not a cosmetic one.

A common mistake is to make the pillar page try to say everything about the topic, which produces an unwieldy monster and leaves the cluster posts nothing distinct to do. The pillar’s job is to cover the topic comprehensively at a high level — to be the authoritative overview that orients a reader and points them onward — not to exhaust every detail. It should introduce each sub-topic enough to be genuinely useful on its own, then link to the cluster post that goes deep, acting as a hub that distributes the reader to the right detailed resource rather than a single page attempting to contain all the detail itself.

Getting this balance right is what makes the whole structure cohere. If the pillar is too shallow it fails as a standalone overview and the hub has no strong centre; if it is too exhaustive it cannibalises its own clusters, since a reader who finds everything on the pillar never visits the deep posts, and the clusters become redundant. The target is a pillar that is satisfying as an overview and clearly signposts where to go for more, so that it serves the reader who wants the big picture and funnels the reader who wants depth into the appropriate cluster. Think of it as the front page of a well-organised reference: complete enough to be useful, structured enough to send you exactly where to dig.

The clusters are where the depth lives, and each one should go thoroughly into its single sub-topic — deeper than the pillar does, deep enough to be the best resource a reader could find on that specific question. A cluster post that is shallow undermines the whole hub, because the structure promises comprehensive coverage and a thin cluster breaks that promise exactly where a reader went looking for detail. The value of the hub is the combination of broad orientation at the pillar and real depth at each cluster; weak clusters hollow out the second half of that and leave a structure that looks comprehensive but is not.

Each cluster post should also stand on its own as a useful, complete treatment of its sub-topic, because many readers will arrive on a cluster directly from search rather than via the pillar. That means a cluster cannot assume the reader has read the pillar; it has to be self-contained, while still linking up to the pillar and across to relevant siblings for the reader who wants more. The standard to hold each cluster to is simply that it is the best answer to its specific question that a searcher could find — and if every cluster meets that bar and the pillar ties them together, the hub as a whole is unambiguously the authoritative resource on the topic, which is the entire goal.

A hub is only as strong as the integrity of its links, and as it grows, keeping every pillar-to-cluster and cluster-to-cluster link correct by hand becomes error-prone — a renamed post orphans the links pointing at it, a new cluster gets added but never linked from the pillar, and the structure quietly decays. This is where treating content as structured data rather than loose documents pays off enormously, as argued in /product-blog/content-as-code-a-blog-without-a-cms. When the relationships between posts are data the system understands, the hub’s structure can be partly generated and, crucially, validated, so a broken internal link or an orphaned cluster becomes a caught error rather than a silent rot.

The practical upshot is that you should build the hub on a foundation that lets the machine help maintain its integrity. Whether that is a content system that understands the pillar-cluster relationships, a build-time check that confirms every cluster links to its pillar and every internal link resolves, or simply a disciplined data model for related posts, the goal is the same: the structure that makes the hub work is enforced rather than hoped for. A hub whose links are maintained by memory alone will degrade as it grows; a hub whose structure is encoded and checked stays coherent at ten posts and at a hundred. The model’s power comes from its structure, so protecting that structure as the hub scales is not optional housekeeping — it is preserving the thing that makes the hub rank.

A few specific failures recur often enough to name. Thin clusters, already mentioned, break the depth promise and are the most common. Orphan posts — pages that belong to the topic but are not linked into the hub — waste content and confuse the structure, since they neither receive the authority the hub confers nor pass it on. Keyword cannibalisation is the subtler trap: two posts targeting essentially the same query end up competing with each other, splitting the signal and confusing the search engine about which to rank, which is why mapping the cluster to distinct sub-topics matters so much. Each of these is a structural defect that a well-planned, well-linked, well-maintained hub avoids by design.

The other quiet failure is neglect. A hub is not a build-once artifact; it is an asset that needs occasional maintenance to keep compounding, because content ages, sub-topics evolve, and gaps appear as the topic develops. Refreshing the pillar and clusters to stay current, as covered in /product-blog/refreshing-old-content-to-keep-rankings, and adding new clusters as new sub-topics emerge, is what keeps a hub growing in authority rather than slowly going stale. The hubs that dominate a topic are the ones that are tended — kept comprehensive, kept current, kept tightly linked — over years, not the ones built in a burst and abandoned. Avoiding the structural mistakes gets the hub built; tending it is what makes it win.

The reason the pillar-and-cluster model is worth the upfront planning is that a well-built hub is a compounding asset, not a one-time campaign. Each cluster post earns traffic on its own sub-topic; the pillar earns traffic on the broad term and distributes authority to the clusters; the internal links pass that authority around so the whole structure lifts together; and as the hub grows more comprehensive, it becomes harder for any scattered competitor to displace, because they would have to match not one post but the entire organised body of work. The effort you put into structure keeps paying long after the writing is done, which is exactly the kind of leverage a small site needs.

So the build, in summary, is deliberate from the start: choose a well-scoped pillar tied to your real expertise, map the cluster of distinct sub-topics before writing, build the pillar as a comprehensive hub rather than an encyclopedia, make each cluster genuinely deep and self-contained, wire the internal links as the actual structure they are, build on a foundation that keeps those links correct as it grows, and tend the hub against the predictable mistakes over time. Do that and the same writing effort that would have produced a forgettable pile of posts instead produces a structure that demonstrates real authority on a topic and compounds for years. The pile and the hub cost the same to write; only one of them is an asset.