Content clusters that compound: planning in public

Most company blogs are archipelagos: hundreds of islands, no bridges. A post about onboarding here, a post about onboarding there, three posts about onboarding written eighteen months apart that have never met each other. Each one ranks for nothing, links to nothing, and quietly decays. Then the team concludes "content doesn't work for us" and the budget moves to paid ads with the half-life of a mayfly.

The alternative is a cluster: one authoritative pillar page surrounded by tightly focused articles that link to it and to each other, covering a topic so completely that both readers and search engines conclude you own it. Clusters don't just rank better page-for-page — they compound, because every new article strengthens every existing one. This is the planning method we use with clients and on our own journal (you're reading a spoke in a growth cluster right now).

Why clusters beat campaigns

A standalone article has to earn everything alone: authority, links, rankings, trust. An article inside a cluster inherits. Internal links from siblings pass context and equity; the pillar concentrates external links and redistributes them; the reader who lands on any page has somewhere excellent to go next, so engagement signals improve across the whole graph.

There's also an editorial benefit nobody mentions: clusters make content decisions easier. "Does this fit a cluster we own?" is a better brief filter than "is this keyword big?", which is how blogs fill up with articles about topics adjacent to the business but useless to it.

Pillar economics: choosing what to own

A pillar is a promise to be the best resource on a topic — a 2,500-word-plus guide that answers the head question completely and routes readers to spokes for depth. Choose pillars with cruel honesty:

• Is the topic load-bearing for the business? A pillar should map to a service, a product surface, or a problem your customers definitely have. Our landing page anatomy piece exists because clients ask us about conversion weekly. Rank for your strangers' questions, not your industry's gossip.
• Can you actually be the best answer? If the first page of results is ten competitors with more data, more examples and more authority, pick a narrower topic. Owning "checkout UX for subscription groceries" beats being the fourth-best page about "e-commerce UX".
• Is there a spoke-shaped long tail? A good pillar naturally decomposes into eight to twenty sub-questions. If you can't list twelve spokes on a whiteboard in ten minutes, the topic is too thin to cluster.

Three to five pillars per year is a sane ambition for most teams. Each one is a quarter of focused publishing, not a content calendar filler exercise.

The spreadsheet (this is the part everyone skips)

Cluster planning lives or dies in one spreadsheet, with one row per intended article and these columns:

1. Query / topic — the primary search intent, phrased as a searcher would.
2. Intent type — informational, comparative, transactional, navigational. Mixed-intent pages serve no one well.
3. Cluster — which pillar it belongs to. If it belongs to none, it waits.
4. Funnel stage — stranger, prospect, evaluator, customer. Clusters that only talk to strangers never show revenue; clusters that only talk to evaluators never grow traffic.
5. Target URL — stable and human-readable. Decide slugs before writing, so internal links can be built into drafts rather than retrofitted.
6. Links out — the three to six internal links each piece will carry: up to the pillar, across to siblings, sideways to a service or case study. We write ours like case studies with real texture so cited work earns the click.
7. Status & refresh date — every piece gets a review date at publication. More on that below.
8. Metric of success — one primary measure decided before publishing: impressions, newsletter signups, assisted demos. Pre-committing to a metric prevents the post-hoc cherry-picking that makes content reports fiction.

This spreadsheet is the strategy. When it says no, the answer is no.

The link graph is the strategy

Writers think in articles; clusters work as graphs. Our linking rules are boring and non-negotiable:

• Every spoke links up to its pillar, in the first third of the article, with descriptive anchor text.
• Every spoke links across to the two or three most relevant siblings — chosen by reader intent ("if you cared about that, you'll care about this"), not by recency.
• Every pillar links down to every spoke, updating the pillar each time a spoke publishes. Pillars are maintained documents, not launch-and-leave posts.
• Each cluster links sideways to exactly one commercial page — a service, a demo, a guide in the resources hub. Not five. One good bridge, placed where it helps.

We hold the same discipline across the whole site: even our technical pieces, like the technical SEO checklist, link up, across and sideways rather than hoarding attention. Six links per article, chosen on purpose, beat twenty links chosen by a plugin.

Publish less, refresh more

The arithmetic nobody wants to do: updating a proven article from position 9 to position 3 is usually worth more than the next five new articles combined, at a fraction of the effort. So the calendar runs 60/40 — sixty per cent new spokes, forty per cent refresh — and every piece carries the refresh date from the spreadsheet.

A refresh is not a date change. It's: re-check the query's results page (what does "best" mean now?), add the example you'd include if you wrote it today, fold in anything readers emailed about, tighten the intro, update the screenshots, then bump the date and log it. Our rule of thumb: if the update wouldn't be worth emailing your newsletter about, it wasn't a refresh.

The first ninety days

The sequence that works:

1. Weeks 1–2: keyword-to-intent mapping and the spreadsheet. Interview three customers or sales calls and steal their nouns.
2. Weeks 3–4: publish the pillar first. It's the anchor; spokes need somewhere to point.
3. Weeks 5–12: two spokes a week, each with the linking rules applied at draft time. Publish in a sensible arc — foundational concepts before edge cases — because readers and crawlers both experience the cluster as a body of work.
4. Day 90: first honest review. Which spokes earn impressions? Which links get clicked? Refresh the pillar to reflect reality, prune or merge anything dead, and only then decide whether the cluster earned its next quarter.

Measuring a cluster, not a page

Page-level metrics lie about clusters — spokes cannibalise and assist each other constantly. Measure at the cluster level: aggregate impressions and clicks, ranking coverage across the query family, and the business metric the cluster exists to move. Give a cluster two quarterly cycles before judging it, the same patience you'd give a hire. The teams that fail at content mostly fail at waiting.

Key takeaways

• Three to five pillars a year, chosen by business relevance and winnability — never by volume alone.
• The spreadsheet is the strategy: intent, funnel stage, links and success metrics decided before a word is drafted.
• Link up, across and down, with one bridge to a commercial page. The graph does the compounding; articles are just its cells.
• Budget 40% of content effort for refreshes. Updating a proven page beats publishing a hopeful one.
• Judge at ninety days, at the cluster level. Content fails from impatience more often than from quality.

FAQ

How many articles does a cluster need before it works? One pillar plus six to ten spokes is the smallest unit that behaves like a cluster — enough to cover a topic's obvious sub-questions and build a meaningful link graph. Below that you have a page with friends; above twenty, watch for spokes cannibalising each other.

Should clusters live on the blog, or closer to product pages? Intents belong near their natural homes. Educational clusters can live in a journal, but transactional and evaluative content should sit near the thing being evaluated. An architecture like how we structure service pages and their supporting articles together consistently outperforms a distant blog silo.

What if two of our clusters overlap? Overlapping reader interest is fine — overlapping primary intent is not. If two planned articles target the same query, merge them or differentiate the intent explicitly. One canonical answer per question, or you compete with yourself and lose twice.

Do we need keyword tools to do this? They help with volumes and variants, but the spine of a good cluster comes from customer language: sales calls, support tickets, search logs on your own site. Tools tell you what everyone already knows; conversations tell you what nobody has answered well yet.

Our blog already has 200 scattered posts. Do we start over? No — audit them into clusters. Most legacy blogs contain two or three accidental clusters worth formalising: find posts that already rank, assign them pillars (writing new pillars if needed), retrofit the link graph, and merge or redirect the stragglers. Rescue beats replacement almost every time.