Topic clusters: the complete guide

A topic cluster is a group of pages organized around one subject, with three parts: a pillar page that covers the whole topic broadly, a set of supporting pages — the spokes — that each cover one subtopic in real depth, and internal links that connect every spoke to the pillar and related spokes to each other. The shape this produces is hub-and-spoke: one central page surrounded by specialists, all visibly part of the same unit.

The plainest analogy is a textbook. The pillar is the chapter — it introduces every concept the topic contains and tells you where each one is treated fully. The spokes are the chapter's sections. And the internal links are the table of contents: the structural proof that the chapter is actually organized, not just a pile of pages that happen to mention the same words. Most websites, by contrast, are organized like a diary — a reverse-chronological blog where a post about payroll costs from 2023 has no structural relationship to the payroll compliance post from last month. Both pages exist; nothing tells an engine, or a reader, that they belong together.

That is the problem clusters solve. A blog is a timeline; a cluster is a structure. The individual pages may be identical in quality, but the cluster makes the relationship between them explicit and machine-readable — which, as the next two sections show, is exactly what modern search and AI retrieval systems are built to detect.

Search engines stopped ranking pages by keyword matching a long time ago. They interpret queries as intents, group thousands of phrasings under one intent, and evaluate not just whether a page answers it but whether the site behind the page is a credible source on the topic. That site-level evaluation is what practitioners call topical authority: demonstrated breadth and depth on a subject, which engines treat as evidence that you can be trusted for everything inside it. Clusters are the most direct way to build it, because they make breadth and depth visible at once — the pillar shows breadth, the spokes show depth, and the links show the two are connected.

Internal links are doing more work here than most teams realize. They are the site's own table of contents — the one signal where you tell the engine, in your own words, what each page is about and which pages belong together:

• Anchor text describes the destination. A link that says "how payroll taxes are calculated" tells the engine what the target page covers before it ever crawls it. Dozens of consistent anchors are a labeling system you fully control.
• Links pass authority. Spokes pointing at the pillar concentrate the cluster's accumulated strength on the page targeting the hardest query — the head term. This is the same mechanism as external links, applied internally and deliberately.
• Links create crawl paths. A clustered site gets every page discovered, recrawled, and refreshed faster, because everything is reachable within a click or two of the hub. Orphaned pages — no internal links pointing in — get crawled late and ranked reluctantly.

The other reason clusters work is humbler: one page cannot rank for everything. A topic like "payroll software" contains dozens of distinct intents — cost questions, comparison questions, how-to questions, compliance questions — and no single document can be the best answer to all of them. The cluster resolves this by giving every intent its own specialist page while letting each page borrow strength from its siblings. It is division of labor, applied to classic SEO.

Everything in the previous section was true five years ago. What changed is that AI search made cluster structure matter more, for three reasons that come straight from how these systems operate.

First: retrieval rewards complete coverage. When ChatGPT, Perplexity, or Google's AI Overviews ground an answer, they retrieve candidate passages — not pages — from sources they can find for the query at hand. A site with one long post on a topic offers retrieval a handful of candidate passages. A site with a pillar and twelve spokes offers dozens, each one already focused on the exact sub-question being asked. More focused candidates means more retrieval wins, and retrieval wins are what become citations. The mechanics of earning those citations have their own guide; the cluster is the content architecture underneath them.

Second: entity association. AI engines maintain an internal sense of which brands and domains are associated with which topics, built from everything they have crawled and been trained on. When a model decides who to mention for "payroll software for restaurants," that association strength is doing much of the deciding. Repeated, interlinked, consistent coverage of a topic is how a domain builds the association — a cluster ties your entity to the topic entity over and over, in crawlable form, with consistent terminology.

Third: a cluster is machine-readable proof of expertise. E-E-A-T is easy to claim and hard to demonstrate. An AI engine never reads your about page and takes your word for it — it observes what you have actually published. A complete cluster is the observation: here is the overview, here are the fourteen specific questions answered in depth, here is the structure connecting them. No isolated blog post, however brilliant, can produce that signal.

Three components, each with a distinct job:

• The pillar page targets the head term and covers the entire topic at survey depth. It is the page you want ranking for "payroll software" — broad enough to be the canonical entry point, structured enough to route every reader to the right spoke.
• The spokes each own exactly one subtopic or question — "how much does payroll software cost," "payroll software vs a bookkeeper," "how to run your first payroll." Each is the deepest page on your site about its sliver, and ideally the deepest on the web.
• The linking contract binds them: every spoke links up to the pillar with descriptive anchor text, the pillar links down to every spoke from the relevant section, and spokes link sideways to the siblings a reader would naturally need next. The contract is non-negotiable — a pillar and spokes without the links is not a cluster, just adjacent content.

The contract is worth stating as a rule because it is where clusters quietly fail. Teams write the pillar, write the spokes, and never go back to wire them together — or wire them once and let the structure decay as new content ships. Treat the links as part of the definition of done for every page in the cluster: a spoke is not published until the pillar links to it and it links back.

A cluster is a quarter-scale investment — a pillar plus six to twenty spokes, built and maintained. Choosing the topic is therefore the highest-leverage decision in the whole process, and the ordering of criteria matters: business value first, search demand second.

Business value first because the failure mode of demand-first selection is well known: a cluster on a high-volume topic adjacent to your business that ranks, attracts traffic, and converts nobody. The right starting question is not "what do people search for?" but "what topics, if we owned them, would produce customers?" — the problems your product solves, the category you sell in, the decisions your buyers make on the way to choosing you. For Aergos that calculus pointed at topics like topic clusters themselves; for a payroll company it points at payroll operations, not generic small-business advice.

Search demand second, as validation and as a sizing tool. Demand validation confirms people actually look for the topic in volume worth the build. Sizing tells you whether the topic is cluster-shaped at all:

• Too broad — "marketing" — is not a cluster, it is a whole site. You will never reach coverage, and the pillar has no realistic head term to win.
• Too narrow — a topic with two or three distinct intents — is a page or a short series, not a cluster. Forcing it into cluster shape produces thin spokes.
• Cluster-sized — supports one strong pillar and roughly six or more spokes with genuinely distinct intents. This is the test to apply before committing.

One more filter: pick clusters you have a right to win. Genuine expertise, original data, product proximity, or an existing foothold in the rankings all count. A cluster where you bring nothing the incumbents lack is a long, expensive way to come second.

With a topic chosen, the map comes from keyword research — but the unit of planning is the intent, not the keyword. Pull every query you can find around the head term: keyword tools, People Also Ask boxes, autocomplete, your own search console data, and the questions that come up in sales calls. The raw list will run to hundreds or thousands of strings. Then group them, and group by what the searcher is trying to accomplish rather than by string similarity — "payroll software pricing," "how much does payroll software cost," and "payroll service fees" are three strings and one intent.

The operating rule is one page per intent — not one page per keyword. The page-per-keyword era produced doorway sprawl: forty near-identical pages cannibalizing each other for one intent. The test for whether two keywords share a page is simple: would the ideal page for keyword A fully satisfy someone searching keyword B? If yes, same page. If no — the searcher needs something structurally different, a comparison instead of a definition, a tutorial instead of a price list — different page.

The output of this exercise is the cluster map: the pillar at the top, then a row per spoke with its intent, its primary query, the queries it absorbs, and its status — live, needs rework, or not yet written. The map is the source of truth for the whole build: it tells you what coverage means for this topic, which makes it the thing you measure against later. Keep it as a living document, because new intents appear — product launches, regulation changes, and new competitor categories all mint fresh questions.

This grouping work is exactly what Content Intelligence automates in Aergos: it maps your existing pages and keyword data into clusters, classifies intent, and surfaces the gaps — the intents on the map with no page to serve them.

The most common misreading of the model is treating the pillar as "a really long blog post." A pillar is a different kind of document with a different job: it covers the whole topic at survey depth and deliberately hands the reader off to spokes for the detail. A long post tries to be the destination; a pillar is the destination and the directory.

The properties that make a pillar work:

1. Complete coverage, controlled depth. Every subtopic on the cluster map appears as a section. Each section gives the reader a genuinely useful summary — answer-first, self-contained — and then links to the spoke for the full treatment. The pillar should satisfy a reader who wants orientation and route a reader who wants depth.
2. Every section maps to a spoke. This is the structural discipline that separates a pillar from an essay. If a section has no spoke, that is either a gap on the map or a section that does not belong. The pillar's outline and the cluster map should be the same document viewed two ways.
3. An evergreen URL, updated forever. The pillar lives at a stable, dateless address — /payroll-software-guide, not /blog/2026/06/payroll-post — and gets revised in place as the topic moves. Authority accrues to URLs; replacing the pillar every year forfeits the accrual.
4. It targets the head term. The pillar competes for the hardest, broadest query in the cluster — the one no spoke could win alone, and the one the entire linking structure exists to support.

Length follows from coverage rather than the other way around. Most real pillars land long because real topics contain a lot — but an 8,000-word page that exhausts every subtopic inline has stopped being a pillar and started competing with its own spokes, which is one of the failure modes covered below.

A spoke earns its place in the cluster by passing three tests. It owns a distinct intent — one question or subtopic no sibling already covers. It serves real demand — search volume, or the kind of sales-conversation recurrence that never shows up in keyword tools but converts better than anything that does. And it adds something — your experience, your data, your sharper answer — rather than restating what the top results already say. A page that fails any of the three is filler, and filler is not neutral: thin spokes drag down the engine's assessment of the whole cluster they are linked into.

In practice spokes take a handful of recurring shapes, and matching the shape to the intent is most of the craft:

• How-to spokes for task intents — numbered steps, one task, done completely.
• Comparison spokes for decision intents — honest trade-offs, a real recommendation, a table an engine can lift.
• Cost and pricing spokes for the questions buyers ask first and vendors answer last.
• Definition and glossary spokes for the topic's terminology — short, structured term pages that answer "what is X" cleanly. These are underrated cluster assets: they win definitional queries, they give every other page in the cluster something precise to link to, and they are exactly what Aergos's Glossary Management builds — structured term pages designed to slot into and support a cluster.

Write each spoke as if it is the only page of yours the reader will ever see — because in AI search, where engines lift one passage from one page, it often is. The spoke's obligation to the cluster is structural (the links, the consistent terminology); its obligation to the reader is to be the best answer on its sliver, full stop.

The links are what turn a folder of related pages into a cluster, so they deserve mechanics, not vibes. The contract has three clauses:

1. Pillar → every spoke. Each section of the pillar links to its spoke, in-body, from the sentence where the hand-off naturally happens. If a spoke exists that the pillar does not link to, the pillar is out of date.
2. Every spoke → pillar. Each spoke links up to the pillar early — typically in the opening section, where the spoke situates its narrow question inside the broader topic. This is the clause that concentrates authority on the head-term page.
3. Spoke ↔ spoke, where a reader would actually go next. The cost spoke links to the comparison spoke; the how-to links to the prerequisite how-to. Sideways links follow reader logic, not a quota — but every spoke should have at least a couple in and a couple out.

Anchor text discipline is the part most teams get wrong in one of two directions. "Click here" and "read more" anchors waste the labeling signal entirely. The opposite failure — the identical exact-match anchor repeated on every link to a page — reads as mechanical to engines and humans alike. The discipline: anchors are descriptive, contain the topic's natural language, and vary the way a careful human writer would vary them. "How payroll taxes are calculated," "calculating payroll tax," and "the payroll tax calculation walkthrough" all label the same destination honestly.

Placement matters too. In-body links — inside sentences, surrounded by relevant context — carry more weight than the same links in a footer, sidebar, or auto-generated "related posts" widget. Boilerplate link blocks are better than nothing, but they are not a substitute for editorial links placed where the connection is actually made.

And the standing rule: no orphans. Every page enters the cluster with links in and links out on day one. The practical fix is workflow, not heroics — publishing a spoke includes, as part of the same task, adding the pillar link to it, adding its link to the pillar, and linking it from two siblings. Orphan prevention at publish time costs minutes; orphan cleanup at audit time costs a project.

Most teams do not start from zero — they start from years of accumulated blog posts with no structure. That is good news: retrofitting existing content into clusters is usually the fastest win available, because the expensive part (the content) exists and the missing part (the structure) is cheap by comparison. The playbook runs in five steps:

1. Inventory. Crawl the site and export every indexable page with its title, the queries it ranks for, its traffic, and its internal links in and out. This is the raw material; decisions made without it are guesses.
2. Group. Assign every page to a topic and an intent within it. Pages will sort into three piles: pages that clearly belong to a cluster, pages that belong to no topic you care about, and clumps of pages that all chase the same intent. The second and third piles drive the next two steps.
3. Prune. Pages with no traffic, no links, no rankings, and no strategic purpose are dead weight — they spend crawl attention and dilute the site's topical profile. Remove them, redirecting anything with even residual link value to the nearest relevant survivor.
4. Merge. Where three weak pages target one intent — the classic symptom of years of page-per-keyword publishing — consolidate them into one strong page and 301-redirect the losers to it. One page per intent applies retroactively, and merging is how cannibalization actually gets fixed.
5. Relink. Designate or write the pillar for each cluster, then apply the linking contract across everything that survived: pillar to every spoke, every spoke to the pillar, siblings to each other, with disciplined anchors. This step is where the retrofit pays out — the same pages, suddenly legible as a cluster.

In our experience the inventory-and-group steps surprise people most: established sites typically discover they already own two or three nearly complete clusters, missing only a pillar and the links — and a long tail of pages that belong to nothing. The retrofit converts the first into assets and the second into a prune list, and both moves help.

Clusters are built page by page but succeed or fail as a unit, so they have to be measured as a unit. Three families of metric cover it:

• Coverage — of the intents on the cluster map, what share have a live page serving them? Gaps are the highest-signal finding cluster measurement produces, because each one is a specific, ready-to-brief piece of work.
• Internal-link completeness — what share of the linking contract is actually implemented? Spokes missing pillar links, pillar sections missing spoke links, orphaned pages, and redirect chains where direct links used to be. This number decays constantly as content ships, which is why it needs monitoring rather than a one-time audit.
• Cluster-level performance — rankings across the cluster's whole query set, and AI citations for the cluster's questions, tracked as a group. Per-page numbers hide the story; the question that matters is whether the topic, as a topic, is trending toward owned.

This is the layer Aergos was built to operate. The Topic Clusters module organizes your pages into hub-and-spoke clusters and scores each cluster's health, identifies the missing pillars and supporting pages, fixes the internal links, and recommends the next move — so the cluster map stops being a spreadsheet someone updates quarterly and becomes a live system. Rank tracking and AI citation tracking run against the same clusters, which closes the loop: structure, gaps, links, and outcomes in one view, on flat pricing.

Whatever tooling you use, put the review on a cadence. Coverage drifts as the topic grows, link completeness drifts as content ships, and performance drifts as competitors build their own clusters. A monthly cluster review — gaps, links, trend — is enough to keep the structure honest.

Four failure modes account for most broken clusters we see:

• Thin spokes. Pages written to fill out the map rather than to answer the question — 400 words of restatement with a keyword in the H1. They do not rank, they do not get cited, and they actively dilute the cluster's quality profile. The fix is the earn-their-place test: if a spoke has nothing to add yet, leave the gap visible on the map instead of papering over it.
• Competing pages. Two or more pages targeting the same intent — usually the residue of page-per-keyword publishing. The engine has to choose between them, often alternates, and frequently settles on neither. Detection is straightforward (two URLs trading rankings for one query set); the cure is the merge step from the retrofit playbook.
• Pillar cannibalization. The boundary between pillar and spokes erodes from either side. A pillar that exhausts every subtopic inline starts outranking its own spokes for their long-tail queries while losing focus on the head term; a spoke that sprawls past its intent starts contesting the pillar's. The fix is editorial discipline at the boundary: survey depth in the pillar, full depth in the spoke, and a hand-off link where one ends and the other begins.
• Link rot. The cluster was wired correctly once — then six months of publishing, a few URL changes, and a site migration later, the pillar does not link to the four newest spokes, two anchors point through redirect chains, and an orphan has appeared. Structure is not a deliverable; it is a state you maintain. This is the strongest argument for monitoring link completeness continuously instead of auditing it annually.

The common thread: every one of these is a maintenance failure more than a knowledge failure. Teams know what a healthy cluster looks like — what breaks is keeping it true while shipping. Build the checks into the publishing workflow and the failure modes mostly disappear.