Marketing
May 4, 2026
Topic Cluster Architecture: Hub-and-Spoke for SaaS
What hub-and-spoke SEO actually means
Topic clusters for SaaS are a content architecture model where one hub page covers a broad topic at a high level and multiple spoke pages each go deep on a specific subtopic, all connected through internal links. The hub targets a broad keyword. Each spoke targets a long-tail query. Both link back to each other, and the bidirectional structure tells Google your site covers a subject in depth, not just breadth.
If you run marketing for a SaaS company, this matters at the consideration stage for one reason: you already produce blog content. Cluster architecture is what shifts that content from traffic-neutral to traffic-compounding. Without it, every post you publish competes alone, reinforces nothing, and rarely breaks into the top 10.
This guide covers what the model actually is, how to map it to a SaaS product, the URL structure decisions most agencies skip, how many spokes a single hub should support, and the live cluster running on this site as a worked example.
A hub page covers a broad topic at a high level. Spoke pages each address one specific subtopic in depth and link back to the hub. The hub links out to every spoke. Internal authority radiates from the hub outward and from the spokes back inward.
Hub: the pillar page targeting a broad head term (e.g., "CRM software")
Spoke: each cluster article targeting a specific long-tail query (e.g., "how to automate follow-up emails in a CRM")
Connection: every spoke links to the hub, the hub links to every spoke, and adjacent spokes link to each other when topically relevant
Outcome: search engines treat the cluster as one demonstrated topic, not 12 disconnected pages
HubSpot formalized this model around 2017, when it reorganized thousands of existing posts into topic-based groups after Google's ranking systems shifted away from keyword-level matching toward topic authority. The model has since become the default content architecture for most SaaS marketing teams that take SEO seriously.
Why topic clusters SaaS teams skip lead to stalled blogs
Without a cluster structure, every SaaS blog post fights the SERP alone. No post reinforces another. Search engines see breadth without depth. They rank accordingly.
This is why most SaaS blogs accumulate hundreds of published posts and earn meaningful traffic on a handful of them. 75% of searchers never reach page 2, so an isolated post that lands on page 3 effectively does not exist. We see this pattern in roughly every audit we run on a B2B SaaS blog older than two years, and it is the single most common reason most B2B blog content never ranks.
SaaS products are well-suited to clustering, because the feature set itself produces natural hub topics. A project management tool's posts on task automation, time tracking, integrations, and team permissions should each form a hub with their own spokes, not sit in a flat chronological archive. The product surface gives you the cluster map for free. Most teams ignore it.
How to map a SaaS product to a cluster: URL structure first
Map your product's feature categories to hub topics before you start keyword research. Each feature area becomes a hub. Each use case, comparison, or how-to query underneath it becomes a spoke. URL structure is not cosmetic. The path /blog/crm/email-automation/ signals topical proximity to Google in a way that /blog/email-automation-tips-2024/ does not.
The order of operations matters more than most blog posts on this subject admit:
List your product's core feature areas as candidate hub topics. For a project management SaaS, that might be task management, reporting, and integrations.
For each candidate hub, research the full search-intent landscape. How-to queries, comparison queries, and use-case queries all qualify as spoke candidates.
Lock the URL taxonomy before any post goes live. Retroactive restructuring costs crawl budget, triggers redirect chains, and resets some of the link equity you already earned.
Publish the hub first, then publish spokes that link back to it. Hub-first is non-negotiable.
Audit existing posts and decide which to migrate, merge, or retire. Posts that fit no hub are usually candidates for deletion, not preservation.
HubSpot's 2017 restructure remains the most public worked example. It moved a flat chronological archive into topic-organized groups and used the migration to compound organic traffic at scale. The lesson is not "do what HubSpot did." The lesson is that a clean URL taxonomy is worth more than another 50 posts in the wrong shape. For the content side of this argument, see our note on why context, not just content, decides what ranks.
How many spokes per hub: a practical answer
Eight to fifteen spoke pages per hub is the working range for most SaaS companies. Below eight, the cluster does not have enough surface area to signal topical authority. Above twenty without proportionate search demand, your effort spreads across pages that will never rank and that dilute the cluster's average quality.
The number you actually need is set by counting distinct search intents under the hub topic, not by a content quota. Synonyms of the same query do not qualify as separate spokes. "Best CRM for startups" and "top CRM for early-stage companies" are one spoke, not two.
Search Engine Land documented a cluster rollout that drove a 53% traffic lift in three weeks, with most supporting posts up triple digits in views, when hub and spokes shipped together rather than drip-fed. That compounding effect is the whole point of cluster architecture. Drip-feeding one spoke per quarter loses most of it.
A few rules we apply on every cluster build:
Every spoke needs at least one original analysis, observation, or data point. Spokes under 600 words that restate competitor content harm the cluster average and signal thin coverage to Google's quality systems.
Prioritize spokes by search volume and buyer intent first, ease of production last.
Map spokes to buyer stages. Awareness spokes feed the hub, consideration spokes feed product pages, decision spokes feed pricing or demo pages.
Kill spokes that have no internal link path to a revenue page. They are traffic for traffic's sake.
Topic cluster vs pillar page: the distinction that matters
A pillar page is one component of a topic cluster: the hub. A topic cluster is the full system, including the pillar, every spoke beneath it, and the internal link structure binding them. Publishing one long-form pillar page and calling it a cluster strategy is the most common content planning mistake in SaaS SEO.
Pillar page | Topic cluster | |
|---|---|---|
What it is | Single page | Network of pages |
SEO scope | Broad keyword overview | Full topical coverage |
Internal links | Outbound to spokes | Bidirectional structure |
Sufficient on its own? | No | Yes, when spokes are strong |
The pillar without spokes is just a long article. The spokes without a pillar scatter link equity across the site with no canonical destination to consolidate it. Most SaaS teams publish spoke-style posts first, then try to retrofit a hub on top a year later. That order works against you. Build the hub or at least designate its URL before the first spoke ships, even if the hub launches as a stub. For why source-of-truth pages matter to ranking signals more broadly, see our breakdown on E-E-A-T as a ranking signal. Conductor's guide on topic clusters and pillar pages covers the structural distinction in more detail.
Gravidy's own cluster architecture as a live example
This blog is organized around six pillars: Technical SEO, Content and On-Page, Search Evolution (AI and voice), Off-Page Authority, International SEO, and Analytics and Measurement. Every post you find in our archive maps to one of those six. New posts target gaps in incomplete pillars first. The publishing calendar is a direct output of cluster gap analysis, not trend chasing.
A few rules we apply to our own architecture:
Hub-first: the hub URL is designated or stubbed before any spoke goes live, so every spoke has a canonical destination to point at.
Internal links flow from the highest-authority page in a cluster toward the page that needs ranking support, not from new posts to whatever is loosely related.
Pillars 4, 5, and 6 (Off-Page, International, Analytics) are the current publishing priority precisely because they are the incomplete clusters, not because those topics are trending.
This article is a spoke in the Content and On-Page pillar. It links back to the content strategy hub and across to adjacent spokes in the same cluster.
You can see the model in production. The post on why the AEO vs GEO vs LLMO acronym soup doesn't matter is a live spoke in the Search Evolution pillar. It links back to its hub and across to neighboring spokes on AI search behavior. That is the cluster architecture working as designed.
Frequently Asked Questions
What is hub-and-spoke SEO?
Hub-and-spoke SEO is an internal linking model where one central hub page connects to multiple specific spoke pages. The hub targets a broad keyword and gives a high-level overview of the topic. Each spoke targets a narrower subtopic in depth and links back to the hub. Together they build topical authority that isolated posts cannot generate on their own.
How many spokes per hub do you need?
Eight to fifteen spokes per hub is the working range for most SaaS sites. The exact number is set by counting distinct search intents under the hub topic, not by a content quota. Below eight, the cluster lacks coverage. Above twenty without matching search demand, the effort spreads thin and dilutes cluster quality.
Topic cluster vs pillar page: what is the difference?
A pillar page is the single hub page at the center of a cluster. A topic cluster is the entire system: the pillar, all its spoke pages, and the internal links connecting them. The pillar is one component. The cluster is the architecture. Publishing only a pillar without spokes is the most common SaaS SEO mistake on this subject.
Should the hub or spokes go live first?
The hub. Designate the hub URL and publish at least a stub version before any spoke goes live, so every spoke has a canonical destination to link back to from day one. Retrofitting a hub onto a year of orphaned spokes wastes crawl budget and forces redirect chains that reset some of your earned link equity.
Where most SaaS clusters actually break
Most SaaS blogs we audit have the right ingredients in the wrong architecture: 80 posts, no hubs, a flat URL taxonomy, and traffic spread across pages that will never compound. If you want to know which clusters your existing content already supports and which ones are quietly leaking traffic, book a free SEO audit call. 30 minutes, specific findings, no slide decks.
