Ranking for a broad topic is not a one-page job. A single article can win one query, maybe three closely related ones, but the moment you look at the full query space around a subject — definitions, how-tos, comparisons, mistakes, costs, tooling — you are looking at dozens of distinct intents that no page can serve without becoming unreadable.
The standard answer is hub-and-spoke architecture: one pillar page, a set of supporting articles, and deliberate internal links binding them into a single unit. This guide covers how to choose the pillar, how to map subtopics from real query data instead of guesswork, the linking rules that hold a cluster together, how to tell a healthy cluster from cannibalization, and how to measure the whole thing at once rather than page by page.
What a topic cluster actually is
Three parts, one job each:
- The pillar — a page targeting the head query and giving the topic a single home. It explains the landscape and points readers to depth.
- The spokes — articles, each owning one sub-intent: a specific question, comparison, mistake, or task within the topic.
- The links — contextual internal links running up, down, and (selectively) across the set. The links are what make it a cluster rather than a folder.
The structure works because relevance accrues. A spoke that links up declares what it belongs to; a pillar that links down concentrates its authority on the pages it endorses. Get the wiring right and the set behaves like one strong asset instead of nine weak ones. The full logic of internal link weight and anchor choice is covered in the internal linking strategy guide.
Choosing a pillar: the query you cannot win with one article
A pillar is not your favorite topic and it is not your homepage. It is a specific URL you will maintain for years, aimed at a query whose results page makes it obvious that one article is not enough.
Run three tests before committing:
- The SERP test. Search the query. If the results mix a definition, a list, a tutorial, and a tool — four different intents fighting for one page — Google is telling you the topic needs multiple URLs.
- The cut test. Draft the outline you would need to fully answer the query. If you are already deciding which sections to leave out, the parts you cut are your spokes.
- The maintenance test. Can you keep this page accurate as the topic changes? A pillar that goes stale drags every spoke down with it.
One practical rule: a pillar should be a query you could plausibly own for a year, not a fad phrase. If you already publish on the subject, start from the page that already earns impressions and rebuild it into the pillar instead of starting a second one.
Mapping subtopics from real query data
Guessing the subtopics is how clusters end up with eleven pages nobody searches for. Pull the list from evidence:
- Your own Search Console query report. Queries you already show for are demand you have already proven. Group them by intent and see which ones have no dedicated page.
- Related questions and autocomplete. People Also Ask boxes and the dropdown suggestions are literally the sub-questions users type. Read them from a target-market location rather than your own, because the suggestions are localized.
- The top ten results for the head term. Note the recurring subheadings and page types. Those are the subtopics the market has agreed on.
- Questions your audience actually sends. Support tickets, sales calls, comments, and on-site search queries are data no keyword tool has.
Then group the raw keywords by intent, not by string similarity. Two keywords that return the same results page are one page; two keywords with different result types are two pages. Our keyword cluster generator does that grouping, and our free keyword research guide explains how to gather the raw list in the first place.
Keep it in a sheet with four columns: query, intent, existing URL, action (write, merge, or leave alone). That sheet is the cluster. Every decision after this point is just executing it.
The linking rules
Clusters fail on wiring more often than on content. Four rules cover almost everything:
- Every spoke links up to the pillar, early on the page, with an anchor that names the pillar's topic — "our guide to X" — not "back to the overview."
- The pillar links down to every spoke, in context, inside the section where that subtopic is mentioned. A pillar with a bare bullet list of links at the bottom wastes the placement.
- Siblings link laterally only where it helps. If a reader finishing one spoke genuinely needs the next, link it. A spoke with twelve sideways links and one up-link is miswired: relevance is leaking sideways instead of pooling in the pillar.
- Anchors describe the destination. Write descriptive anchors that name the destination — never the same exact phrase repeated across every spoke. The internal link audit confirms every spoke has at least one link in and one link out.
A cluster where no spoke receives a link from outside the cluster is an island. Pull at least one existing high-traffic page into the pillar so authority flows in from elsewhere on the site.
Clusters versus cannibalization
This is where most cluster projects go wrong, because a deliberate cluster can look exactly like a mess from the outside. The difference is not how many pages you have. It is what each page was built to do.
- A cluster is intentional division of labor. You decided the head query needs several pages, you assigned each page a distinct intent, and the pages link to each other. Google can tell which URL owns which query.
- Cannibalization is accidental competition. Two or more URLs chase the same intent because nobody assigned ownership — they swap positions, split clicks, and neither becomes the confident result.
The diagnostic question is blunt: for the query each page is supposed to own, is there more than one candidate URL on your site? If yes, you have cannibalization, not a cluster. Check it directly with the keyword cannibalization checker, and read how to find and fix keyword cannibalization for the difference between a genuine conflict and harmless long-tail overlap.
The fixes are different, which is why the distinction matters:
- Cluster problem: a spoke is missing, a link is missing, an anchor is vague. Add the page or the link.
- Cannibalization problem: two pages target the same intent. Merge them, 301 the weaker URL into the stronger one, or rewrite one onto a genuinely different intent — the cannibalization merger planner sequences that work.
Expect mild overlap in long-tail queries; that is normal and not a defect. The test is whether each page has a clear primary intent, not whether their keyword lists are perfectly disjoint.
When a cluster is complete
Not when you run out of ideas — when demand is saturated. Four signals:
- Every high-intent query in your mapping sheet has a URL that owns it.
- New queries arriving in Search Console for the topic map to pages you already have rather than to gaps.
- The pillar holds its position on the head query and spokes hold theirs on the sub-queries, without pages trading places week to week.
- New material in the topic can be added to an existing page instead of spawning a new one.
If the coverage check keeps returning subtopics you deliberately skipped, that is a decision, not a gap. Write it down so the next content pass does not reopen it.
Measuring cluster health
Per-page ranking reports hide cluster behavior. Two of your spokes can be climbing while the pillar collapses, and a page-by-page view will not tell you the unit is failing. Roll the metrics up by cluster instead:
- Indexation: every cluster URL is indexed and in your sitemap. A spoke that never gets indexed is dead weight — confirm with the coverage check and your sitemap, and read how to set that up in the Search Console guide.
- Total impressions for the cluster over a rolling window, filtered by the URL prefix that contains the cluster. This is the number that moves when architecture works; individual page positions are noise by comparison.
- Clicks and average position for the cluster, same window, so you can see whether more queries are entering the set or the same queries are improving.
- Link coverage: every spoke has at least one inbound and one outbound internal link, and no spoke is orphaned — the orphan page finder runs that check in one pass.
- Ownership: the pillar, not a spoke, holds the head query. If a spoke consistently outranks the pillar for the head term, the pillar is too thin or aimed at the wrong intent.
Track those five per cluster, monthly, in one sheet. That is how you learn whether the architecture is compounding or just sitting there.
Related Articles
Continue learning with these practical SEO guides:
- Internal Linking Strategy: Link Structure That Ranks - A complete guide to internal linking for SEO - how to build a link structure that distributes authority, helps crawlers discover content, and boosts rankings for your most important pages.
- Keyword Cannibalization: How to Find It and Fix It Without Losing Traffic - Find keyword cannibalization in Search Console, separate real conflicts from intent overlap, then fix each one with a merge, a retarget, or a 301 redirect.
- Programmatic SEO: Building Pages That Scale Without Getting Penalized - Build programmatic SEO pages that scale: justify each template with real data, test 20 pages first, and control indexation before generating thousands.
- Content SEO: Writing Pages That Rank - A complete guide to writing SEO-optimized content: understanding search intent, building briefs, structuring headings, internal linking, and measuring performance.
