TL;DR
- We audited our own content plan before launching it. Across 189 planned articles in 15 topical hubs, 42 of 173 cluster articles, 24%, were scheduled to publish before the pillar they support.
- In the first wave the figure was 68%, 13 of 19 clusters.
- The largest gap was nine months. One cluster was scheduled for month one against a pillar arriving in month ten.
- Twelve of fifteen hubs were affected. This is not a slip. It is what happens when a calendar is sorted by keyword opportunity rather than by structure.
- The fix is an ordering rule, not a content rule: publish the pillar first, or in the same week as its first cluster, in every hub.
Choosing which topics deserve a hub at all is the decision before this one, and our guide to B2B keyword research covers how to price a keyword before committing a cluster to it.
What is the pillar and cluster content model?
A site structure where one broad page covers a topic at summary depth, several narrower pages cover its subtopics in full, and all of them link to each other. HubSpot popularised it in 2017 and the shape has not changed much since.
Three plain-English terms:
- A pillar page is the broad one. It covers the whole topic but does not exhaust any part of it.
- A cluster page is a narrow one. It takes a single subtopic and goes deep.
- Bidirectional linking means the pillar links down to each cluster and each cluster links back up to the pillar. Both directions, not one.
The purpose is to show a search engine that your site covers a subject rather than a keyword. A hub of twelve connected pages on one topic reads differently from twelve unconnected posts on twelve topics, even if the word count is identical.
Why does the model still work in 2026?
Because the retrieval changed in a way that suits it. Search systems no longer evaluate whole pages against whole queries. They break a question into related sub-questions, retrieve passages from several sources, and assemble an answer.
Two mechanics matter here:
- Query fan-out. A single question is expanded into related sub-questions behind the scenes, and the answer is built from all of them.
- Passage-level retrieval. What gets pulled is a section of a page, not the page.
A hub with a pillar and ten deep clusters happens to be a good shape for that. It gives a retrieval system a clean, self-contained passage for each sub-question rather than one page trying to cover everything shallowly.
But this is now the consensus, not an insight. Every guide competing for this term explains fan-out and passage retrieval, and most of them explain it well. The advice is correct and it is everywhere, which means it is no longer the useful part. The useful part is the next section.
What we found auditing our own 189-article plan
We planned a 189-article programme across 15 topical hubs. Before publishing anything, we audited the calendar against the structure. The result was worse than we expected.
42 of 173 cluster articles, 24%, were scheduled to publish before the pillar they were supposed to support.
| Finding | Figure |
|---|---|
| Total articles planned | 189 |
| Pillars | 16 |
| Cluster articles | 173 |
| Clusters scheduled before their pillar | 42 (24%) |
| Hubs affected | 12 of 15 |
| Largest gap | 9 months |
| Clusters before pillar, first wave only | 13 of 19 (68%) |
The worst case was a cost guide scheduled for month one whose hub pillar was scheduled for month ten. The first wave was the most affected, at 68%, which is exactly backwards: the wave with the least accumulated authority had the least structural support.
Nobody plans this deliberately. It happens because a content calendar gets sorted by keyword opportunity, and the highest-opportunity keywords are frequently the specific commercial ones, which are clusters. The broad definitional terms that make good pillars have lower opportunity scores, so they sink down the calendar.
Sorting by opportunity is how you get a plan where the roof arrives before the walls.
This article is one of the 42. It is a cluster in a hub whose pillar publishes three months after it. That is not irony, it is the finding.
We are publishing this because it is the most useful thing we learned building the programme, and because a model everyone describes and nobody audits is worth auditing out loud.
Why does publish order matter more than the model?
Because a cluster published before its pillar is a page with nowhere to send authority and no hub to inherit it.
Four things go wrong, in order of cost.
1. The up-link cannot exist. Every cluster is supposed to link to its pillar. If the pillar has not been published, that link is either a broken URL or plain unlinked text somebody has to remember to convert later. Across 42 articles, that is 42 manual conversions nobody has scheduled.
2. The pillar arrives with no accumulated equity. The point of a hub is that clusters pass signals to the pillar over time. A pillar published in month ten has received nothing from the five clusters that preceded it, and it is starting from zero on the hardest keyword in the hub.
3. The clusters compete with each other. Without a pillar to anchor the topic, several clusters covering adjacent subtopics can end up competing for the same broad query. Google picks one, usually not the one you wanted.
4. Nobody notices. This is the expensive part. Each individual article looks fine. The rankings look reasonable. The problem is that the compounding never starts, and that absence does not appear on any dashboard.
The rule that prevents all four: publish the pillar first, or in the same week as its first cluster, in every hub. Nothing else in this article matters as much.
How do you build a pillar and cluster set, in order?
Time required: about a day to plan a hub, then normal production time per article. Prerequisites: a keyword list with search volume and difficulty, and your site's existing pages mapped to topics.
Step 1. Pick the topic, not the keyword
A hub covers a subject you want to be known for. If you cannot name ten distinct sub-questions a buyer would ask about it, it is a cluster, not a hub.
Step 2. Assign the pillar and the clusters
The pillar takes the broadest term. The clusters take the specific ones. Check for overlap now: if two planned clusters would be satisfied by the same page, merge them before writing anything.
Step 3. Order the calendar by structure, then by opportunity
This is the step this article exists for. Place the pillar first in every hub. Then sort the clusters by opportunity within the hub. Do not sort the whole plan by opportunity and let hubs fall where they land, which is how you get a 24% error rate.
Step 4. Ship the pillar with two or three clusters together
A pillar alone has nothing to link down to. Publishing it with its first two or three clusters gives the structure something to be from day one.
Step 5. Add links in both directions on publication day
Not in a later sprint. The cluster links up to the pillar, the pillar links down to the cluster, both on the day the cluster goes live. Section seven covers the mechanics.
Step 6. Publish remaining clusters on the sorted order
Each one adds a down-link to the pillar and an up-link from itself.
Step 7. Re-audit the calendar quarterly
Plans drift. Articles move. Re-run the check in section three: for every cluster, is its pillar already published? This takes ten minutes with a spreadsheet formula and it is the check we should have run at planning time.
How long should a pillar page be?
Long enough to cover every subtopic at summary depth, and no longer. Published guidance in 2026 clusters around 2,500 to 4,000 words, with a caution that pages beyond roughly 5,000 words risk diluting passage-level relevance because retrieval systems extract sections rather than whole pages.
The more useful test than word count: does the pillar summarise each subtopic and link out for the full treatment, or does it try to be the full treatment? If it is the second, your clusters have nothing left to say and you have built one long page with satellites.
A practical symptom of getting this wrong. If your pillar is comprehensive enough that a reader never needs the clusters, the clusters will not rank, and the hub is a pillar with decoration. If your pillar is so thin that it is only a table of contents, it will not rank either. Summary depth per subtopic, full depth in the cluster.
How should the internal links actually work?
Bidirectionally, with descriptive anchor text, added on publication day.
The mechanics, specifically:
- Cluster to pillar. Every cluster links up to its pillar, ideally within the first 200 words, using anchor text containing the pillar's primary keyword.
- Pillar to cluster. The pillar links down to every cluster, in the section that summarises that subtopic.
- Cluster to cluster. Each cluster links to one or two siblings where genuinely relevant. Forced sibling links read as bolted on and help nobody.
- Anchor text mix. Vary between exact-match, descriptive and natural-sentence anchors. Identical anchor text on every link is a pattern, and patterns get discounted.
- Timing. Both directions live within 48 hours of the cluster publishing. Anything longer becomes a task nobody does.
One rule worth writing down before you need it: decide in advance what happens when a cluster publishes before its pillar. Either hold the cluster, or ship the anchor as plain text with a dated task to convert it. Choosing in the moment means the second option, and forgetting.
What do most teams get wrong?
Sorting the calendar by opportunity score. The single most consequential error and the one that produced our 24%. Opportunity ranks keywords. Structure ranks hubs. Sort by structure first.
Treating the pillar as a summary of the clusters. Write the pillar as a standalone page that happens to link out, not as an index.
One-directional linking. Clusters link up because writers remember to. Pillars link down because somebody goes back and edits them, which is the step that gets skipped.
Building a hub around a topic with fewer than five real subtopics. If you cannot name ten sub-questions, and comfortably write five, it is not a hub.
Two pillars in one hub. We have one, and it creates a genuine problem: two pages compete for the anchor role, clusters do not know which to link to, and the link equity splits. Pick one canonical anchor per hub.
Never re-auditing. Plans drift as priorities change. The check takes ten minutes.
Who pays for this: the person who approved a twelve-month content budget, because the failure is invisible on a monthly report. Traffic rises modestly, every article looks acceptable, and the compounding that justified the investment never begins.
How does Euracle plan content programmes?
By auditing the calendar against the structure before anything is written, which is a habit acquired the hard way.
The Eureka Method, Euracle's discovery sprint, applies four steps here.
Discover prices the keyword set so hubs are chosen on expected pipeline rather than on volume, using the method in our keyword guide.
Design assigns pillars and clusters, then orders the calendar by structure before opportunity, which is the specific correction that came out of the audit above.
Deploy ships each pillar with its first two or three clusters and adds links in both directions on publication day.
Scale re-runs the structural audit quarterly, because plans drift.
The stack is unremarkable: Ahrefs and SEMrush for keyword and difficulty data, Google Search Console and GA4 for measurement, and a spreadsheet with a formula that flags any cluster scheduled ahead of its pillar. That last one is not sophisticated. It is the check that would have caught 42 articles.
Two structural commitments come from how Euracle is set up. Senior practitioners only: the people in the pitch do the work. And one contract across six disciplines, so a finding that the content plan needs restructuring rather than more articles does not require a second conversation with a different vendor.
If you want the structure audited before the calendar is committed, that is Euracle's SEO service. The problem is most expensive for B2B SaaS companies, where large content libraries accumulate around product features rather than around buyer questions.
The AI-visibility half of this work, including why self-contained passages matter more than they used to, sits in our generative engine optimization guide.
FAQ
Conclusion
You can now audit your own plan in about ten minutes, which is roughly nine minutes and fifty seconds more than we spent before writing ours. Add a column for each article's hub, a column for that hub's pillar publish month, and flag every row where the article lands first. Then reorder: pillar first in every hub, clusters sorted by opportunity within the hub, links in both directions on publication day. The model itself is not the hard part and has not been for years. The order is. If you want the structure audited before your calendar is committed, talk to Euracle about SEO.
Sources
- Euracle content plan audit, 2026. 189 planned articles, 16 pillars, 173 clusters, 15 topical hubs. 42 clusters (24%) scheduled before their hub pillar; 12 of 15 hubs affected; first wave 13 of 19 clusters (68%).
- Pillar page length guidance of 2,500 to 4,000 words and the caution about dilution beyond roughly 5,000 words.
- Query fan-out and passage-level retrieval, described in Google's own documentation on generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
- HubSpot's popularisation of the topic cluster model in 2017.
