How to Build Topic Clusters That Rank

This guide shows you how to plan a topic cluster that earns search visibility: how to pick topics worth a cluster, how to decide which subtopics get their own page, how to link the pages, and how to tell after three to twelve months whether it is working. It also sets out what Google has actually said about "topical authority", because most cluster advice leans on a ranking factor Google has never documented for ordinary websites.

The short version: a cluster is a planning tool, not a ranking signal. It works when each page answers one distinct search need well, when the pages are linked the way a reader would move between them, and when you maintain them. It fails when it becomes a quota of articles pointing at an overlong pillar page.

What a topic cluster is (and is not)

A topic cluster is a set of pages that together cover one subject, where each page owns a distinct search intent and the pages link to each other where a reader would want to go next. The pillar page sets out the scope of the subject and routes readers to the detail. Each spoke page answers one specific question or task in full, and would be worth publishing even if the cluster did not exist.

Two common misreadings cause most failed clusters. The first treats spokes as keyword variants of the pillar ("content audit tips", "content audit best practices"), which produces pages that compete with each other. The second treats the cluster as a silo where pages may only link inside their own group. Real topics overlap, and a link to an adjacent cluster is fine whenever it helps the reader.

A useful test for any cluster plan: could you hand each page's one-line purpose to a different writer, and would no two writers end up answering the same question?

What Google has and has not said about topical authority

"Topical authority" is the idea that search engines reward a site for covering a subject thoroughly. It is a useful planning model. It is not a documented Google ranking factor for general websites, and it pays to be precise about what Google has published:

• Google has a "topic authority" system, for news. In May 2023 Google described a topic authority system that helps surface expert sources for news queries in specialised areas such as health, politics and finance. The signals it names are news-specific: how notable a publication is for a topic or location, how often other publishers cite its original reporting, and its reputation for quality reporting.
• Google's ranking systems mostly work on pages, with some site-wide signals. The ranking systems guide says its systems are designed to work at the page level, that site-wide signals and classifiers are also used, and that good site-wide signals do not mean every page on the site will rank well. It does not list a topical authority system.
• Links help Google find pages and understand them. Google's link best practices say every page you care about should have a link from at least one other page on your site, that good anchor text is descriptive, reasonably concise and relevant to both pages, and that the words around a link matter too.
• Site structure matters less than many guides claim. The SEO Starter Guide says grouping similar topics in directories can help Google learn how often URLs in a directory change, mainly on sites with more than a few thousand URLs, and that keywords in the URL path alone have hardly any effect beyond breadcrumbs.
• There is no special optimisation for AI answers. Google says AI Overviews and AI Mode issue multiple related searches across subtopics to build a response, and that there are no additional requirements to appear in them beyond normal SEO best practice.

So what does a cluster actually do for you? Three concrete things. It makes every page discoverable through descriptive internal links. It forces one clear page per search intent, which removes the overlap that leaves Google choosing between your own pages. And it makes you cover the subtopics a reader needs, which is what Google's helpful content guidance asks for. That is reason enough to build clusters. Promising that a cluster will raise a hidden authority score is not.

Why most cluster projects underperform

When a cluster has not moved after six months, the cause is usually one of five things.

• A pillar that tries to rank for everything. "The complete guide to content marketing" that covers strategy, creation, distribution, measurement and tooling ends up shallow on each, and the spokes have nothing left to own.
• Spokes without distinct intent."Content marketing tips", "content marketing best practices" and "content marketing strategies" are one page with three titles. Publishing all three splits clicks and links across pages that answer the same need. Check for overlap with a cannibalization audit before you write, not after.
• Mechanical linking."Every spoke links to the pillar, the pillar links to every spoke" with the same anchor each time gives readers no reason to click and gives Google little context about what each page covers.
• No look at the results page. Teams plan clusters around what they want to write, not around what the search results show people want, or where they have a realistic chance.
• Building from scratch on top of an existing library. New spokes duplicate older posts, and the site ends up with two or three pages for the same question.

Choosing which clusters to build

Not every topic deserves a cluster. Score each candidate on five questions and decide to build, defer or skip. The thresholds below are rules of thumb from cluster planning work, not figures Google publishes; adjust them to your market.

Three or more "Build" answers, and no "Skip" on the first question, is a reasonable bar for committing. A cluster that fails the first question can still earn traffic, but treat it as discretionary work, not strategy.

For the competition question, look at the actual results for the head term and three or four likely spokes. Search volume alone misleads: a query whose results are full of video, forums and large platforms may send few clicks to an article, while a smaller query with a page of dated blog posts is a real opening. Running competitor benchmarking and search intent analysis across the candidates turns this from a guess into a comparison.

A worked example: one cluster, planned on paper

Here is a cluster plan for a fictional HR software company deciding whether to build around "employee onboarding". The pages, queries and decisions are illustrative; the method is the point. The intent labels use the query types from Google's Search Quality Rater Guidelines: Know (learn about something), Know Simple (one short answer), Do (accomplish a task) and Website (find a specific site).

Notice what the plan does not contain: a word count per page, or a page for every keyword variant. Seven candidate pages became five, one of them a refresh. That is typical. A plan where every candidate survives usually means nobody checked for overlap.

Designing the pillar page

The pillar does three jobs: it answers the broad query well enough to stand on its own, it shows the reader the shape of the subject, and it sends them to the right spoke for depth.

Scope test.If a reader finishes the pillar with no reason to open any spoke, the pillar is doing the spokes' work. If they finish it still unable to explain the subject to a colleague, it is too thin. Each section should summarise its subtopic in a few paragraphs and link to the spoke that covers it in full.

Length. Do not set a target. Google's SEO Starter Guide says the length of content alone does not matter for ranking, and its helpful content guidance says plainly that Google has no preferred word count. Let the number of subtopics decide the length.

Headings.Use the cluster's main subtopics as the pillar's H2s, because that is how a reader scans for their question. Do it for readers: Google's starter guide says there is no ideal number of headings and that using them out of order does not matter.

The mega-guide trap. A pillar that grows into a reference manual becomes the page Google may show for spoke queries instead of the spoke, and it is hard to keep current. When a pillar section passes a few screens of text, it is usually a spoke that has not been split out yet.

Choosing spoke pages

Good spokes are distinct, individually worth searching for, and together cover what a reader needs. Three sources give you the candidate list:

• The results page. People Also Ask, related searches and the subtopics the top-ranking pages share. This is the start of content gap analysis.
• Your own Search Console data. Queries where you already get impressions but no page truly answers them are the cheapest spokes to win.
• Your customers. Sales and support questions that no page answers. These rarely show up in keyword tools and are often the most valuable spokes.

Then apply the merge test to every pair of candidates that sound alike. Search both queries and compare the top ten. If the results overlap heavily (as a rule of thumb, four or more of the same URLs), Google is treating them as the same need, so one page should serve both. If the results differ, the needs differ, and two pages are justified. Recording the winner in a keyword-to-page map stops the next writer from reopening the question.

Group the survivors by what the searcher is trying to do:

• Definitions and context ("what is X"): often a pillar section rather than a page.
• How-to and process: step-by-step pages for someone doing the task now.
• Comparison and evaluation ("X vs Y", "best X for"): closest to a buying decision.
• Troubleshooting ("why is X not working"): narrow, urgent, often high intent.
• Advanced practice: depth for experienced readers, the pages most likely to earn links from peers.

Finally, look for the angle nobody covers: an industry-specific version, a template, a worked example with real numbers you are allowed to share. Those are the spokes competitors cannot copy quickly.

Linking the cluster

Internal links let readers and crawlers move through the cluster, and their anchor text tells both what the destination covers. Plan four kinds:

• Pillar to spoke.In the section that summarises the subtopic, with an anchor that names it ("the onboarding checklist", not "click here").
• Spoke to pillar. Early, where the broader subject comes up, with an anchor that says what the pillar adds.
• Spoke to spoke. Where the content naturally meets: the first-week plan links to the checklist where it lists paperwork. This is the link most clusters skip.
• Cross-cluster.Where a reader would genuinely continue into another subject. Do not remove these to keep a silo "pure".

Follow Google's anchor text advice: descriptive, reasonably concise, relevant to both pages, and readable in the sentence around it. Vary anchors naturally; twenty spokes all linking back with the same phrase tell the reader nothing. An internal link audit shows whether yours are descriptive or repetitive.

Validate the structure after launch. Three checks, all rules of thumb rather than Google thresholds: every spoke is linked from the pillar, every spoke is reachable within two clicks of the pillar, and no spoke has only one internal link pointing at it while another has dozens. An internal link audit finds orphans and lopsided distribution; a site architecture review shows how the cluster sits in the rest of the site. For the wider method, see the guide to internal linking at scale.

Building clusters from existing content

Most sites have years of content written without a cluster plan. Retrofitting it is usually faster than starting over, and it avoids creating new duplicates.

1. Inventory. List every page that touches the topic, with its queries, clicks and inbound links. A content inventory that classifies page type and intent makes this a filter rather than a reading project.
2. Assign. Give each page one home cluster and one intent. Pages that serve two intents need splitting or a decision.
3. Consolidate. Where several pages answer the same need, keep the strongest URL (by clicks, rankings and links), merge the best material into it, and permanently redirect the others. Google says it treats a permanent redirect as a signal that the target should be canonical. The consolidation guide covers when to merge, prune or leave a page alone.
4. Fill gaps. What is still missing becomes your brief queue, prioritised with the same viability questions you used for the cluster. The guide to content briefs covers what each brief needs.

You do not need to move existing pages under one URL folder for Google to understand that they belong together; links and content do that. Consistent paths do make clusters easier to filter, report on and maintain, which matters more as the site grows. A Site architecture review tells you whether a restructure is worth the redirects, and the migration playbook covers doing it safely.

Measuring a cluster

Page metrics tell you whether a page works. Cluster metrics tell you whether the plan works. Track the cluster as one unit.

Define the cluster in Search Console. In the Performance report, add a Page filter with Custom (regex) that matches the cluster's URLs, for example /hr/onboarding|/blog/(remote-onboarding|first-week-plan). Matching is partial and case-insensitive by default. Save the expression with the cluster plan so every report uses the same definition.

• Coverage. Of the distinct needs you listed for the topic, how many have a page or pillar section that answers them well? In the example above, five of seven needs are covered after launch (71%), with one deferred on purpose. Aim to cover the important needs, not every niche variant.
• Query and position spread.For the cluster's queries, how many sit in positions 1 to 3, 4 to 10, 11 to 20 and below? A healthy cluster moves queries up over time. As a rule of thumb, judge indexing and first impressions at about three months and rankings at six to twelve.
• Share of clicks.Compare the cluster's share of your organic clicks with its share of the demand you target. A cluster aimed at a large share of your addressable searches that brings a small share of clicks is where to look first.
• Business outcomes. In GA4, conversions from sessions that start on cluster pages. Informational clusters convert less and earn more links; comparison pages convert more. Know which you built before you judge it.
• Link health. New spokes linked from the pillar and at least one sibling within a week of publishing; no orphans.

If you add several spokes and the position spread has not moved after about three months, look at intent match and content quality before adding more pages. The measurement guide goes further on tying content to outcomes.

When a cluster is the wrong tool

Clusters help most when a subject has many distinct needs, when your buyers research over weeks, and when you already have partial coverage to organise. They add overhead without much return when:

• The topic is narrow. Three or four needs are usually better served by one thorough page.
• The content is time-sensitive. News and trend commentary need speed, not architecture.
• Nobody will maintain it. A large cluster left to go stale is worse for readers than a few pages kept current. If you cannot commit to reviewing it, build fewer pages.

Common mistakes

Choosing topics on volume alone

High volume says nothing about whether you can win or whether the visitors will buy. Weigh it against the results page and business fit, as in the viability table.

Publishing every spoke at once

Launch the pillar with three to five core spokes, watch which subtopics gain impressions, and let that shape the next batch. Later spokes are better for what you learned writing the first ones.

Formatting for features you cannot control

Question-led headings with a direct answer underneath are good for readers, and that is the reason to write them. Do not promise featured snippets: Google says it decides which page makes a good featured snippet and that site owners cannot mark a page to get one. If SERP features matter in your market, SERP feature targeting shows which queries show them and who holds them.

Pruning for the wrong reason

Some spokes will not work. After six to twelve months, review the ones with no impression growth: merge them into a sibling, re-aim them at a need the results page supports, or retire them with a redirect. Do it because the page is not helping readers. Google's helpful content guidance is explicit that removing lots of older content just to make a site seem fresh will not help. Content pruning analysis puts the data behind each call.

Where Morrison fits

dash.morrison.app/lumenpay.com/chat

Illustration

lumenpay.com/Cluster gaps: holiday pay

What do you want to know about lumenpay.com?

Ask about your website content...

Search ConsoleSerpApiAhrefsContent Planning / Pillar & Cluster Mapping

Claude Sonnet 5.5

Everything above works with spreadsheets and standard tools. The slow parts are the inventory, the overlap checks and the measurement, and those are the parts Morrison does.

• Inventory. Morrison crawls and indexes every page on your site and classifies each one by page type and search intent, so pages with onboarding in the path or title, with their intent, are one filter in the URL grid, and chat finds the rest by meaning.
• Demand and competition. In chat, Morrison combines your pages with Search Console queries, live Google results, SERP features and People Also Ask from SerpApi, and keyword difficulty and competitor visibility from Ahrefs if you connect it.
• Whole-site checks. Chat answers from the whole site index, scores included. To run the same check on every page of a cluster spanning hundreds of URLs, build a workflow and run it on the segment, up to 500 URLs a run.
• Gaps to briefs.Skills such as the Question & FAQ Harvester, the Outdated & Thin Content Finder and the Universal Brief Builder turn the gap list into briefs, written to a canvas where you can ask about any passage and download the brief as Markdown.
• Measurement. An automation can send the cluster report by email every week or month.

The decisions stay with you: which clusters fit the business, which pages to merge, what angle each spoke takes. See topical map and cluster planning for how teams run this in Morrison.

Key takeaways

• Topical authority is a planning model, not a documented ranking factor. Google has a topic authority system for news and uses some site-wide signals, but ranks mostly page by page. Build clusters for readers, discoverability and clean intent.
• One page per search need. Use the merge test: heavily overlapping results mean one page.
• Decide with a viability check. Business fit, intent mix, competition, existing content and maintenance capacity.
• Audit before you build. Consolidate and redirect overlapping pages first, then brief the gaps.
• Link like a reader. Descriptive anchors, spoke to spoke as well as hub to spoke, and no orphans.
• Measure the cluster as one unit. A saved regex in Search Console, position spread, share of clicks and conversions.
• Maintain it, or build less. A smaller cluster kept current beats a large one left to decay.