Topic Clusters for SaaS: Authority Without a Team

A topic cluster is one in-depth pillar page about a broad problem your software solves, surrounded by 8 to 20 narrower articles that each answer one specific question inside that problem, all linked to each other and back to the pillar. For a solo founder, the reason to build clusters instead of publishing whatever occurs to you on a Sunday is simple: ten connected posts about one subject tend to earn rankings that ten unconnected posts about ten subjects do not, because internal links pass relevance and context, and because you stop competing with yourself for the same query.

That is the whole idea. The rest of this guide is about how to do it when you are the only person who will ever write, edit, publish and measure it.

The short version, in order

1. Pick one cluster that sits between what your product does and what people search for. Not your product category. The problem your product removes.
2. Write the pillar as the definitive answer to the broad query, structured so each section can later become its own article.
3. Build the spoke list from real queries, grouped by intent, one URL per intent.
4. Publish spokes first or alongside the pillar, in a fixed order, at a cadence you can sustain for six months.
5. Link every spoke up to the pillar, link the pillar down to every spoke, and link spokes sideways when the connection is genuine.
6. Verify in Google Search Console at the cluster level, not the post level, and give it three to nine months.

Now the detail.

What a topic cluster actually is

https://www.youtube.com/watch?v=yzdwELHZFRM

Video: "Complete Guide to SaaS Content Topic Clusters Strategy" — Victor Eduoh (YouTube)

Photo: cambodia4kidsorg · BY

The vocabulary comes from HubSpot's marketing team, which popularized the pillar-and-cluster model in the mid 2010s, but the underlying idea is older and duller: search engines try to work out what a site is about, and a site that covers one subject thoroughly and coherently gives them more to work with than a site that covers twelve subjects thinly.

A cluster has three parts:

The pillar. One long page targeting the broad, high-volume, high-competition head term. Something like "invoicing for freelancers" or "SOC 2 compliance for startups." It is broad by design. It will not rank quickly. It exists partly to rank eventually and partly to be the hub that every other page points at.

The spokes. Individual articles targeting specific long-tail queries inside that topic. "How to write a late payment reminder email." "Do freelancers need to charge VAT on invoices to EU clients." "Invoice due date terms explained: net 15 vs net 30." Each one answers a single question completely. Each one can rank on its own within weeks or months because the competition on a five-word query is thinner than on a two-word query.

The links. Every spoke links up to the pillar with descriptive anchor text. The pillar links down to every spoke. Spokes link sideways to each other when a reader would genuinely want the other article. This is the part most people skip, and it is the part that turns a pile of posts into a cluster.

What a topic cluster is not

It is not a category page on your blog with an auto-generated list of posts. Tag archives are not pillars. They have no unique content, no argument, no reason to be ranked.

It is not ten articles with the same keyword stuffed into ten titles. That is keyword cannibalization with extra steps, and it is one of the most common ways small blogs quietly waste six months of work. If you are not sure whether you have already done this, here is how to find and fix cannibalization on a small blog.

It is not a guarantee. Clusters improve the odds. They do not override the fact that a three-month-old domain writing about "project management software" is bringing a spoon to an artillery duel.

Why clusters matter more for small SaaS sites than for big ones

Big sites can afford scattered content. They have enough domain authority that a random post about a random topic will pick up some traffic anyway. You do not have that. Everything you publish has to work harder, and the cluster structure is how you make ten posts behave like more than ten posts.

Four specific mechanics:

Internal links concentrate relevance. When eight pages about invoicing all link to your invoicing pillar with anchor text about invoicing, you are sending a fairly loud signal about what that page is for. Google's own documentation on crawlable links explains that links are how Google discovers and understands relationships between pages. Anchor text and link context are part of that understanding.

Long-tail spokes win before the pillar does. A new site almost never ranks for a head term. It can rank for "how to invoice a client in a different currency" within a couple of months if the article is genuinely useful and nobody else has answered it well. Those spokes bring in the first real traffic, and traffic to the cluster tends to help the cluster.

You stop splitting your own signals. Without a plan, founders write three near-identical posts about the same query over eighteen months, and Google picks one at random or none of them. A cluster map assigns one query family to one URL and forces you to notice the overlap before you write.

Depth is a plausible answer to the "why should this site be the answer" question. Google's creating helpful content guidance asks whether a site demonstrates first-hand or deep knowledge of a subject and whether the content is the kind of thing someone would bookmark or recommend. A site that covers one problem from twelve angles has a better story here than a site with twelve orphan posts.

There is a newer reason too. AI answer surfaces summarize and cite. If you want to be the source that gets pulled into an answer about a niche subject, being one of the few sites that covers that subject comprehensively is a reasonable strategy. We looked at how citation patterns are shifting in this piece on how AI tools recommend brands and cite other sites, and the practical takeaway lines up with clusters: coverage depth on a defined subject beats scattered coverage.

Step 1: Pick a cluster you can actually win

This is the step where most SaaS content plans go wrong, and it goes wrong in a specific way: founders pick their product category as the cluster.

You sell a lightweight CRM, so you decide your cluster is "CRM software." Your pillar is "The Complete Guide to CRM Software." Your spokes are "best CRM for small business," "CRM vs spreadsheet," "CRM features explained." Every one of those queries is defended by companies with content teams, link budgets and a decade of domain history. You will not win any of them this year. Possibly not next year either.

The winnable cluster sits one step to the side. Ask: what does someone have to be doing, dealing with or worried about immediately before they need my product?

The right-hand column has lower search volume per query. It also has far fewer well-funded competitors, and the people searching it are closer to your actual buyer than the people typing "best CRM" into Google at 11pm.

Practical filter: before you commit to a cluster, search five of its intended spoke queries. If the first page is entirely made of Forbes Advisor, G2, HubSpot and Zapier, pick a different cluster. If the first page contains a couple of Reddit threads, a forum, one thin blog post and something from 2019, you have found a gap.

If you have a raw keyword list and no idea how to group it into clusters, the mechanical process is covered in keyword clustering: turning a raw list into a publishing plan.

Step 2: Define the pillar properly

A pillar is not "a long post." It is the page you would send someone to if they said "explain this whole problem to me."

Three formats work reliably:

The complete guide. Covers the entire problem end to end, with each major section summarizing a spoke and linking to it. Typically 2,500 to 4,000 words. Works when the topic has a natural sequence.

The framework page. Presents your specific way of thinking about the problem, named and numbered. Works when the topic is messy and readers want a structure imposed on it.

The definitive resource. A comparison table, a decision tree, a benchmark set, a template collection. Works when the topic is factual rather than procedural.

What all three share: the pillar can be read on its own and is useful without clicking anything, but it also naturally invites you to click into the spokes for depth.

A concrete example. Say you make invoicing software for freelancers. Your pillar is not "Invoicing Software Guide." It is:

"Getting Paid on Time as a Freelancer: The Complete Guide"

Sections: setting payment terms before the work starts, what a legally sound invoice contains, when to send it, the follow-up sequence for late payments, when to escalate, when to stop working, currency and tax edge cases, and what to automate.

Each of those sections is 200 to 400 words on the pillar, ending with a link to a spoke that covers it in 1,500 words. The pillar is genuinely useful for someone who reads only it. It is also a table of contents for twelve future articles.

Write the pillar outline first even if you publish it last. The outline is your cluster map.

Step 3: Build the spoke list from real queries

Take each pillar section and find the questions people actually type about it. Sources that cost nothing:

• Google autocomplete, typing your section topic and cycling through the alphabet
• "People also ask" boxes, expanding two levels deep
• Related searches at the bottom of the results page
• Reddit and niche forums, searching your topic and reading how people phrase the problem
• Your own support inbox, sales calls and onboarding questions, which are the highest-signal source you own and the one founders forget
• Google Search Console, if you already have any pages ranking, filtered to queries with impressions but no clicks

Write everything down. You want 30 to 60 raw queries per cluster before you start grouping.

Here is what a mapped cluster looks like for the invoicing example, trimmed to twelve spokes:

Notice the last row. Every cluster needs at least one or two product-adjacent spokes, because that is where the cluster earns its keep commercially. More on that shortly.

Notice also that "best invoicing software" is not on the list. It could be added later, once the cluster has traction and the domain has some history. Starting there is how you spend three months producing a page that will sit on result page seven forever.

Step 4: One intent, one URL

Before you write anything, run the list through this rule: if two rows would satisfy the same searcher, merge them.

"How long to wait before chasing an unpaid invoice" and "when should I send a payment reminder" are the same intent. One article. Pick the better title, list the other phrasing as a subheading inside it.

"Late payment interest: what you can legally charge" and "late payment email templates" are different intents. One is a legal question, one is a copy question. Two articles.

Write the decision down in a spreadsheet with a column for the canonical URL. When you have a new idea in month four, you check the sheet first. This single habit heads off the most common self-inflicted SEO wound on founder blogs.

Step 5: Sequencing, or what to publish first

The instinct is to write the pillar first because it feels foundational. The better move for a small site is usually to publish three to five spokes first, then the pillar, then keep adding spokes.

Reasons: spokes are shorter and faster to write, which matters when your writing budget is Sunday evenings. Spokes can rank sooner, which gives you data and motivation. And a pillar published on day one with no spokes to link to is a page with nowhere to send anyone.

A cadence that works for one person:

That is roughly 23 articles in six months, one cluster, done. One per week is not heroic. It is also more than most founder blogs manage, because most founder blogs stop at post three. The reasons that happens are predictable, and worth reading before you commit: 11 reasons founders abandon their blog after three posts.

If four articles a month is not realistic by hand, be honest about that now rather than in month two. Two per month with a system that survives beats four per month for six weeks followed by silence.

Step 6: The linking rules that hold up at 60 posts

Internal linking is where clusters live or die, and it is also the part that decays fastest, because linking is retroactive work. Post 4 cannot link to post 19. Post 19 can link to post 4, but only if you remember post 4 exists.

Four rules that scale:

Rule 1: Every spoke links to the pillar, high on the page. Somewhere in the first third, with descriptive anchor text that includes the pillar's target phrase. Not "click here." Not "our guide." Something like "getting paid on time as a freelancer."

Rule 2: The pillar links to every spoke, in its relevant section. When you publish a new spoke, you go back and add the link to the pillar the same day. This is a five-minute task that you will skip unless it is on a checklist.

Rule 3: Spokes link sideways only when the reader benefits. Three to five outbound internal links per spoke is a reasonable range. Twenty is a link farm and reads like one.

Rule 4: New posts link back; a monthly pass links forward. Once a month, open your three or four oldest posts and add links to anything newer that is genuinely relevant. Fifteen minutes. This is the compounding part.

The full system, including anchor text patterns and how to avoid orphan pages, is written up in internal linking for blogs: a simple system that compounds.

One structural note: keep spoke URLs shallow and flat, like /blog/late-payment-email-templates, rather than nesting them under the pillar path. Nested paths are not required for clusters to work, and flat URLs are easier to move around later when you reorganize, which you will.

Step 7: Connect the cluster to the product without ruining the articles

A cluster of purely informational posts can bring traffic and produce nothing. The fix is not to jam CTAs into every paragraph. It is to design two or three spokes as the commercial floor of the cluster.

Three types work:

The "how to do this manually" post. Explain the manual process honestly and completely. At the end, note where it becomes tedious at scale, and mention that this is what your product handles. Readers who do it manually and hate it come back.

The "what to automate" post. Explicitly about tooling. Fair comparison, including doing nothing and using a spreadsheet. Your product appears as one legitimate option, with its limits stated.

The alternatives or comparison post. "X alternatives" and "X vs Y" pull in people already shopping. These convert well and rank harder, so publish them once the cluster has some footing rather than on day one.

The other spokes carry a single soft mention, usually a one-line note in context or a link in the closing paragraph. That is enough. A reader who arrives from "late payment interest rates" is not in a buying frame of mind, and pretending otherwise makes the article worse without making the sale.

Expect the traffic-to-signup ratio to be lopsided. Informational spokes drive volume and links. Two or three commercial pages drive most of the conversions. That is normal and it is why you build both.

Step 8: Verify at the cluster level, not the post level

This is where founders lose their nerve, usually around week six, when post one has 11 impressions and 0 clicks and the whole exercise feels like performance art.

Set the measurement frame before you start.

Use Google Search Console, filtered. In the Performance report, filter pages by a URL pattern that matches your cluster, or tag them manually in a sheet. You are looking at the cluster as one unit. Individual post variance is noise.

Watch these in order:

Those windows are typical for a newer domain in a normal niche, not a promise. A domain with existing authority moves faster. A brand new domain in a saturated niche moves slower, sometimes much slower. We went through the evidence and the realistic ranges in how long it takes for a new blog to rank on Google.

The single most useful early metric is impressions, not clicks. Impressions mean Google is showing your page for something. Position 42 with rising impressions is a page on its way up. Zero impressions after eight weeks is a different problem entirely, usually indexing, thin content, or a query nobody searches.

The second most useful is query diversity. A healthy cluster starts collecting impressions on queries you never targeted. When your "net 15 vs net 30" article starts appearing for "what does payment due on receipt mean," the topical relevance is working.

Sanity check with the site query. Searching site:yourdomain.com plus a spoke's target phrase tells you which of your pages Google associates with that phrase. If three of your pages show up and they are all trying to be the answer, you have cannibalization to fix.

Common ways clusters fail

The cluster is too big. Forty planned spokes, four published, abandoned. Cap the first cluster at 12 to 20 and finish it before starting a second.

The pillar is a listicle. "10 Tips for Getting Paid on Time" is not a pillar. It cannot host twelve subtopics. Pillars need structural room.

No links were ever added. The posts exist, none of them reference each other, and the site is a pile of orphans. This is the most common failure and the easiest to fix.

Every post has the same intent. Twelve "how to" posts and no comparison, no template, no definition, no decision framework. Search results for one topic usually contain multiple content types. Match them.

The spokes are 600 words of paraphrased consensus. If your article says exactly what the top three results say in slightly different words, there is no reason for it to outrank them. Add something they lack: the actual numbers, the edge case, the template, the thing you learned from customers.

Publishing stops after the pillar. The pillar is not the finish line. It is the middle.

Doing this without a content team

Photo: Rawpixel Ltd · BY

Here is the honest arithmetic. A cluster of 20 articles, done properly, is 20 keyword decisions, 20 outlines, 20 drafts of 1,200 to 2,000 words, 20 edits, 20 sets of internal links, and 20 CMS uploads with formatting and metadata. Call it 4 to 8 hours per article if you write reasonably fast and know the subject. That is 80 to 160 hours.

You have three options.

Write it yourself. Cheapest in money, most expensive in the thing you have least of. Works if you genuinely enjoy writing and can protect two blocks a week for six months. Most founders think they can and then ship a fundraise, a migration and a support fire in the same month.

Hire freelancers. Quality is available, and briefing a good writer on your niche is real work. Rates vary widely by market and experience; we broke down what the ranges actually look like in how much a freelance SEO article costs in 2026. For a 20-article cluster the total is usually a four-figure number, sometimes a large one, and you still own the keyword planning, the linking and the publishing.

Automate the production and keep the judgment. This is where AI writing tools sit, and their quality varies enormously depending on whether they plan at the cluster level or just generate articles one at a time from a keyword list. Bulk generators will happily produce 50 articles that overlap each other and link to nothing, which is cannibalization at industrial scale. The tools worth considering handle topic planning, internal linking and publishing, not just drafting. There is a survey of the category in the best AI blog automation tools.

Worth saying clearly since it is the question underneath the question: Google's documentation does not prohibit AI-assisted content. Its guidance is about whether content is helpful, original and people-first regardless of how it was produced, and its spam policies target content produced primarily to manipulate rankings. We covered the exact wording in is AI-generated content bad for SEO. The practical reading: automation is fine, unreviewed slop is not.

That distinction is the reason Rankody works the way it does. It researches your market, plans a cluster of winnable topics rather than a random keyword dump, writes the long-form drafts, and pushes them to your CMS once you approve them. You stay in the loop where judgment matters (does this claim about our product hold up, is this the angle we want) and out of the loop where it does not (formatting, metadata, remembering to link post 19 back to post 4). Setup is one time. It is priced as a single flat plan that costs less than commissioning one freelance article, which is roughly the point: the constraint on founder blogs is almost never ideas, it is the 100 hours of production between the idea and the published cluster.

If you want to see how that compares against the closest tool in the category, there is a direct breakdown in SEObot vs Rankody, and a broader look at running the whole thing hands-off in the guide to putting your blog on autopilot.

A 30-day starting plan

If you want to begin this week rather than think about it for another quarter:

Days 1 to 3. Pick the cluster. Write down the problem your product removes, list five adjacent problem areas, search five spoke queries from each, and choose the one where the results page looks weakest.

Days 4 to 7. Build the raw query list. Autocomplete, People Also Ask, Reddit, your support inbox. Aim for 40 queries. Do not filter yet.

Days 8 to 10. Group into 12 to 20 spokes, one intent per row, in a spreadsheet with columns for title, target query, intent, status and URL. Sketch the pillar outline from the section headings.

Days 11 to 30. Publish four spokes. Highest priority first. Each one links up to the (not yet published) pillar URL, which you decide in advance so the links are already correct when the pillar goes live.

Day 30. Open Search Console. Confirm all four are indexed. Ignore positions. Set a calendar reminder for day 90.

Then keep going. The compounding does not start in month one, and the whole reason clusters beat scattered posts is that the twentieth article makes the first nineteen work better. That only pays off if the twentieth article exists.

Frequently asked questions

How many spokes does a cluster need before it works? There is no threshold number, but the pattern most small sites see is that things start moving somewhere between 8 and 15 well-linked spokes. Under five, you have a few posts. The internal link graph is too sparse to do much.

Should the pillar target the highest-volume keyword? Usually yes, within reason. The pillar should target the broadest term you have any long-term hope of ranking for. If that term is "project management software," pick something narrower. The pillar is your ceiling, not your fantasy.

Can one site have multiple clusters? Yes, and eventually it should. Finish the first one first. Two half-built clusters are worse than one complete one, because neither reaches the density where linking matters.

What about updating old spokes? Budget one refresh pass per quarter. Add links to newer posts, update anything factually stale, expand sections that are drawing impressions but no clicks. Refreshing an existing page that already ranks in positions 8 to 20 is often better value than a new post.

Do I need backlinks for a cluster to work? They help, and pillars are the natural target for them because a genuinely comprehensive resource is more linkable than a 900-word how-to. But clusters produce results on internal linking and topical depth alone on lower-competition queries, which is exactly why the winnable-cluster selection in step one matters so much.

Where does this leave AI search and zero-click results? Answer engines still need sources, and being the site that covers a narrow subject thoroughly makes you a more likely one. It does change what you optimize for, since some informational queries now get answered in the results page. The practical adjustments are in how Google AI Overviews change blog traffic. The short version: clusters that include templates, comparisons, calculators and decision frameworks hold up better than clusters made entirely of definitions.