How to Build Topic Clusters That Rank a SaaS Site
Kamaraj Mathiarasan (Kim)
Last updated on
Most SaaS topic clusters fail at the whiteboard stage. A team draws a neat hub-and-spoke diagram, assigns 12 blog titles, and starts publishing. Then six months later the pillar still sits on page 3. The diagram looked like a cluster; it was really a content calendar with arrows.
A topic cluster is an architecture you build around how a specific buyer actually searches, with the decision-stage pages doing the heavy lifting and everything wired to point at them. It’s not a shape you draw. Get the wiring wrong and you’ve published 12 articles that compete instead of compounding.
Below is the exact way I build clusters that rank: the pillar-versus-spoke call, how many spokes you actually need, and the linking that turns a pile of posts into one ranking system.
TL;DR
- Clusters fail as org charts (build buyer structure): Most clusters die because they’re drawn as hierarchy diagrams Google never sees, instead of pages wired around how one buyer actually searches.
- Pillar vs spoke is an intent test, not volume: A page is a pillar if it’s where the buyer decides, and a spoke if it exists only to answer one question and feed links toward that decision.
- Size a cluster by coverage, not a number: Map every real buyer question first and the spoke count falls out, usually landing between 8 and 15 pages once you stop padding for a count.
- Real buyer language unlocks uncontested clusters: Pulling keywords from the teams who talk to customers, not a tool, surfaces the messy queries competitors miss and turns a keyword mess into a buildable map.
- Internal linking is what makes it rank as one system: Wire every spoke up to its pillar and concentrate the most links on decision-stage pages, so authority flows where it converts instead of to “what is” posts.
- Avoid the cluster-killers (diagrams, cannibalization, copying giants): Linking with intent, expanding pages instead of writing rivals, and building on winnable intent beats mirroring a competitor’s structure you can’t support.
Why Most SaaS Topic Clusters Never Rank
The standard advice (one pillar, a ring of spokes, link them together) isn’t wrong. It’s just incomplete in a way that quietly kills most clusters. Teams treat the cluster as a publishing structure when it’s really a buyer structure, and those are not the same thing.
Most teams build a cluster around what they want to say. That’s backwards. A cluster has to be built around what one specific buyer searches across an entire decision, from the first vague question to the moment they’re comparing you against the tool they currently hate.
The other failure is subtler. People draw the cluster like an org chart, pillar at the top and spokes hanging below, and assume Google reads it as a hierarchy. Google doesn’t see your diagram. It sees pages, the queries each one answers, and the links between them.
If your spokes don’t link to the pillar with intent, and the pillar doesn’t push authority back to the decision pages, you’ve drawn a hierarchy that exists nowhere except your slide.
I learned to think about this as a system, not a checklist. Across the work we do, the clusters that move pipeline are built as a connected machine where every page returns something (a ranking, a link, a warmed-up buyer) instead of decaying the week after they publish.
Treat content as a product you maintain, not output you ship and forget.
How Do You Decide What’s a Pillar and What’s a Spoke?
A page is a pillar if it’s where a buyer makes a decision, and a spoke if it exists to feed authority and links toward that decision. That’s the whole test, and it’s an intent test, not a volume test.
Most teams pick the pillar by search volume. They find the highest-volume term, make it the pillar, and hang everything else off it. The problem is that term is almost always a top-of-funnel “what is” query, and that page can’t carry a cluster because nobody buys from it.
You end up with a pillar that pulls traffic and a cluster that pulls no pipeline.
Build Around the Page Where the Money Changes Hands
The pillar should be the page closest to the decision. For a SaaS topic, the decision-stage pages (alternatives, pricing, comparison, category) are where the credit card comes out, so those are what you build first. A “what is X” article is a spoke that feeds them, not the reverse.
This flips the usual cluster order. The shape I build follows the buyer down the funnel: What Is → How To → Automate → Tools → Alternatives → Pricing/Reviews → Conversion. The decision-stage nodes get built first because they close, and everything upstream pushes authority toward them.
A cluster that starts with the “what is” page and never reaches the alternatives page is a cluster with no exit.
Use Spokes to Answer Everything the Pillar Can’t
A spoke earns its place by answering a specific question the pillar would bloat trying to cover. If your pillar is a comparison page, the spokes are the questions asked on the way there: implementation steps, integration concerns, the workflow they’re fixing. Each spoke owns one question and links up.
The test for a spoke is simple: does a real buyer search this, and does answering it move them closer to the decision page? If a “spoke” only exists because it had search volume and loosely relates to the topic, it’s a stray post you’ll be auditing in a year.
Coverage means answering the questions buyers ask, not the questions a keyword tool surfaced.
How Many Spokes Does a Cluster Actually Need?
A cluster works at coverage, not at a magic number, but in practice that lands between 8 and 15 pages for most SaaS topics. The honest answer is “enough to answer every real question a buyer has in that topic, and not one page more.”
The instinct is to ask “how many articles should I write?” That’s the wrong question, because it produces clusters padded with thin spokes written to hit a count. The right question is “what does a buyer need answered before they’ll trust this decision page?”
Map every real question, pulled from the team that talks to customers and not from a keyword tool, and the spoke count falls out of the answer instead of being set in advance.
Map the Topic, Then Count the Pages
I build the full topic map before publishing a single page. List every question a buyer asks across the whole decision, group the ones that answer to the same intent, and what survives is your spoke list. One pillar might map to 9 questions, another to 14.
The cluster is “done” when there’s no real question left unanswered, not when you hit a round number.
A practical ceiling helps here. Most single-product SaaS companies have a maximum of 40 to 60 genuine bottom-of-funnel pages across the whole site: software pages, alternatives, comparisons, pricing. Force more decision-stage pages than that and you’re stretching intent that isn’t there.
The same discipline applies inside one cluster: padding it past real demand just dilutes the pages that matter.
One Strong Spoke Beats Three Thin Ones
The multiplier is how many queries each spoke ranks for, not the spoke count. A single post built to answer a question thoroughly ranks for 20 related secondary keywords instead of two, doing the work of ten thin posts. Multiply that across a cluster and the compounding traffic is enormous.
This is the most underrated lever in SaaS SEO, and most teams leave it untouched. They write one post per primary keyword, never expand it to own the related questions, then wonder why a 12-spoke cluster underperforms an 8-spoke one with more depth. Almost every time, fewer pages each covering more will beat more pages each covering less.
A Cluster That Lifted a Whole Site
The clearest example I’ve lived through started when I stopped opening a keyword tool first. Working with Sprinto in 2023, instead of building from Ahrefs, I sent a simple keyword sheet to every team that touches the customer (Sales, CS, Product, marketing) asking what buyers actually said on calls.
I expected duplicates of what Vanta and Drata already ranked for. Instead it surfaced 900+ keywords we’d never have found from a tool, taking the list from around 1,500 to roughly 2,400. Real buyers don’t search like SEO pros. They use the messy, layman language sales hears on calls.
That language is where the un-contested cluster opportunities hide.
Those 2,400 keywords weren’t a content calendar. Grouped by intent, they became topics, and topics tell you how many pages a cluster actually needs. “What is GRC,” “GRC components,” and “GRC examples” all map to one pillar page, not three thin articles.
That’s how a 2,400-keyword mess collapses into a tight, buildable cluster map instead of a backlog.
That’s the difference between a list and a strategy. A spreadsheet of 2,400 keywords is noise; grouped into topics it’s a business case (this many BOFU pages, this many MOFU, this many TOFU) built around language buyers use.
The cluster ranked because it answered real questions in real words, not because the diagram was tidy.
How Do You Wire a Cluster So It Ranks as One System?
Internal linking is what turns a pile of related posts into a cluster Google reads as authority, and it’s the step most teams treat as an afterthought. The links aren’t decoration. They’re how PageRank and topical relevance flow toward the pages you need to rank.
Every spoke links up to its pillar, the pillar links down to its most important spokes, and the whole thing pushes toward the conversion pages. Decision-stage nodes (alternatives, pricing, case studies) should be the most-linked-to pages in the cluster, because that’s where you want authority concentrating.
If your highest internal-link count sits on a “what is” article, you’re funneling authority to the page that converts worst.
Link With Intent, Not With a Plugin
Automated “related posts” widgets don’t build a cluster. They scatter links by recency or tags, not by buyer logic. A real cluster link goes from a specific sentence where a reader has a genuine next question to the exact page that answers it.
The anchor text describes the destination, the placement matches where the reader’s intent shifts, and every link earns its place by moving someone closer to a decision.
This is also where topical authority gets built. It’s one of the dimensions modern SaaS SEO is scored on (alongside intent mapping, technical health, and brand signals) and clusters are how you earn it. Covering one topic completely and linking it coherently tells Google you own that subject.
That’s what lets the decision pages rank without buying links. Most teams chase backlinks for those pages when tighter internal architecture would have done more.
Common Mistakes That Break a SaaS Cluster
The most common one is building the cluster as a hierarchy diagram and stopping there. The diagram works when it’s a map of buyer questions wired with intent; it breaks the moment it’s boxes and arrows nobody links between. A diagram with no linking is just a wish, not a cluster.
The second is letting clusters cannibalize each other. Build two pages for the same intent, a “best X tools” post and a “top X software” post, and they split rankings and compete for the same query. Google often ranks neither well.
This happens fast once a site crosses 30 to 50 posts. Before adding a spoke, check that no existing page already owns that intent; if one does, expand it instead of writing a rival.
The third is copying a giant’s cluster structure wholesale. A big competitor often ranks on brand power, not on a clean cluster, so mirroring their page structure when you lack their domain authority just gives you their weaknesses without their backlinks.
Steal the content structure of whoever actually ranks #1 for your terms (frequently an aggregator like G2) but build your cluster on intent you can realistically win, not on authority you don’t have.
How PipeRocket Digital Builds Clusters That Rank
We build clusters backwards from the decision. Before mapping a single pillar, we interview the teams that talk to customers, group those queries into topics, and architect the cluster so the decision-stage pages get built and linked first.
Then we wire the internal links with buyer intent, not a plugin, so authority concentrates where it converts. If your content is publishing but not compounding, that’s usually an architecture problem. Talk to our team or see how we approach SaaS SEO .
Frequently Asked Questions
What is the difference between a pillar page and a topic cluster?
A pillar page is a single page; a topic cluster is the pillar plus all the spoke pages that support it and link to it. The pillar is the central page you most want to rank, usually a decision-stage page like a comparison or category page.
The spokes are the supporting posts that each answer one specific question and pass relevance and links back to the pillar. You can’t have a cluster with only a pillar. The cluster is the whole connected system, not just the hub.
How many blog posts do you need for a topic cluster?
There’s no fixed number. A cluster is complete when it answers every real question a buyer has about that topic, which usually lands between 8 and 15 pages for a SaaS subject. Counting pages first is a mistake because it pushes you to pad the cluster with thin posts.
Map the actual questions buyers ask, group them by intent, and the page count falls out of that map instead of being decided in advance.
Do topic clusters still work for SEO with AI search?
Yes, and arguably more so. Topic clusters build topical authority by covering a subject completely and linking it coherently, which is exactly the signal both Google’s rankings and AI answer engines use to decide who’s a credible source on a topic.
Organic search still drives the overwhelming majority of SaaS traffic and converts far better than AI-referred visits, so a well-built cluster earns rankings now and positions you as the source AI engines cite. Thin, disconnected content loses on both fronts.
