The pillar and cluster model is well known and badly executed, and the failure is nearly always the same one.
People build a long pillar page that covers everything, then build supporting pages that cover the same things again in slightly more detail. The result is forty pages competing with each other, and the pillar usually loses to its own supports.
The fix is a clear division of labour between the two page types, decided before anything is written.
Here is the division I use, plus the linking rules that make the structure do its job.
Quick Info
The Division of Labour
This is the whole model in two sentences.
The pillar answers the whole question at breadth. Each support answers one part of it at depth. Neither does the other's job.
So a pillar section on a sub-question gives the complete short answer, roughly a hundred and fifty words, and links to the support. The support gives the full treatment, a thousand words or more, and links back.
If the pillar section and the support say the same thing at the same length, you have two pages doing one job and they will compete.
What Goes on the Pillar
Structure, in order.
Length follows from the number of sub-questions, not from a target. Eight sub-questions produces roughly two thousand words, which is plenty.
What does not go on the pillar: exhaustive detail on any one sub-question. That is what the supports are for, and putting it here is the specific cause of cannibalisation.
What Goes on a Support Page
One sub-question, treated completely.
The test for whether a support deserves to exist: does it contain at least six hundred words that would not fit on the pillar? If not, it belongs as a section on the pillar and nothing else.
This test alone prevents most thin-content clusters.
How Many of Each
One pillar per major theme, six to ten supports beneath it, three to five pillars per subject.
That is thirty to fifty pages for a complete subject, which is a six-month project at a sustainable rate. My topical authority article has the timeline.
Two constraints worth stating. Fewer than four supports and the cluster is not really a cluster, it is a page with links. More than twelve and you are probably splitting sub-questions too finely, producing thin pages.
And build one cluster completely before starting the next. Half-built clusters behave like scattered pages, which is to say they do very little.
The Linking Rules
The linking is the structure. Without it you have a folder of pages.
Do this at publication, not in a retrospective pass. Retrospective linking across forty pages is a day of work that never gets scheduled.
Avoiding Overlap
Three habits that prevent the cannibalisation problem entirely.
First, write the sub-question list before any page, and assign each sub-question to exactly one support. If two supports would both cover it, they are one support.
Second, keep a one-line note per page saying what that page and only that page answers. If you cannot write that line, the page should not exist.
Third, check the title tags across the cluster before publishing. If two are near-identical, one of the pages is redundant.
When overlap does happen, and it will, merge rather than differentiate. Redirect the weaker URL into the stronger, combine the content, and update the internal links. Merging is almost always the right answer and almost never the instinctive one.
Maintaining a Cluster
Clusters decay as a unit, which is convenient, because it means they can be maintained as one.
Once a quarter, per cluster: check the pillar still links to everything, check any new content got linked in, refresh the statistics across the whole set in one sitting, and see whether any sub-question has grown enough to deserve promoting from a pillar section to a support.
That last one is the sign a cluster is working. Subjects grow, and a good cluster grows with them rather than being rebuilt.
An hour a quarter per cluster keeps the whole structure current.
Frequently Asked Questions
The pillar answers the whole subject at breadth, with a short complete answer per sub-question. Each support answers one sub-question in depth. Neither should do the other's job.
As long as its sub-questions require, typically around two thousand words for eight sub-questions. Length should follow structure, not a target.
Six to ten. Fewer than four is not really a cluster, more than twelve usually means you are splitting sub-questions too finely.
Assign each sub-question to exactly one support, keep the pillar's treatment short and link out, and check title tags for near-duplicates before publishing.
In the first third, with anchor text describing the pillar's subject. Links buried at the bottom carry less weight and get followed less.
Merge them. Redirect the weaker URL into the stronger, combine the content and update internal links. Merging beats trying to differentiate.
Before You Go
Breadth on the pillar, depth on the supports, and a link in both directions written the day you publish.
My cluster planning template, with the one-line-per-page discipline built in, is in the resources section.
If you have a hub that is not performing and suspect the pages are competing, get in touch.
One question, one page, Tariq
I'm a marketing consultant, entrepreneur and content creator. I help businesses grow through practical marketing, websites, SEO, content and AI.
More About Tariq →