Usually because those 80 posts are 80 separate islands. Each one targets a different keyword, none of them link to each other, and no single page is strong enough to own a topic. A pillar and cluster structure fixes that by pointing all the small pages at one big one.
We see this pattern constantly. A company publishes for two years, builds a real library, and gets almost nothing back. The content is not bad. It is just unorganised. Search engines cannot tell what the site is actually about, because every page argues for a different subject.
The scale of the problem is worth sitting with. Ahrefs published a study of roughly 14 billion pages from its Content Explorer index in 2023 and found that 96.55% of those pages get zero traffic from Google, with another 1.94% getting between one and ten monthly visits. Publishing more is clearly not the lever. Publishing in a structure is.
A pillar page is one long page that covers a broad topic at a high level. It answers the main question, defines the terms, and links out to deeper pages on each subtopic. HubSpot describes a pillar as content that covers a broad subject at a high level and acts as the authoritative overview that defines the topic.
Think of it as the front door to a subject. If someone lands on it knowing nothing, they should leave understanding the shape of the whole thing. They should also see clear paths to the detail, because a pillar page is not supposed to say everything.
The practical test we use is simple. If you cannot summarise the page in one sentence that a stranger would understand, it is not a pillar. It is just a long article. A pillar has a single subject and a single job.
A content cluster is the group of supporting pages that sit around a pillar. HubSpot describes cluster content as pages that each address a specific subtopic, long-tail question, or use case within the broader subject. Every cluster page links up to the pillar, and the pillar links down to each of them.
The links are the whole point. Without them you have a folder of related articles, which is what most blogs already are. With them you have a structure that says, clearly and repeatedly, that this site covers this subject in depth.
Cluster pages are also where the specific queries live. Your pillar might target a broad head term. Your cluster pages target the questions people actually type, including the awkward ones nobody thinks to optimise for. That is where most of the traffic quietly comes from.
It came out of HubSpot. HubSpot credits former employees Anum Hussain and Cambria Davies with the 2015 research behind it. According to HubSpot, their finding was that the more internal links they added between related pages, the higher those pages climbed in search results and the more impressions they earned.
That origin matters because it tells you what the model is really about. It is not a content format. It is an internal linking experiment that turned into a content format. People remember the long pillar page and forget the links, which is exactly backwards.
The model has aged well for a reason. It maps onto how search engines evaluate a site, and it also maps onto how a reasonable human would organise a library. Those two things agreeing is rare enough in SEO that it is worth paying attention to.
Pick a topic broad enough to support eight to fifteen genuine subtopics, and narrow enough that you could plausibly become one of the better sources on it. If you cannot name ten real questions under it, the topic is too small. If you could write a hundred, it is too big and you need to split it.
The second filter is commercial. A pillar takes real effort, so it should sit near something you actually sell. We look for the topic a prospect researches right before they start shortlisting suppliers. That is the page worth owning.
The third filter is honesty about your position. You are not going to win a generic head term against a site with twenty years of authority behind it. Go one level more specific, own that completely, and expand outward later. We wrote more about that patient approach in our piece on what topical authority is and how you build it.
There is no magic count, but eight to fifteen is where most clusters start feeling solid. Fewer than five and the structure is too thin to signal anything. More than twenty and you usually have two clusters pretending to be one, which creates overlap and confusion rather than depth.
The better question is coverage, not count. List every real question a person has about your topic, group them, and see which groups you have answered. Gaps in the map matter more than the number of pages on it.
We also build clusters slowly on purpose. Publishing fifteen posts in a fortnight tends to produce fifteen mediocre posts. Publishing one a week for four months, with each one linked into the structure as it lands, produces something that keeps working. Speed helps at build time. It rarely helps at content time.
Every cluster page links to the pillar using descriptive anchor text about the pillar topic. The pillar links back out to each cluster page in the section where that subtopic is introduced. Cluster pages can link to each other when it genuinely helps a reader, but the pillar stays the hub.
Anchor text carries a lot of the weight here. Ahrefs, in its internal linking guide, quotes Google search advocate John Mueller saying that anchor text gives additional context about the page you are linking to. Generic anchors like click here throw that context away. Descriptive anchors keep it.
Ahrefs also suggests three to five contextual links per article as a reasonable starting point, and warns that stuffing in more dilutes how link value gets distributed. That matches what we do on client builds. A handful of well-placed links inside sentences beats a block of twenty at the bottom that nobody reads.
The mechanical part is easy to get wrong at scale, so it helps to have a system rather than good intentions. We covered the practical side of that in our guide to what internal linking is and how it improves SEO.
Yes, and arguably better than before. AI answer engines like ChatGPT, Perplexity, and Google AI Overviews break a question into smaller sub-questions and gather sources for each. A cluster is a site that has already answered those sub-questions on separate, clearly labelled pages. That is a convenient shape to be cited from.
The pillar page usually is not the page that gets cited. The specific cluster post is. Somebody asks a narrow question, and the page that answers exactly that question in its first forty words is the one that gets pulled. The pillar earns the topical credibility. The cluster earns the citation.
This is why we now write cluster posts with a stricter format than we used to. Every heading is a real question. Every heading gets a direct answer immediately underneath it. No warm-up paragraph before the answer. If a machine has to hunt for your point, it will use a site where it does not have to.
The four we fix most often are clusters with no links, pillars that try to say everything, cluster posts that compete with each other for the same query, and pillars built around a topic the business does not actually sell. Each one quietly wastes months of publishing.
The no-links mistake is the most common by a distance. Teams write the pillar, write the cluster posts, and never wire them together. That is the version of the model with the engine removed, and it was the engine that made the original research work in the first place.
The overlap mistake is sneakier. Two cluster posts drift toward the same question, both rank weakly, and neither gets clear. If you have ever watched a page you did not care about outrank the one you did, that is usually what happened. We walked through the diagnosis in our article on how to fix keyword cannibalization on your website.
The last one is the most expensive. A beautifully executed cluster on a topic that never leads to a sale is still a wasted quarter. We ask early and bluntly what the pillar is meant to sell. If nobody can answer that, we do not build it.
Start with an audit, not a blank page. Export every URL, tag each one with its topic, and see what clusters already exist by accident. Most sites we look at have two or three half-finished clusters buried in an unsorted archive. Finishing those is faster than starting fresh.
Then pick the strongest half-cluster and complete it. Write or rewrite the pillar, fill the two or three obvious content gaps, and go back through the existing posts adding links up to the pillar. That last step is unglamorous and it is usually where the movement comes from.
Do the retrofit before you publish anything new. It is genuinely common for the retrofit alone to lift pages that have been flat for a year, because nothing was wrong with them except that they were invisible to the rest of the site.
Fix what you have first, almost always. If you already publish regularly, the fastest gain is organising the archive into clusters and wiring the links, not adding a long new page on top of a pile that nobody can navigate. Build the new pillar once the existing structure is doing its job.
The exception is a brand new site with nothing to organise. There, starting with one pillar and three cluster posts is a clean way to begin, because you are building the structure before the mess exists rather than after.
If you are staring at an archive and not sure which of those two situations you are in, we are happy to look at it with you. Send us the site over at phoenix.studio and we will tell you plainly whether you have a content problem or a structure problem. In our experience it is usually structure, and that is the cheaper one to fix.
Tell us where you want to go. We'll tell you how we'd get you there.