Topic Clusters: How to Build Them Properly

A topic cluster is a group of pages that covers one subject completely: a broad hub (pillar) page in the center, focused spoke pages around it, and internal links wiring them into a single unit. The content is only half the model; the links are what turn a folder of related articles into a cluster search engines can recognize. Most "failed" cluster strategies produced perfectly good content and simply never built the links.

The hub-and-spoke model

The architecture has three parts:

• The hub (pillar page). One page that covers the whole topic broadly: every major subtopic addressed, none exhausted. It targets the head term ("email marketing") and serves visitors who need orientation before depth.
• The spokes (cluster pages). Focused pages that each exhaust one subtopic ("email subject line testing," "SPF and DKIM setup"). Each targets its own long-tail queries and serves visitors who know exactly what they need.
• The links. Every spoke links up to the hub; the hub links out to every spoke; spokes link selectively to sibling spokes where genuine overlap exists.

The model works because it matches both how people search and how search engines evaluate sites. Searchers arrive at different depths of need, and the structure routes them: hub for orientation, spokes for answers, links for movement between the two. Search engines, meanwhile, read the dense in-text linking within the group (and the anchor text on those links) as evidence that the site covers the topic as a connected whole rather than as scattered posts. That's the mechanism behind topical authority: coverage plus coherence, and internal links are how the coherence becomes visible.

One clarification worth making early: a cluster is defined by links, not by URLs. Putting twenty posts under /email-marketing/ creates a folder. Only the links create a cluster.

Choosing cluster topics

A good cluster topic passes three tests:

1. It's genuinely broad enough to need a cluster. The head term should decompose into at least 6–8 subtopics that each merit their own page. If you can cover everything worth saying in 2,500 words, that's one great article, not a cluster; forcing thin spokes around it creates pages with no reason to exist.
2. It's narrow enough to finish. "Marketing" is not a cluster topic; it's a category with dozens of clusters inside it. Pick the level where a complete treatment is 10–30 pages, achievable within a quarter or two. Incomplete clusters are just blogs.
3. Your business has standing on it. Clusters are expensive. Build them on topics where ranking produces customers and where you can say things competitors can't.

The practical method: take a candidate head term, list every question and subtopic beneath it (keyword research, competitor tables of contents, sales call questions), and group that list into pages. Each group becomes a spoke; the head term becomes the hub. If the grouping produces fewer than a handful of substantial spokes, the topic is too narrow. If it produces fifty, split it into multiple clusters.

The linking rules that make clusters work

This is the section that separates working clusters from decorative ones. Three rules, in priority order:

Rule 1: Every spoke links to the hub

Each cluster page links up to the pillar exactly once, from within the prose, with a descriptive anchor close to the hub's target topic. This is the highest-value link in the model: it concentrates the cluster's collective relevance onto the one page targeting the head term, and it gives every deep-reading visitor a path to the broader context.

The anchor matters. "Read our complete guide to email marketing" passes topical meaning. "Click here for more" passes nothing. Anchor guidance is covered in depth in the pillar guide to internal linking, but the short version is: the anchor should describe the destination, and it shouldn't be the identical exact-match phrase on all twenty spokes.

Rule 2: The hub links to every spoke

The pillar links out to each cluster page from the relevant section of its own prose: when the hub's overview of deliverability reaches its natural limit, that's where the link to the deliverability spoke belongs. In-text placement is the point: a "related articles" widget at the bottom of the pillar is boilerplate, not endorsement. If a spoke can't earn a contextual link from the hub, that's usually a sign the hub is missing a section or the spoke is off-topic.

Rule 3: Spokes link to sibling spokes, selectively

Spoke-to-spoke links are valuable and the most commonly mishandled. Two failure modes: linking every spoke to every other spoke (a mesh of forced, low-relevance links that dilutes the structure), and linking none of them (leaving readers and crawlers with the hub as the only path). The right standard is editorial: link sibling spokes where one genuinely continues the other: the subject-lines page naturally references the A/B-testing page. Typically that yields two to four sibling links per spoke, each with a descriptive anchor, each at the point in the text where the reference is natural.

The common failure: writing the content, forgetting the links

Here's how clusters actually fail in practice. A team plans the cluster, briefs the writers, publishes fifteen strong spokes over four months, and every spoke goes live with links to whatever old posts the writer happened to remember, while posts published in month one never get updated to link to posts from month four. The result: a completed content plan and a cluster that exists only in the planning spreadsheet.

The cause is structural, not laziness. Content creation is a forward-only pipeline (draft, publish, next), while cluster linking is inherently retroactive: every new spoke should trigger edits to previously published pages. No editorial workflow naturally includes "reopen six old posts," so it doesn't happen.

Fixes, in ascending order of reliability:

• Add linking to the definition of done. A spoke isn't published until it links to the hub and until at least two existing pages link to it. This works while someone enforces it.
• Schedule a recurring cluster audit. Quarterly, map each cluster's actual in-text links against the model. This catches drift but scales poorly past a few clusters.
• Automate the retroactive half. This is the part tooling genuinely solves. An internal linking tool that crawls your site on a schedule, clusters pages by topical similarity, and proposes links (with anchors taken from sentences you already published) turns "reopen six old posts" from a forgotten chore into a review queue. New spokes get inbound links from month-one posts automatically proposed; you approve or reject. The judgment stays yours; the remembering becomes software's.

Order of operations for a new cluster

If you're starting a cluster from zero, sequence matters less than completeness, but this order avoids rework:

1. Map the full cluster first (hub plus every planned spoke) before writing anything. The map is the topical strategy; see the process for building pillar pages for how the hub's outline doubles as the cluster plan.
2. Publish the hub early, even in a leaner version. Spokes need something to link up to from day one; you can deepen the pillar as spokes teach you what belongs in it.
3. Publish spokes with their hub link included; never retrofit rule 1.
4. After each spoke ships, add the hub→spoke link and 1–3 inbound links from existing relevant pages; this is the retroactive step to systematize.
5. Revisit the hub quarterly to make sure its prose actually references every live spoke.

The bottom line

Topic clusters are an internal linking architecture wearing a content-strategy costume. The hub-and-spoke content plan tells you what to write; the three linking rules (every spoke to the hub, the hub to every spoke, siblings selectively) are what make the cluster real to readers and search engines. Plan the whole cluster before writing, build the links as a non-negotiable part of publishing, and put a system (human checklist or automated review queue) behind the retroactive links, because those are the ones every team forgets.