The pillar-and-cluster model for SaaS content

The pillar-and-cluster model is one of those frameworks that everyone has heard of and almost nobody implements well. Marketing teams know they should build topical authority. They publish a long pillar page, draft a few supporting articles, link them together and call it a cluster. Six months later the rankings have not moved, the team has lost interest and the pillar is stranded as a one-off.

We have built pillar-and-cluster programmes for SaaS clients across analytics, security, ERP and infrastructure software. The model works, but only when the architecture and editorial discipline are right. Here is how we build it.

What the model is actually for

A pillar-and-cluster structure does three things. It tells search engines that you cover a topic deeply rather than touching it once. It gives buyers a clear path through the material so they read more than one page in a session. And it gives the editorial team a frame for planning, so each new brief sits inside a wider thesis rather than chasing a stray keyword.

Done well, a single pillar can carry 18 to 30 supporting articles, capture 50 or more long-tail queries and become the spine of a sales enablement library. Done badly, it is a hub page with five broken internal links.

Choosing the right pillar

The pillar topic is the most important decision in the whole model. Get it wrong and no amount of cluster work will save it. We use three tests when we help a SaaS client choose theirs.

First, can the company credibly own the topic. A SaaS analytics vendor can credibly own “attribution for long sales cycles” because that is a problem their product solves daily. They cannot credibly own “the future of B2B marketing” because it is too broad.

Second, is there real search volume across the cluster. The pillar query itself might only see 200 searches a month, but the supporting questions should add up to several thousand. We pull this data from Semrush and Ahrefs, then sense-check against Search Console for any existing site signals.

Third, does the topic intersect with where deals get won. A pillar that nobody on the sales team will reference is a pillar that will not get refreshed when it needs to. We make sure every pillar maps to a buying conversation that the AEs are having.

We covered the broader thinking on choosing topics in our piece on content strategy for B2B tech, and the same logic applies to picking a pillar.

Architecture: hub, spokes and the in-between

The basic shape is a single pillar page (the hub), 12 to 30 cluster articles (the spokes) and tight internal linking between them. In practice we add a few more layers.

• Pillar page. A long, definitive piece on the topic. 2500 to 4000 words. Designed to rank for the head term and to be the canonical entry point. It links out to every cluster article and back to the relevant service page. We’ve broken the page-level architecture down further in pillar page structure.
• Cluster articles. 1100 to 1800 words each, answering one question that sits inside the pillar’s scope. Each links back to the pillar and across to two or three sibling articles.
• Comparison and decision pages. Where the pillar topic includes a vendor or product decision, we add comparison content as part of the cluster. We covered the structure for those in feature comparison content that actually ranks.
• Pillar-adjacent assets. Glossary entries, FAQs, calculators, downloadable templates. These pick up long-tail traffic and feed links back into the cluster.
• Service page. The pillar should link cleanly to the relevant content marketing or SEO service page so that buyer interest converts.

The internal linking is what makes the structure compound. We mapped out the wider mechanics in internal linking for tech sites and the broader topic-clustering view in topic clusters for tech companies.

Plan the whole cluster before you publish the pillar

The mistake we see most often is teams publishing the pillar first and figuring out the cluster later. By the time the third cluster article goes live, the pillar is already out of date and the internal links do not match the structure that emerged.

We plan the cluster as a single document before the first piece is commissioned. That document lists every article we expect to publish, the working title, the target query, the primary reader and the position in the cluster. It also flags which existing articles on the site can be folded into the cluster (often a third of the cluster already exists in some form, just unconnected).

The plan changes as we publish, of course. New questions surface, search trends shift and some articles turn out to be subsections of others. But the discipline of planning the whole cluster up front means the architecture holds together as it grows.

Cadence: how to actually publish a cluster

We typically launch a cluster with the pillar plus three or four supporting articles, then publish a new cluster article every two weeks. That cadence is steady enough to build search momentum and slow enough that the team can keep the quality bar high. A cluster of 20 articles takes about nine months to publish in full.

During the build, we keep a simple sheet that tracks each article’s status, the pillar links it earns and the queries it ranks for. After three months we run the first review pass: which articles are pulling traffic, which need a refresh, which need internal links rebalanced. After six months we look at conversion paths: which articles are starting demo flows, which are showing up in HubSpot before a closed-won deal.

Write each piece as part of the whole

Cluster articles often read like orphans because they were written like orphans. The brief talks about the article in isolation, the writer never sees the rest of the cluster and the result is a piece that does not refer to anything around it.

Our briefs include a small section called “where this sits”. It names the pillar, the two or three most relevant sibling articles and the key terms the article should not duplicate. Writers can then build natural references to the rest of the cluster, with phrases like “we cover the structure in more detail in our piece on case studies” rather than dropping links at random. The same approach shapes our editorial workflow more broadly, which we wrote about in editorial calendars for tech marketing teams.

Refresh the pillar, not just the spokes

Pillar pages are easy to forget. Once they are live, they tend to be left alone while the team focuses on new cluster articles. That is a mistake. The pillar earns more links and more traffic than any single cluster piece, and a stale pillar drags the whole structure down.

We schedule a quarterly refresh on every pillar. New data, updated examples, fresh references to the latest cluster articles. Search engines reward the freshness, and buyers landing on a pillar that was last updated two years ago notice immediately.

If you are planning a pillar programme and the cluster map is feeling unwieldy, we’d be glad to talk through it. It is one of the harder problems in B2B tech content, and the difference between a cluster that compounds and one that fizzles is almost always in the architecture.