A blog with three hundred posts and no structure is not an asset. It is three hundred pages that each rely on their own merit, with nothing passing between them. A topic cluster is the opposite design: a small number of subjects, each covered completely by a group of pages that reinforce one another, so that every new page makes the existing ones stronger. It is the clearest example I know of SEO that compounds.
This sub-guide is part of the content SEO guide. It assumes you have done the research and mapping described in keyword mapping, and it feeds directly into topical authority, which is what clusters are ultimately for.
Hub and spoke
The structure has two kinds of page. The hub, sometimes called the pillar, is a comprehensive page on the broad topic. It introduces every important sub-topic, answers the broad query, and links out to each spoke. The spokes are focused pages that each cover one sub-topic in depth and link back to the hub and, where relevant, to each other.
- Hub: the broad topic
- Spokes: one sub-topic each
- Links: hub to every spoke, every spoke to hub
- Authority: the set outranks any single page
This site is built on the pattern. The technical SEO guide is a hub; Core Web Vitals, canonical tags and JavaScript SEO are spokes. The hub targets the broad query; each spoke targets its own cluster of specific queries. Together they tell Google that the site covers the subject, not just a slice of it.
Why it works
Three mechanisms. Internal links pass signal, so a hub linked from every spoke accumulates the strength of the set. Coverage signals expertise: a site that answers forty questions about a topic is more credibly an authority than one that answers two. And matching page to intent is easier when each page has one job, which the search intent sub-guide explains. The semantic SEO guide covers the entity side of the same idea.
Drawing the boundaries
The hardest decision is where one cluster ends and the next begins. Too broad and the hub becomes a vague overview nobody searches for; too narrow and you have a hub with two spokes and no depth.
I use three tests. First, demand: there should be a real broad query for the hub and real specific queries for each spoke, verified in the SERP. "Term insurance" is a hub-sized topic; "term insurance for smokers" is a spoke; "term insurance for smokers in Pune aged 34" is not a page. Second, coherence: a person interested in the hub topic would plausibly want most of the spokes. Third, ownership: the site has, or can honestly build, the expertise to cover the whole cluster. A cluster you can only half-cover is a cluster you should not start.
Where two clusters overlap, pick the parent. "GST for freelancers" could sit under a GST cluster or a freelancing cluster. The right answer is whichever hub the business wants to be known for; the other hub links across to it rather than duplicating.
Sizing a cluster
There is no correct number of spokes. The size is set by the topic, not by a target. The questions I ask are: how many distinct sub-intents does the SERP show for this topic? How many does the business need to cover to be credible? How many can be produced at the required depth in a sensible time?
| Cluster size | Typical topic | When it is right | Risk |
|---|---|---|---|
| Hub plus 4 to 6 spokes | A product feature area, a narrow service, a local niche | Small team, clear scope, need to prove the model before scaling | Too small to be seen as authoritative on a competitive subject |
| Hub plus 8 to 15 spokes | A service category, a buying decision, a regulatory process | Most B2B and SaaS clusters; enough depth to own the topic | Needs sequencing or it ships half-finished for months |
| Hub, sub-hubs, 20 or more spokes | A whole discipline, a product category with many types | Publishers, large e-commerce, sites whose core business is the topic | Sub-hubs must be real topics, not a filing system |
When a cluster wants to grow past about fifteen spokes, I split it with sub-hubs rather than letting one hub carry forty links to pages a reader cannot navigate. Each sub-hub is itself a hub-sized query, which is the test for whether the split is legitimate.
Internal linking rules inside a cluster
The links are the cluster. Without them you have a folder of related posts. These are the rules I apply, and the internal linking framework extends them to the whole site.
- The hub links to every spoke, in context, with descriptive anchor text, not a bare list at the bottom.
- Every spoke links back to the hub in its first or second paragraph, as this page does.
- Spokes link to sibling spokes where the content genuinely references them, and not otherwise. Forced sibling links dilute the ones that matter.
- Anchor text describes the destination's topic, varied naturally, never the same exact phrase every time.
- Spokes do not link out to other clusters' spokes casually; cross-cluster links go hub to hub, or spoke to the other cluster's hub, so the boundaries stay legible to a crawler.
- Every spoke is reachable from the hub in one click and from the homepage in three or fewer. Orphaned spokes are the most common way a cluster quietly fails, which the orphan pages experiment measured.
Sequencing publication
Clusters are rarely published in one release. The order matters because the cluster starts earning signal from the first page.
Publish the hub first, even if it is incomplete
A hub that introduces every planned spoke, with the unpublished ones as plain text rather than links, establishes the topic and gives spokes somewhere to link to from day one. Update it as spokes go live.
Ship the spokes with the clearest demand next
Pick the three or four sub-topics with the most obvious queries and the weakest competition. These earn impressions early and validate the cluster.
Fill the spokes that make the set credible
Some spokes will never drive much traffic but are necessary for completeness. They go in the middle of the sequence, not the end, or they never get written.
Finish, then revise the hub
Once all spokes exist, rewrite the hub with the benefit of what was learned. The first version was a plan; the last version is the summary of a finished body of work.
Measuring cluster performance
Measure the cluster, not only the pages. A single spoke's traffic says little; the trajectory of the set says a lot. In Search Console, filter the Performance report by the cluster's URL path and watch total impressions, the number of distinct queries the set appears for, and the average position of the hub's primary term over time. The number of queries is the earliest signal that Google is associating the site with the topic; it usually rises before clicks do.
Beyond search data, I track whether spokes are being discovered through the hub by looking at internal navigation paths in analytics, and whether the cluster is producing the business outcome it was built for: sign-ups, enquiries, assisted conversions. The topical authority cluster test documents the method on a live cluster.
Common mistakes
I see the same handful of mistakes undo otherwise sound clusters.
Choosing the hub topic by what the business wants to say rather than what people search for. Building spokes for queries that have no demand, which produces a complete cluster nobody visits. Treating the hub as a table of contents instead of a page that answers the broad query in its own right. Publishing spokes before the hub exists, so they are orphaned for months. Linking everything to everything, which turns the structure into noise. Writing the spokes at the same shallow depth as the hub, so the cluster has breadth without depth. And abandoning a cluster at sixty percent because the early spokes did not spike, when the compounding was two quarters away.
Frequently asked questions
How many pages does a topic cluster need?
As many as the topic has distinct sub-intents with real demand, which is usually somewhere between five and fifteen spokes around one hub. Beyond that, split into sub-hubs. The size is set by the SERP, not by a target.
Should the hub page target a keyword?
Yes, the broad topic query. A hub that is only a table of contents does not rank and does not deserve to. It should be the best single answer to the broad question, with the spokes as the detail.
Can I build a cluster from existing blog posts?
Often, and it is the fastest way to start. Map the existing posts to sub-topics, merge the ones that overlap, write a hub, add the links, and fill the gaps. The keyword mapping sub-guide covers the merge decisions.
How long before a topic cluster shows results?
Early spokes often earn long-tail impressions within weeks of indexing. The hub's position on the broad term and the cluster's overall authority typically take months to build, and the compounding effect is clearest after the cluster is complete.
Do topic clusters work for e-commerce and SaaS sites?
Yes, with different page types. An e-commerce cluster might be a category page as the hub with buying guides and sub-categories as spokes. A SaaS cluster is often a solution or feature hub with use-case, comparison and how-to spokes. The SaaS SEO guide and e-commerce SEO guide cover each.
Where this connects
This sub-guide belongs to the content SEO guide, and clusters are the unit of work in my topical authority framework. The topical authority cluster test measures a cluster built with these rules, and the technical SEO and content architecture case study shows a site restructured from a flat blog into clusters on a sound technical base. If you want the architecture designed and the clusters built, that is what my content SEO service is for.