Topical Authority: Building a Cluster Search Can Actually Read

You have eleven articles on one subject and you rank for none of them. Two of the eleven swap places for the same query week after week. The newest piece, which is the best written of the group, has never appeared at all. Nobody did anything careless here. This is simply what a keyword export looks like once it has been turned into articles.

Topical authority is not an achievement of volume. It is an achievement of structure. A search engine can only work with what your pages and links actually express: which page is the general answer, which pages are the specific ones, and how they relate to each other. Where that structure is missing, publishing more only adds material that competes with itself.

So this piece does four things. It defines a cluster in structural terms you can check against your own site this afternoon. It gives a rule for deciding what is a hub and what is a spoke. It shows how to spot cannibalisation before it costs you a position you already hold. And it argues, with a concession attached, that clusters built from question lists hold while clusters built from keyword lists fall apart.

What a cluster actually is, structurally

Strip away the vocabulary and a cluster is four conditions. All four have to be true at once, and a cluster failing in the wild is nearly always failing on one of them specifically.

• One hub. A single page that covers the subject broadly and names its parts. It answers the general question and deliberately refuses to answer the specific ones in full.
• A set of spokes. Each spoke answers exactly one question completely. Not one keyword. One question, with a beginning, a middle and an end the reader can feel.
• Links running both directions. The hub links to every spoke. Every spoke links back to the hub. Spokes link sideways only where the subject genuinely continues for the same reader.
• No two pages sharing an intent. If two pages would satisfy the same searcher equally well, you do not have two spokes. You have one page that was accidentally split in half.

That is the entire model. Everything else described as topical authority is a downstream effect of those four conditions holding across enough of a subject for the relationships between pages to be legible from the outside.

The check we use is deliberately crude. Give a stranger only your internal links, with the prose removed, and ask them to draw the map. If they cannot tell which page is the general one, a crawler is not going to do better. It has strictly less context than the stranger, because it does not know what your business does.

Why keyword lists produce clusters that never work

Most clusters begin life as an export. Someone pulls a keyword tool, filters by volume, groups the results by string similarity, and hands over a spreadsheet with one parent term and thirty children. It has the shape of a cluster. It is a list of strings sorted alphabetically, wearing a diagram.

The flaw is that string similarity is not intent similarity. Consider three phrases that any grouping tool will file together: the name of a service, the name of that service plus the word checklist, and the same name plus the word cost. Those are three different people at three different moments. One is comparing options, one is already doing the work, one is trying to get a number approved internally. Give them one page and you serve none of them well. Meanwhile the question that shares no words at all with any of the three, the one that starts "why did this suddenly stop working", belongs firmly in the same cluster and never appears in the export.

Build from questions instead. Write out the questions a person asks in the order they ask them, from not knowing the subject exists to signing something. Then decide, question by question, which ones deserve their own page and which are a section inside a larger answer. That decision is the whole job, and it is precisely the part a keyword tool cannot do, because it turns on editorial judgement about whether an answer stands alone. It is also why writing a page that answers a query is a different craft from writing a page about a topic, and the difference shows up in the rankings long before it shows up in the draft.

There is a practical benefit here beyond search. A question list is reviewable by people who know the subject and nothing about organic growth. Hand a sales lead a keyword spreadsheet and you get silence. Hand them thirty questions and they will correct four of them and add two you would never have found.

Deciding what is a hub and what is a spoke

The most common structural mistake is promoting a spoke to a hub because it ranks. The logic feels sound: this page performs, so let us make it the centre and hang everything off it. What follows is predictable. The question the page answered gets buried under orientation material nobody arrived for, the page stops being the best answer to the query that made it valuable, and the position that prompted the whole idea goes away.

The substitution test

Ask whether the page could be substituted for any of its children. A hub partially satisfies every query in the cluster and fully satisfies none of them. A spoke fully satisfies exactly one and is close to useless for the others. If a candidate page completely answers one question, it is a spoke, whatever its length and whatever the traffic says.

Length is not the signal

A hub is not the longest page in the group. It is the page with the broadest scope and the shallowest treatment, and some good hubs are short, because their job is orientation and routing rather than exhaustive coverage. A very long page that answers one question thoroughly is still a spoke, and dressing it up with a table of contents does not change what it is.

The other half of this decision is commercial rather than editorial. The general question is usually the one that maps onto a service, so hubs tend to sit adjacent to a service page and inherit its language, while spokes sit adjacent to each other. Getting that adjacency right matters more than it sounds: it decides whether a reader who arrives on a narrow question ever discovers that there is a discipline behind it rather than a one-off fix.

How to detect cannibalisation before it costs you

Cannibalisation is not two pages mentioning the same term. It is two pages competing to be the answer to the same query, which forces a search engine to pick one, and the pick is unstable because neither page is decisively better. The instability is the symptom worth watching, more than any absolute position.

Fixing it in the right order

The remedy is nearly always consolidation, and the sequence matters. Decide which URL survives on the strength of its inbound links and its history rather than on which draft you prefer. Move anything worth keeping into it. Then redirect permanently, and only then update the internal links pointing at the retired address. Leaving both pages live while you think about it is how a temporary problem becomes the permanent state of a section.

If this work arrives as an audit somebody sold you, read it structurally before acting on any of it. A finding is only usable when it carries a severity, a priority and a specific recommendation attached to a specific URL, which is the discipline behind tools like Prooflin and the argument in how to read an audit you were sold. A tab of pages flagged "thin" is a symptom list, not a plan, and acting on it in order of appearance is how teams delete pages that were quietly earning links.

The links are the cluster

Without links, a cluster exists only in the planning document. The pages have no relationship anything outside your team can observe, and a shared theme is not a relationship. This is the step most often postponed and most often never done.

Two rules cover most of it. First, every spoke links back to the hub using anchor text that names the subject rather than the page, because the anchor text is the label you are attaching to the destination. Second, the hub links to every spoke in a list a reader would genuinely use, positioned where the reader needs it, not appended to the footer as a block of related links nobody scrolls to.

Sideways links between spokes are useful and very easy to overdo. Link sideways only where the second page continues the first for the same reader at the same moment. Linking every spoke to every other spoke flattens the structure into a mesh, and a mesh says nothing about which page leads. This remains the cheapest work available in the whole discipline and the least likely to be scheduled, which is why internal linking deserves a slot in the calendar rather than a note in a backlog.

Building one, in order

Order matters more here than effort. A cluster built in the wrong sequence needs the same number of pages and produces a fraction of the effect, because early pages get published without anything to link to and nobody goes back.

1. Write the question list first. Enough questions to cover the subject as a reader moves from unaware to deciding. Phrase them as a person would say them out loud.
2. Group by intent, never by wording. Two questions with the same answer are one page. Two questions with the same words and different answers are two pages.
3. Name the hub before writing it. Write the sentence describing what the hub covers and what it refuses to cover. That sentence is the scope contract for everything else.
4. Publish the commercially serious spokes first. The questions asked closest to a decision. They are the hardest to write and the first to justify the programme.
5. Publish the hub once there is something to link to. A hub with two outbound links is a stub with ambitions, and it will be judged as one.
6. Add every link as part of publishing. Not as a later pass. The later pass is the task that gets moved to next quarter forever.

That last step is a workflow problem rather than an SEO one, and it is worth solving in the tooling instead of in a checklist. If publishing a page prompts for the hub it belongs to, the links happen. If it does not, they happen for the first three pages and then stop, which is one of the things a content workspace should handle the day after launch.

A cluster is not a content plan. It is a claim about how a subject is organised, and every page you add has to keep that claim true.

Measuring a cluster without lying to yourself

Measure the group, not the page. The unit that means something is total impressions and clicks across the cluster for the family of queries you set out to answer, plus the count of distinct queries the group appears for at all. That second number moves earlier than positions do, and it moves for reasons you can act on.

Individual page positions move for reasons nobody can attribute honestly, and chasing them produces a sequence of edits that quietly undo each other. Be careful, too, about the window you promise. Structural work shows slowly and holds once it shows, which is a different curve from paid activity, and reporting them together makes both unreadable. We have set out what can honestly be measured in the first ninety days rather than repeat it here.

One warning about moving house. Redirects preserve a page; they do not preserve a structure. Internal links pointing at old addresses survive as redirect chains that still resolve, so nothing looks broken while the relationships between pages get quietly harder to read. Rebuilding internal links against the new URLs belongs on the migration checklist, not on the list of things to tidy up afterwards.

Where this stops working

Two honest limits, and the first one is the bigger. Structure makes competence legible; it does not manufacture competence. A well-organised cluster on a subject you have no real experience of reads as a well-organised cluster with nothing inside it, and that is now easier to spot rather than harder. Structure is amplification. It multiplies whatever is already there, including zero.

The second limit: some subjects are too small to deserve a cluster. If a subject holds three genuine questions, publish three pages and link them to each other. Forcing a hub on top produces a page with nothing of its own to say, which is worse than having no hub, because now the weakest page in the group is the one you have pointed everything at.

There is also a maintenance failure nobody plans for. Clusters need pruning as well as growth. Pages that no longer answer a live question, or that a better page has since replaced, should be merged or retired rather than left in place to compete for attention from inside the group. A cluster that only ever grows eventually becomes a cluster that argues with itself, and the audit that finds this is far cheaper than the year of publishing that preceded it.

The rule we apply before publishing anything into a subject we already cover: name the question the page answers, name the page it will link to, and name the page that will link back to it. If any of the three is missing, the piece is not ready, however good the draft reads. That single gate prevents more cannibalisation than any tool, and it costs a minute. If you already have a section trading places with itself in the results, show us the pages and the queries they keep swapping over.