OUTRANKED.ME

Topic clusters and pillar pages: structuring a blog that ranks

By Outranked.me · published · updated · 8 min read

A blog is a list. A cluster is a structure. The difference decides whether forty articles compound into something or sit there individually failing.

Two sites publish forty articles each over a year. One gets steadily more visible; the other stays flat. The articles are of similar quality.

The difference is usually structure. The first site covered one subject in a connected way. The second published forty separate things in the order they occurred to someone.

A blog is a list, ordered by date, where the newest thing is at the top and everything older sinks. A cluster is a structure, organised by subject, where each new piece makes the existing pieces stronger. The second compounds; the first does not.

What a cluster actually is

A pillar covers a subject broadly. It is the page you would send someone who asked "explain this whole area to me". It is deliberately not exhaustive on any one point.

Spokes each own one specific question within that subject, in the depth the pillar cannot afford.

Every spoke links up to the pillar. The pillar links down to the spokes. Spokes link across to each other where the connection is genuine.

That is the entire idea. The value is not in the diagram; it is in three consequences.

Coverage. Ten pages that map a subject demonstrate something one page cannot: that this site has actually covered this territory.

Internal links that mean something. Links inside a cluster describe relationships between related things, which helps establish what your site is about. Links between unrelated posts describe nothing.

No cannibalisation. Each page owns one question, so pages stop competing with each other for the same query — the failure mode covered in keyword cannibalisation.

Choosing the pillar

The commonest mistake is picking a pillar that is too broad. "Marketing" is not a pillar; it is a career. A pillar should be a subject you could plausibly cover in fifteen to thirty articles.

Three tests:

Can you name twenty real questions inside it? From customer emails, sales calls, the phone. If you struggle past eight, the subject is too narrow to be a pillar and is probably itself a spoke.

Is it something your business genuinely knows? A cluster is a claim to be a credible source. If the knowledge is not there, it will read as assembled rather than known.

Would a customer recognise it as one subject? If the questions inside it feel unrelated to a reader, it is two clusters.

Building it in the right order

The order matters more than people expect.

Write the pillar first. Not because it will rank soon — it usually will not, since pillars target the broadest and most contested terms — but because every spoke needs somewhere to link up to on the day it publishes. Retrofitting links across thirty articles later is work nobody ever gets round to.

Then write spokes for the questions you can actually win. These are the narrow, specific ones. They will rank before the pillar does, and they are what produce the first real traffic. Choosing them is covered in judging whether you can realistically win a keyword.

Then revisit the pillar. Once eight or ten spokes exist, the pillar can link to them all and becomes genuinely useful — a map of a territory you have actually covered rather than a promise.

Finish one cluster before starting another. A half-built cluster is a list with extra steps. Two half-built clusters are worse than one finished one.

What each page should own

The rule that keeps a cluster coherent: one page, one question.

If you cannot state in a single sentence which question a page answers, and if that sentence is not different from every other page's sentence, you have a duplication problem waiting to appear.

An illustrative cluster for a firm selling accounting software:

| Page | The question it owns | |---|---| | Pillar | How does bookkeeping work for a small business? | | Spoke | When do you have to register for VAT? | | Spoke | Cash or accrual accounting — which applies to you? | | Spoke | What records must you keep, and for how long? | | Spoke | What can you actually claim as an expense? | | Spoke | How do you handle an invoice that is never paid? |

Each is a genuinely different question from a reader in a different situation. None of them is a rephrasing of another. That is the standard.

Planning one before you write anything

Two hours with a blank page, done once, prevents most of the failures below.

1. Write the subject at the top. One line. If it takes a paragraph, it is two subjects.

2. List every question a customer has ever asked about it. From emails, sales calls, the phone, complaints. Not keywords — questions, in the words people used. Aim for thirty; you will use most of them.

3. Group them. Some are the same question asked differently — merge those now, on paper, where it costs nothing. Some are one question with several situations attached; those may be one page or several depending on whether the answers genuinely differ.

4. Mark which you can answer better than what currently ranks. Search four or five of them and look. This is the step that turns a list into a plan, because it tells you which pages have a route to ranking and which are you writing for completeness.

5. Put them in order. Pillar first, then the ones you marked in step four, then the rest. The reasoning is in how many articles before SEO starts working.

6. Write one sentence per page stating the question it owns. Keep this list. It is what you check against before publishing anything new, and it is the single thing that prevents the cluster from quietly duplicating itself.

The output is not a diagram. It is a numbered list of questions with an owner page each, which is a far more useful artefact than a hub-and-spoke picture.

When a spoke turns out to be a cluster

It happens on any subject worth covering: you start writing a spoke and find it contains six real questions rather than one.

That is a signal, not a problem. The right response is to promote it — the spoke becomes a sub-pillar with its own spokes beneath it, still linking up to the original pillar. Two levels is manageable and common. Three is usually a sign the top-level subject was too broad to begin with.

What not to do is force the six questions into one page. A page trying to answer six distinct questions answers none of them as well as the pages that answer one, which is the whole mechanism by which clusters work in the first place.

Linking inside a cluster

Every spoke links to the pillar. Once, in context, early, with anchor text that describes the destination.

The pillar links to every spoke, at the point in the argument where the reader would want more depth on that specific thing.

Spokes link to each other only where the connection is real. A reader on the VAT page may genuinely want the record-keeping page. They probably do not want the unpaid-invoice page. Forced cross-linking to hit a number produces the dense, unreadable interlinking that marks machine-built sites.

Anchor text should describe what the reader will find — Google's guidance is for descriptive anchors, and repeating an identical keyword phrase into every link is a pattern rather than an optimisation.

Where clusters go wrong

The pillar is a table of contents. A pillar with no substance of its own, existing only to list links, is not a page anyone wants. It should be genuinely readable alone.

Spokes duplicate each other. "How to get backlinks" and "how to get high-quality backlinks" are one page. If two spokes serve the same intent, merge them.

The cluster is abandoned at four articles. The compounding only starts once a subject is covered. Four is a start, not a cluster.

Links are added later. They are not. Add them as you publish or they never exist.

The structure is imposed on unrelated content. Retrofitting a cluster over forty existing posts about different subjects produces a diagram, not a structure. Better to pick the subject with the most existing coverage, complete that, and let the rest be.

How this looks in practice on this site

Worth being concrete, since we are doing it.

This article sits in a content-marketing cluster whose pillar is content strategy for a business that has never published. Neighbouring spokes cover how many articles before SEO starts working and content refreshes. Each owns a different question; each links up; none of them repeats another.

The cluster was planned before the first article was written, which is why the links exist rather than being promised.

When a cluster is not the answer

If your customers do not research before buying — if the decision is immediate and local — then a body of connected articles is a slow answer to a fast problem. A plumber's customers are not reading a five-part series about pipework; they are searching once and ringing someone.

For those businesses the priority is the map results and reviews, covered in how to promote a local business online, and clusters are a secondary investment at best.

And if the queries in your subject are held structurally by large platforms, a well-built cluster may still not reach them. That is worth establishing before writing thirty articles rather than after — the trade-off is in when renting attention beats owning it, and the current cost of the alternative is on the rankings board.

Common questions

How many spokes make a cluster? Enough to cover the subject. Usually somewhere between ten and thirty; the questions decide, not the number.

Should the pillar be the longest page? Usually, but length is a consequence of covering breadth, not a target.

Can a page belong to two clusters? Occasionally, and it is a sign the clusters overlap more than they should.

What if I already have a disorganised blog? Pick your strongest subject, identify the posts that belong to it, write the missing pillar, link them together, and leave the rest alone until that one works.

Sources

See the data behind this

Outranked.me ranks businesses by verified spend, and publishes the whole record: the live leaderboard, every position change with the competitor that caused it, and the open dataset behind both.

Read next