Content clusters and the pillar model, in plain English.

Strip the marketing vocabulary off it and a content cluster is just this: one big page that covers a topic broadly, surrounded by a set of smaller pages that each cover one part of that topic deeply — and all of them linked together so a reader (and a search engine) can see they belong to the same body of work. The big page is the pillar. The smaller pages are the cluster. That’s the whole model. The reason it works is worth understanding, because once you see it you stop building blogs and start building clusters.

Pillar and cluster — what each one is

A pillar is the page you’d send someone to if they said “tell me everything about X.” For an HVAC contractor, the pillar for air-conditioning repair is the comprehensive page — what the service covers, the common problems, how diagnosis works, what it costs, when repair beats replacement, what to expect. It’s broad by design. It doesn’t try to be the definitive answer on every sub-question; it’s the hub that orients the reader and points them deeper.

A cluster page is one of those deeper pages. “AC repair vs. replacement,” “why is my AC blowing warm air,” “emergency AC repair,” “how much does AC repair cost in Tampa” — each of those is a cluster page. It takes one slice of the pillar’s territory and goes all the way down on it: the full answer, the nuance, the edge cases. And then it does two things that make it part of a cluster rather than a stray post: it links up to the pillar, and it links sideways to its siblings where they’re relevant. The pillar links back down to the cluster pages. Now you have a structure, not a pile.

If you want the picture from the top — how you decide which subtopics become pillars and which become cluster pages in the first place — that’s the job of a topical map. The map is the blueprint; the cluster is the thing the blueprint describes once it’s built. (And if you want the one-sentence version of all this for a colleague who’s never heard the term, point them at what is a topic cluster.)

Why the structure ranks

Four reasons, and they compound.

• It consolidates topical relevance onto the pillar. When a dozen well-linked pages all orbit one hub, the hub accumulates the signal that says “this site, and this page in particular, is about this topic — comprehensively.” A search engine evaluating who should rank for the broad term sees a site that has covered the topic from the centre out, not a single page making a claim it can’t back up.
• It distributes link equity where it’s useful. Internal links pass authority. A pillar that links to its cluster pages, and cluster pages that link back and to each other, move that authority around the cluster instead of letting it pool on the homepage. When one cluster page earns an external link, the whole cluster benefits, because the link equity flows along the connections you built.
• It covers the long tail. The broad term (“AC repair”) is contested and ambiguous. The long tail (“AC repair making clicking noise when starting”) is specific, lower-competition, and high-intent — and there’s a lot of it. Cluster pages are how you capture it. Each one ranks for its own narrow query, and collectively they pull in traffic the pillar alone never would. They also feed the pillar: the cluster is part of why the pillar ranks for the broad term at all.
• It makes the site legible. To a reader, a cluster reads as a site that knows its subject — there’s always a more-detailed page one click away, and a way back to the overview. To a search engine, the link structure is a map of how the topic decomposes. Both audiences reward “legible.” A page that’s logically connected to twenty others on the same topic is treated very differently from the same page sitting alone in a blog archive.

How a cluster is different from “a blog”

This is the distinction that costs businesses the most time, because “we have a blog” gets mistaken for “we have topical authority,” and they’re not the same thing.

A blog is dated and disconnected by default. Posts are organised by publication date. They reference whatever was on someone’s mind that month. They’re rarely updated. They link to each other only by accident. Over a few years you end up with a hundred posts, most of them stale, no structure connecting them, and no page that’s the definitive hub for anything. Search engines treat that archive accordingly — it reads as a stream of opinions, not a body of authority.

A cluster is structural and permanent by design. Pages are organised by topic, not date. Each one exists because the topic requires it, and it gets updated when the topic changes — not retired when it scrolls off the front page. The links between them are deliberate and dense. There’s a clear pillar that owns the topic. The whole thing is built to stand for years, not to fill a publishing calendar. (The full version of this comparison is on pillar page vs. blog post — read it if anyone on your team still thinks the monthly post is the strategy.)

You can absolutely run a blog alongside a cluster — news, hiring announcements, the occasional opinion piece — and it has its place. But it’s the supporting cast. The cluster is the work.

A blog is a calendar. A cluster is a structure. Only one of them still works in three years without you touching it.

How big a cluster should be

There’s no number, and anyone who gives you one (“a cluster is a pillar plus ten posts”) is selling a template, not a strategy. The size of a cluster is governed by two things: how much the topic genuinely contains, and how thoroughly the competitive set has covered it.

The topic sets the floor on completeness — there are questions a comprehensive treatment of “AC repair” has to answer, and a cluster that skips half of them isn’t comprehensive no matter how polished. The competitive set sets the practical bar — if the contractors ranking for your terms each have a fifteen-page cluster, a five-page one isn’t competing. Sometimes the topic is genuinely small and a tight cluster is right. More often, on a real service in a real market, “enough” is more pages than the owner expected — which is why the honest answer to “how many pages do I need” is always it depends on the topic and the competition, never a flat figure. Build to clear the floor and beat the floor your competitors set; don’t pad past it. A cluster bloated with thin pages is worse than a tight one — see whether more pages is always better for why.

The practical version on a service-business site

Here’s what this looks like when it’s actually built. Take a plumbing company serving four sub-metros and offering, say, eight services. Each service gets a pillar — a comprehensive service page. Under each pillar sit supporting pages: the comparison questions, the cost questions, the “is this an emergency” questions, the brand and equipment questions, the maintenance questions — whichever ones the topic and the competitors say belong there. Under or alongside those sit FAQ-sized pages for the single-answer queries. And where the service is location-sensitive — most plumbing is — the high-value pages get a per-sub-metro version with genuine local substance (response times, the area’s housing stock, recent jobs), not a find-and-replace clone.

Stack that up: eight services, several supporting pages each, a layer of FAQ pages, multiplied where location matters, all linked into a hub-and-spoke structure. That’s how a plumbing company with a 10-page brochure site honestly becomes a 120-page authority site — without a single page that exists just to pad the count. The internal linking that holds it together is its own discipline; that’s internal link architecture. And the whole thing — map, clusters, links, built in 14 days — is the authority sites service. The topical authority overview walks the full thesis if you want the why before the how.