# Topic clusters for SaaS content

> Hub and spoke architecture for SaaS: how many spokes a cluster needs, internal link rules, anchor discipline, and when a cluster should be split in two.

Source: https://saas-marketing.net/guides/topic-clusters-for-saas/
Topic: SaaS Content Marketing
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/topic-clusters-for-saas/

## Short answer

A SaaS topic cluster is a hub page covering a subject broadly plus 30 to 60 spoke pages each covering one query in depth, with every spoke linking to the hub and siblings linking by shared intent. Clusters compound when built to completion and fragment when abandoned at 10 or 15 pages. Measure at cluster level using share of covered queries ranking in the top ten, not per post traffic.

## Key takeaways

- A cluster reads as authoritative to search engines and language models at roughly 30 to 60 published spokes, not at 10.
- Every spoke links up to the hub. Siblings link sideways only when they share buyer intent, never on keyword similarity alone.
- Build bottom of funnel spokes first. They convert while the informational pages are still climbing.
- Cannibalisation starts with anchor text, not with content. Two pages carrying the same anchor split the signal within a quarter.
- Measure share of covered queries in the top ten at cluster level. Per post traffic hides whether the architecture is working.
- One cluster finished beats five started. Most teams open a second cluster at least 20 pages too early.

---

Most SaaS content programs fail at the architecture layer, not the writing layer. The posts are fine. There are just 90 of them spread across eleven subjects, each one an orphan, and the site reads to Google like a company that has opinions about everything and expertise in nothing.

A topic cluster fixes that by concentrating publishing effort into a shape search engines and language models can recognise. The shape is simple. The decisions inside it are where teams go wrong, and they're mostly decisions made in the first month that you live with for two years.

## Where do you draw the cluster boundary?

Draw it where the buyer's intent changes, not where your keyword tool draws a topic group. This is the single decision that determines whether the cluster compounds or fragments, and it takes an afternoon to get right.

The test: can one hub page introduce every child topic in a single paragraph without the paragraph contradicting itself? "SaaS content marketing" passes. It covers strategy, formats, distribution, measurement and operations, all read by the same person with the same job. "SaaS marketing" fails. A demand gen lead buying paid media and a content manager planning a quarter are different people with different budgets, and a hub trying to serve both serves neither.

Three boundary heuristics that hold up:

- One buyer role, one job to be done, one budget line.
- The hub's head term has a plausible path to page one within 12 months given your current domain strength.
- You can list at least 30 genuine questions inside the boundary before you run dry.

If you can only list 14 questions, the boundary is too tight and the cluster will look thin forever. If you list 140, you have two or three clusters and should say so now rather than discovering it in month eight.

Use a short hub path and keep spokes one level deep under a type directory, so /saas-content-marketing/ is the hub and /guides/topic-clusters-for-saas/ is a spoke. When a cluster splits later, you promote a spoke to a hub and rewire links. Nothing needs redirecting. Teams who nest spokes inside cluster folders end up choosing between a messy split and a redirect chain.

## How many spokes before a cluster reads as authoritative?

Thirty at minimum, sixty at the ceiling, and the number matters more than any individual page's quality. A cluster of 12 excellent articles loses to a cluster of 35 good ones on nearly every competitive head term, because coverage is the signal being measured.

**30 to 60** Spokes in a cluster that competes on a head term, before a split becomes the right move

The order you build them in changes the return profile substantially. Build the bottom of funnel spokes first: comparison pages, alternatives pages, pricing and cost queries, integration pages, and the "how do I do X with Y" queries where your product is the answer. These convert at meaningfully higher rates than informational pages and they buy you political cover while the rest of the cluster is still climbing.

| Build phase | Pages | What you are buying | Typical time to result |
|---|---|---|---|
| Phase 1 | 8 to 12 bottom of funnel spokes | Conversions and internal credibility | 6 to 14 weeks |
| Phase 2 | Hub plus 10 to 15 core informational spokes | Topical coverage and hub authority | 4 to 8 months |
| Phase 3 | 10 to 20 long tail and definitional spokes | Citation surface and link magnet pages | 6 to 12 months |
| Phase 4 | Updates and consolidation | Defending what you won | Continuous |

Phase 3 has changed in importance. Definition and glossary style pages used to be low-value filler. They're now the highest frequency citation surface for language models, which means a page that gets 40 visits a month can be the page ChatGPT quotes when someone asks about your category. That's a different kind of return and it doesn't show up in a traffic report.

## What the internal linking rules should be

Three rules, applied without exception. Most cluster failures trace back to breaking one of them for convenience.

**Every spoke links up to the hub, in the body, high on the page.** Not in a related-posts widget at the bottom, not in a sidebar. Template-generated links carry much less weight than an editorial link inside the first half of the copy. This is the rule that concentrates authority on the hub, and it's the one teams skip when a writer forgets and nobody checks.

**The hub links down to every spoke.** Which means the hub gets edited every time you publish. Build that into the publishing workflow or it won't happen. A hub that links to 20 of its 45 children is leaving a quarter of the cluster orphaned.

**Siblings link sideways by shared intent, not by keyword similarity.** This is the rule people get wrong. A page on comparison page structure should link to a page on competitor claim accuracy, because the same reader needs both on the same afternoon. It should not link to another page just because both contain the phrase "comparison". Keyword-similarity linking is how you build a cluster where every page links to every other page, which passes essentially no useful signal about relationships.

Automated related-post modules generate links by tag match. They produce dense, undifferentiated linking that tells search engines nothing about which pages matter. Keep them if you like for readers, but never count them as your internal linking. The links that do work are the ones a writer placed because a reader would want them there.

## How anchor text discipline prevents cannibalisation

Cannibalisation starts with anchors. Two pages that consistently receive the same internal anchor phrase will split the signal for that phrase, and you'll watch both hover at position eleven while a weaker competitor holds five.

The fix is a keyword register: one sheet, one row per page, primary keyword assigned to exactly one URL, and the two or three approved anchor variants for linking to it. Anyone briefing a piece checks the register first. Anyone editing checks that the anchors used match the register. It sounds bureaucratic for a five person team and it takes about ten minutes a week.

Vary the anchors within the approved set. Exact match on every internal link looks manufactured and reads badly. A mix of exact match, partial match and natural phrase covers both concerns. What matters is that "topic cluster strategy" always points at one URL, never at two.

If you inherit a site where this has gone wrong already, the repair is usually consolidation rather than de-optimisation. Pick the stronger page, merge the useful content from the weaker one, redirect it, rewrite the anchors. Running the [quarterly content strategy review](/checklists/saas-content-strategy-review/) catches most of these before they harden.

## Measuring a cluster without lying to yourself

Per post traffic is the wrong unit. It tells you which pages got lucky and nothing about whether the architecture is doing its job. Measure four things at cluster level, monthly.

That last row matters more every quarter. AI Overviews now appear on roughly 48 percent of queries, and organic click through on those queries drops by around 61 percent. If your only measure is sessions, a cluster that is winning citations while losing clicks reads as a failure. Build the manual prompt set: twenty questions your buyer would ask an assistant, run monthly, record which domains get named. It takes an hour and it's the only honest read available right now.

## A worked map of a 60 page cluster

Here's the shape of a finished cluster for a mid market SaaS company selling to marketing teams. Hub plus five branches, spokes distributed by intent.

**Hub:** the pillar page at /saas-content-marketing/, around 3,000 words, genuinely readable standalone, linking down to every branch and the strongest spoke in each.

**Branch one, strategy (12 spokes):** cluster architecture, keyword research for zero volume products, content strategy templates, editorial calendars, budget allocation by ARR band, in house versus agency economics.

- **Branch two, formats (14 spokes):** comparison pages, alternatives pages, integration pages, glossary architecture, case study production, templates and tools as content, video, webinars.

**Branch three, distribution (10 spokes):** newsletter mechanics, LinkedIn for B2B SaaS, community distribution, syndication, digital PR for links.

- **Branch four, measurement (12 spokes):** attribution models, content sourced pipeline, cohort measurement, content decay detection, AI citation tracking, reporting to a board.

**Branch five, operations (12 spokes):** SME interview systems, freelancer management, QA rubrics, style guides, approval workflows, CMS selection.

Notice branch five. Content operations is named as a gap by almost every top-ranking guide in this category and covered properly by none of them, which makes it the cheapest twelve pages of authority available. The same is true of the failure-analysis pages nobody writes. Build what the incumbents skipped and you compete on an empty stretch of the query set rather than on the crowded one. The [SaaS topic clusters](/guides/saas-topic-clusters/) breakdown goes deeper on branch selection, and the [content strategy template](/templates/saas-content-strategy-template/) includes a cluster map you can fill in.

## The signals that a cluster should split

Four signals. Any two together mean split now rather than next quarter.

One sub-branch crosses 25 pages of its own. At that size it has enough internal gravity to support a hub, and keeping it as a branch means its pages fight each other for the parent hub's attention.

The hub's introduction has started hedging. If you find yourself writing "depending on if you are a startup or an enterprise" twice in the opening, the boundary has two buyers inside it.

Two different people in your company own different parts of the cluster. Ownership usually tracks intent, and split ownership predicts split intent.

Search Console shows the hub ranking for two distinct query families with no overlap in the pages that support them. That's two clusters wearing one hub.

Splitting is cheaper than people fear. Promote the strongest spoke in the branch to a hub, write it up to full pillar length, rewire the internal links inside the branch to point at the new hub, add a link from the old hub to the new one, and leave every URL where it is. A week of work, no redirects, no lost equity.

## What to do this week

If you're starting from scratch, do the boundary work first and write down the thirty questions. If you can't reach thirty, you don't have a cluster yet.

If you have four half-built clusters, and most teams do, pick the one closest to your product's revenue and finish it. Publish twenty more spokes into it before you touch the others. This is the least popular advice in content strategy and the most reliably correct: one cluster built to completion beats five at 40 percent, every time, because authority does not average across subjects.

The [B2B SaaS content marketing](/guides/b2b-saas-content-marketing/) guide covers what goes inside the spokes, the [topic cluster](/glossary/topic-cluster/) definition is the short version to send a colleague, and if you want the whole system taught in order, the [B2B SaaS content strategy course](/courses/b2b-saas-content-strategy/) walks through boundary selection, build order and measurement. Once the cluster is compounding, the [social media strategy for SaaS](/guides/saas-social-media-strategy/) and [SaaS video marketing](/guides/saas-video-marketing/) guides cover the distribution layer that makes each spoke earn more than search alone would give it.

## Frequently asked questions

### How many pages does a SaaS topic cluster need?

Plan for 30 to 60 spokes around one hub. Below about 20 published pages a cluster rarely reads as authoritative on any competitive subject, and the hub struggles to rank at all. Above 60 you are usually looking at two clusters that should be split, with the boundary falling where the buyer intent changes.

### Should the hub page target the head keyword?

Yes, but expect it to rank last. Hub pages inherit authority from spokes, so the head term is typically the final thing you win, often nine to fifteen months in. Write the hub to be genuinely useful on its own rather than as a link directory, because thin hubs stop passing the signal they are supposed to concentrate.

### What URL structure works best for clusters?

A flat structure with a descriptive hub path and spokes one level deep works well: /saas-content-marketing/ as the hub and /guides/topic-clusters-for-saas/ as a spoke. Deep nesting by cluster adds no ranking benefit and makes it painful to move a page when a cluster splits, which happens more often than teams expect.

### How do you stop keyword cannibalisation inside a cluster?

Assign one primary keyword to exactly one page and record it in a sheet everyone writing must check. Then police anchor text: if two pages receive the same internal anchor phrase, search engines split the signal between them. Cannibalisation almost always starts as an anchor text problem before it becomes a content problem.

### How do you measure whether a topic cluster is working?

Track share of covered queries: the percentage of the cluster's mapped keyword set that ranks in the top ten, measured monthly at cluster level. A healthy cluster moves that share up steadily even while individual pages bounce around. Add cited-in-AI-answers tracking, since clusters increasingly earn citations before they earn clicks.

### When should you split a topic cluster in two?

Split when the spokes serve two different buyers, when the hub cannot introduce all its children in a paragraph without contradicting itself, or when one sub-branch exceeds about 25 pages of its own. Splitting means promoting a spoke to a hub, redirecting nothing, and rewiring internal links over a week.

### Should you build several clusters at once?

Almost never below 20 published pages in the first one. Authority concentrates, and splitting a limited publishing budget across three clusters produces three sets of pages ranking on page three. Finish one cluster to 30 spokes, confirm the hub is moving, then start the second.