Most explanations of content clusters use diagrams of imaginary sites. This one uses a real site — this one. ArticlesRanker is built as four content clusters, and this article maps them exactly, so you can inspect a working structure instead of imagining one. It is part of the complete guide how to write articles that rank, which is itself the main guide of the cluster you are in.
- A cluster is one guide 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 main guide links to every spoke, and every spoke links back to its main guide and its siblings.
- Start small: one main guide 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 main guide 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 main guide links out to every spoke; every spoke links back to the main guide and sideways to two or three siblings. Nothing in the cluster is more than one click from the main guide, and the main guide is one click from the homepage navigation.
This site's real cluster map
Cluster 1 — Why articles don't rank
Main guide: Why your articles aren't ranking on Google. Spokes: article not indexed, thin content, wrong search intent, no internal links, keyword cannibalization. The main guide's job is diagnosis and triage; each spoke is the deep fix for one cause.
Cluster 2 — Writing articles that rank
Main guide: How to write articles that rank. Spokes: topical authority, this article (clusters), search intent matching, writing introductions, refreshing old articles. The main guide presents the system; the spokes teach each step.
Cluster 3 — SEO checklists
Main guide: SEO checklists for articles. Spokes: pre-publish, on-page, content refresh, internal linking checklists. Note the deliberate cross-cluster linking: the writing main guide'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
Main guide: 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
- Main guide → articles: every main guide contains a structured "In this guide" section linking to 100% of its spokes, plus in-text links where the main guide summarises each spoke's topic.
- Spoke → main guide: every spoke carries a breadcrumb (Home › Guide › Article), an in-text link to its main guide 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 → guide → article.
Why the two-way rule matters
A main guide that links out but receives no links back is just a sitemap. The return links are what concentrate the cluster's signals on the main guide page, making the main guide the strongest candidate for the broad, competitive head query — while spokes, each tightly focused, pick off the long-tail queries the main guide 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 main guide outline first: the overview, the subtopics, nothing more.
- Turn each subtopic that deserves depth into a spoke brief with its own specific query.
- Publish the main guide + first spokes together if you can, with all two-way links in place; add remaining spokes over following weeks, updating the main guide each time.
- Audit quarterly: every spoke linked from the main guide? Every spoke linking back? Any orphans born from template changes?
Sources (5)
The cluster (topic-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. Guide drift: new spokes get published but the main guide is never updated, so the "index" silently omits a third of the cluster — countered by a house rule (and a checklist item) that the main guide 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 main guide is a link farm and intents begin colliding — countered by capping clusters at the size of one genuinely coverable subject, and starting a new main guide 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 main guide without bloating it. If the main guide 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 guide warns about. Conversely, when a main guide 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 main guide and one of its articless. 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' block) to keep intent and linking signals unambiguous.
Does the main guide 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 link to the main guide, its 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 main guide, 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 content cluster you will build, and which spoke comes first?
