How to turn a list of keywords into a connected set of pages where everyone has a job, using search intent and the buyer’s journey as the organizing logic.
Most keyword research ends one step too early.
You do the work properly: you understand the job your buyer is trying to get done, you translate it into real search language, you end up with a list of queries that genuinely reflect how people search. And then the list sits there, because a list isn’t a plan. Nothing tells you which query deserves its own page, which ones belong together, and which are just variations of something you’ve already covered.
That gap is where topic clusters come in. A cluster turns a pile of related queries into a structured set of connected pages, each serving a specific intent, all linked so that search engines and AI systems can see the depth behind them.
This guide picks up exactly where keyword discovery leaves off.
Where this sits
Keyword and intent discovery is the Decode phase: understanding who searches and what they ask. This article is the Architect phase: turning that understanding into structure. Both are part of the SEO-nergy methodology, the four-part system that aligns search behavior, website architecture, content strategy, and AI search readiness.
What is a topic cluster?
A topic cluster is a group of interlinked pages covering one subject completely: a pillar page that covers the territory broadly, cluster pages that go deep on its parts, and internal links tying them together. The structure is what turns individual pages into demonstrated expertise.
The three layers each do a distinct job:
The pillar page covers the whole topic at a level that satisfies someone arriving with the broad question. It doesn’t try to say everything; it maps the territory and links out to the pages that go deeper. One pillar per topic.
Cluster pages each take one sub-question and answer it properly. Each targets a distinct intent, and each links back to the pillar. This is where most of your specific, long-tail visibility comes from.
Supporting pages carry proof and conversion: case studies, comparison pages, service pages, pricing. They’re part of the cluster because your buyers reach them from the same journey, even though they’re not educational content.
The internal links are not decoration. They’re the mechanism. A pillar that doesn’t link to its clusters, and clusters that don’t link back, is just a collection of pages that happen to share a subject. The connections are what let a crawler or an AI system encountering one page see the surrounding depth.
A note on naming
“Topic cluster” is the industry term for this pillar-cluster-supporting model, and it’s what people search for. In the SEO-nergy toolkit, the working document where you build and map these is called the Topic Constellation. Same structure, different label: one is the concept, one is the worksheet.
Why clusters matter more now than they used to
Clusters were always good practice for SEO. For AI search they’ve become close to essential, because retrieval systems assess whether your site genuinely covers a subject. A single strong page proves you can write. A complete cluster proves you know the field.
There’s a practical consequence that favors smaller businesses. Research on 2026 citation behavior indicates that a site covering one subject exhaustively can outcompete a much larger general publication for citations in that niche. You don’t have to out-rank a major publisher across everything. You have to be the most complete source on the specific thing you do.
There’s a second mechanic worth understanding. When someone asks an AI assistant a question, the system typically breaks that question into several sub-queries and searches each one. Being cited means being the best available answer to that cluster of sub-questions, not just the headline topic. A well-built cluster is, almost by definition, a set of pages that answers those sub-questions individually.
Start from the job, not the keyword list
Build clusters from the job your buyer is trying to get done, because the job is what holds the queries together. Keywords grouped by surface similarity produce clusters that look tidy and serve nobody in particular.
A job statement follows a simple structure: when I’m in this situation, I, as a type of user, want to do this thing, so I can get this outcome. For example:
Example job statement
“When I’m planning a website redesign, I want to make sure SEO is built in from the start, so I don’t lose traffic or rankings and ideally increase visibility in search and AI systems.”
That single sentence generates an entire cluster. The situation tells you what triggers the search. The desired outcome tells you what the content has to deliver. And the fear underneath it, losing traffic, tells you which objections your pages need to handle. The reason this matters structurally: the job stays constant while the language evolves as your buyer moves through their journey. Someone in that redesign situation starts by asking what could go wrong, then compares approaches, then looks for someone to help. Three very different queries, one continuous job. Group by job and those queries stay connected. Group by keyword similarity and they scatter.
Map the queries to the five intent types
Expand each job into the five intent types, because each one calls for a different kind of page. This is the step that determines your cluster’s actual shape.
The job stays the same. Only the language evolves.
The five types, and what each one needs from you:
Two practical rules come out of this mapping.
First, a healthy cluster spans several intent types. If every page in your cluster is informational, you’ve built a library with no path to a decision. If everything is transactional, you have nothing that reaches people before they’re ready to buy. Most complete clusters cover three or four of the five.
Second, format follows intent. This matters more than most people realize, because format mismatch loses visibility regardless of writing quality. Query intent predicts which format gets cited better than industry or topic does: articles lead for informational queries, listicles dominate commercial and comparison queries, and product or service pages win transactional ones. Writing a long explainer to win a “best tools for X” query loses to a listicle every time.
Align the cluster to the search journey
Map each page to a stage of the buyer’s search journey, so the cluster moves people forward rather than just informing them. Intent tells you what a page must answer; journey stage tells you where it sits in the sequence.
For B2B, three stages cover most situations:
- Information search and exploration. The buyer is problem-aware and solution-uncertain. They’re framing the problem, not shopping. Your pillar and most cluster articles live here.
- Consideration, comparison and evaluation. They understand the problem and are weighing options and providers. Comparison pages, “who this is for / not for” sections, and proof content live here.
- Decision. They’ve chosen an approach and want to act. Service pages, pricing, and contact pages live here.
Tagging pages by stage exposes a gap most B2B sites share: plenty of decision-stage pages, thin coverage of the exploration stage where buyers actually build their shortlist. If your cluster has a pillar and four service pages and nothing in between, that’s the gap.
The build order
Work in a fixed sequence so no page exists without a question behind it. The order below is what keeps a cluster from becoming a wish list.
Five steps, and no page exists without a question behind it.
- Write the job statement for one persona in one situation. One job at a time; you’ll repeat this for each major situation you serve.
- Expand the job into the five intent types. Write the actual queries and conversational prompts someone would use at each stage, in their words rather than your product vocabulary.
- Group the queries by the question they answer, not by keyword similarity. “How much does X cost” and “is X worth it” look different and belong together, because they’re the same underlying concern.
- Assign each group a page type: pillar, cluster, or supporting. If a group is too small to sustain a page, it becomes a section within one. If a group is large enough that it needs its own sub-questions, it may deserve its own pillar.
- Link every cluster to its pillar and the pillar back to each cluster. Use descriptive anchor text that names the destination topic. This step is the one most often skipped, and it’s what makes the structure legible.
How many pages should a cluster have?
There’s no fixed number: a cluster is complete when it has no obvious gaps for the job it serves, not when it hits a page count. The useful test is a question, not a quota.
Ask: if someone with this job read only my cluster, is there a question they’d still have to go elsewhere to answer? Every yes is a gap. Every gap is a place a competitor gets cited instead of you. In practice, most B2B clusters land somewhere between five and twelve pages: one pillar, several cluster articles covering the main sub-questions, and a few supporting pages carrying proof and conversion. Complex topics run larger. But depth on one job beats shallow coverage of five, especially for smaller sites where topical authority is the realistic path to visibility.
Two failure modes to watch for
Clusters fail in two predictable ways, and both are visible before you publish. Checking for them at the mapping stage is far cheaper than discovering them in a content audit later.
Cannibalization: two or more pages chasing the same intent. This splits your signals and leaves search engines to guess which page is the right answer. If two ideas in your map serve the same question, merge them. One page, one purpose.
Orphaned depth: good cluster pages with no links from the pillar, or a pillar that links out but gets nothing back. The pages exist, but the structure doesn’t. This is the most common way a cluster ends up performing like a set of unrelated posts.
Both are caught by the same practice: map the whole cluster before you write any of it and mark the internal links as part of the map rather than deciding them page by page during production.
What to do with the clusters you already have
If you already have content, map it against your clusters before writing anything new. Most sites discover they have more coverage than they thought, distributed badly.
Lay your existing pages over the cluster you’ve just designed. Three things surface immediately: pages that fit and just need better linking, pages that overlap and should be merged into something stronger, and gaps where the cluster needs content that doesn’t exist yet.
That’s usually a better first move than publishing more, because consolidating thin overlapping pages into one dense resource removes self-competition and produces exactly the kind of comprehensive page models prefer to cite.
Frequently asked questions
What is a topic cluster in SEO? A topic cluster is a group of interlinked pages covering one subject completely: a pillar page covering the broad topic, cluster pages going deep on specific sub-questions, and supporting pages carrying proof and conversion. Internal links between them are what make it a cluster rather than a collection of separate pages.
How do you create a topic cluster? Start with the job your buyer is trying to get done, expand it into the five intent types (jobs-to-be-done, informational, comparative and evaluative, transactional, navigational and locational), group the resulting queries by the question they answer, assign each group a pillar, cluster, or supporting page, then link every cluster to its pillar and back.
How many pages should a topic cluster have? There’s no fixed number. A cluster is complete when someone with that job could read only your cluster and have no unanswered questions. Most B2B clusters land between five and twelve pages, but depth on one job beats shallow coverage of several.
What’s the difference between a pillar page and a cluster page? A pillar covers the whole topic broadly and links out to everything beneath it; there’s one per topic. A cluster page goes deep on a single sub-question and links back to the pillar; there are several per pillar. Pillars establish coverage, clusters prove it.
Do topic clusters help with AI search? Yes. AI systems assess whether a site genuinely covers a subject, and a complete cluster is the evidence. They also decompose questions into sub-queries and search each, so a cluster that answers those sub-questions individually is far more likely to be cited than a single broad page.How do I avoid keyword cannibalization in a cluster? Give every page one purpose and one primary intent, and check your map before writing: if two planned pages answer the same question, merge them. Cannibalization is easy to spot at the mapping stage and expensive to untangle after publication.
Want to see how your existing content maps to your buyers’ actual search journey, and where the gaps are? The Search Journey Alignment Audit maps what you have against what your buyers ask at each stage, which is the fastest way to find out whether your clusters are complete or just look that way.
