Most explanations of content clusters use diagrams of imaginary sites. This one uses a real site — this one. ArticlesRanker is built as four hub-and-spoke clusters, and this article maps them exactly, so you can inspect a working structure instead of imagining one. It is part of the pillar guide how to write articles that rank, which is itself the hub of the cluster you are in.
- A cluster is one hub page covering a topic broadly, plus spoke articles that each answer one specific question, with links running both ways.
- This article maps a live example — ArticlesRanker's own four clusters, exactly as published — so you can inspect a working structure instead of imagining one.
- The two-way rule is the load-bearing part: the hub links to every spoke, and every spoke links back to its hub and its siblings.
- Start small: one hub and a handful of spokes, built complete, beats a grand map left half-finished.
The model in one paragraph
A cluster covers one major subject. At its centre sits a hub (pillar) page: a broad, authoritative overview that also acts as the subject's index. Around it sit spoke articles: narrow pages, each answering one specific question or targeting one long-tail query in full. The linking is two-way and deliberate: the hub links out to every spoke; every spoke links back to the hub and sideways to two or three siblings. Nothing in the cluster is more than one click from the hub, and the hub is one click from the homepage navigation.
This site's real cluster map
Cluster 1 — Why articles don't rank
Hub: Why your articles aren't ranking on Google. Spokes: article not indexed, thin content, wrong search intent, no internal links, keyword cannibalization. The hub's job is diagnosis and triage; each spoke is the deep fix for one cause.
Cluster 2 — Writing articles that rank
Hub: How to write articles that rank. Spokes: topical authority, this article (clusters), search intent matching, writing introductions, refreshing old articles. The hub presents the system; the spokes teach each step.
Cluster 3 — SEO checklists
Hub: SEO checklists for articles. Spokes: pre-publish, on-page, content refresh, internal linking checklists. Note the deliberate cross-cluster linking: the writing hub's refresh spoke points here for its operational checklist, because that is where a reader needs it — clusters are organised for readers first, diagrams second.
Cluster 4 — Tool reviews
Hub: SEO tool reviews and comparisons. Spokes: Surfer SEO review, SE Ranking review, free alternatives to Surfer, Surfer vs SEOWriting. Reviews get their own cluster so commercial content never muddies the teaching clusters' intent.
The linking rules, as applied here
- Hub → spokes: every hub contains a structured "In this guide" section linking to 100% of its spokes, plus in-text links where the hub summarises each spoke's topic.
- Spoke → hub: every spoke carries a breadcrumb (Home › Hub › Article), an in-text link to its hub in the introduction, and a "Part of" block near the end — three separate paths back, because readers land mid-cluster from Google, not at the front door.
- Spoke ↔ spoke: each spoke links to two or three siblings where the subjects genuinely touch (the indexing spoke links to the internal-links spoke because orphans cause indexing delays — a real dependency, not a quota fill).
- Depth: every page on the site is reachable within three clicks of the homepage: Home → hub → spoke.
Why the two-way rule matters
A hub that links out but receives no links back is just a sitemap. The return links are what concentrate the cluster's signals on the pillar page, making the hub the strongest candidate for the broad, competitive head query — while spokes, each tightly focused, pick off the long-tail queries the hub could never target specifically. One-way structures leak that value; two-way structures compound it. This is also why the anti-pattern in no internal links is so damaging: an unlinked article is a cluster of one.
Building your first cluster
- Pick one subject your audience cares about and you can cover completely.
- Write the hub outline first: the overview, the subtopics, nothing more.
- Turn each subtopic that deserves depth into a spoke brief with its own specific query.
- Publish hub + first spokes together if you can, with all two-way links in place; add remaining spokes over following weeks, updating the hub each time.
- Audit quarterly: every spoke linked from the hub? Every spoke linking back? Any orphans born from template changes?
Sources (5)
The cluster (pillar/cluster) model was popularised by HubSpot's research and writing on topic clusters (blog.hubspot.com/marketing/topic-clusters); Google's site-structure documentation (developers.google.com/search/docs) covers the underlying crawling and linking principles.
- Google Search Central — Link best practices for Google
- Google Search Central — What is a sitemap
- Google Search Central — SEO Starter Guide
- Google Search Central — Creating helpful, reliable, people-first content
- Google Search Central — How to specify a canonical URL
Failure modes we designed against
Three decay patterns kill clusters in the wild, and this site's rules were written against each. Hub drift: new spokes get published but the hub is never updated, so the "index" silently omits a third of the cluster — countered by a house rule (and a checklist item) that the hub is edited in the same sitting as any spoke publishes. Spoke orphans: a spoke template change drops its "Part of" block, breaking the return path — countered by auditing the cluster quarterly against the map printed above. Cluster sprawl: spokes multiply until the hub is a link farm and intents begin colliding — countered by capping clusters at the size of one genuinely coverable subject, and starting a new hub rather than bloating an old one. If you adopt the model, adopt the maintenance rules with it; structure is a practice, not an event.
Cluster size and the depth rule
A practical governor for cluster growth: a spoke earns its place only if its target question cannot be answered completely inside the hub without bloating it. If the hub can absorb the answer in a paragraph, it should — not every sub-question deserves a URL, and clusters padded with paragraph-sized spokes manufacture exactly the thin pages our diagnosis pillar warns about. Conversely, when a hub section keeps growing across refreshes because the subtopic has real depth and its own search demand, that is the signal to promote it into a spoke and leave a summary plus a link behind. Clusters breathe in both directions when they are run well.
Your turn: sketch a cluster in ten minutes
Take the subject you know best. Write its head query at the top of a page. Beneath it, list the five to eight specific questions your readers actually ask — not topics, questions. You have just sketched a hub and its spokes. Everything else in this article is execution detail.
Frequently asked questions
How many spokes should a cluster have?
Enough to cover the subject's real sub-questions — commonly 4–10 for a focused topic. Five genuine spokes beat fifteen padded ones; you can always add more as real questions emerge.
Can an article belong to two clusters?
It can link to both, but give it one primary home (one breadcrumb, one 'Part of' hub) to keep intent and linking signals unambiguous.
Does the hub have to be the longest page?
Usually it is the broadest, not necessarily the longest word-for-word. Its job is complete overview plus navigation; depth lives in the spokes.
What if my CMS makes this linking tedious?
The structure is CMS-agnostic: it is just disciplined linking. A simple rule — 'no article publishes until its hub link, return link, and two sibling links exist' — prevents almost all decay. Our pre-publish checklist includes it.
Can clusters work on a brand-new site?
Yes — arguably best there, because you build the architecture before bad habits form. Expect the ranking payoff to lag the build by some months while pages mature.
Sketch your first cluster in ten minutes — one hub, the real questions around it, the links between them — then build it in that order. You are looking at a working example; copy the structure, not the topics.
What is the first hub-and-spoke cluster you will build, and which spoke comes first?
