A topic cluster strategy for 2026: pick 3 to 7 deep clusters, map each post to a real buyer question, and sequence 30+ posts so authority compounds.
Every "topic clusters 101" post explains what a cluster is. Almost none tell you which three to seven to actually commit to, how to map each article to a real buyer question, or in what order to publish thirty-plus posts so authority compounds instead of scattering. That is the planning layer this post covers. If you have not read the primer, start with SEO for SaaS, which introduces clusters at a high level; this post is the selection and sequencing work underneath it.
A cluster is not a folder of loosely related posts. It is a pillar page and a set of supporting articles deep enough, and linked densely enough, to own a subject in Google's eyes and in a reader's head. Fifteen shallow clusters do neither. Seven deep ones do both.
HubSpot's own topic-cluster guidance makes the same call: pick subjects "broad enough to anchor a pillar page and support 20 to 30 supporting articles," and "three to five pillar candidates is a good number to start with" (HubSpot). We widen that slightly to three to seven, because a git-based pipeline can sustain a bit more volume than a manual content team, but the underlying math does not change. Depth beats breadth, every time we have tested it.
Three numbers define depth, and all three have to be true at once:
The scattering mistake looks productive while it is happening. You spot an opportunity, write a pillar page, get excited about an adjacent topic, start a second pillar, then a third. Six months in you have five pillars with four posts each and zero clusters that meet the depth bar above.
Each half-built pillar competes for the same publishing budget, the same internal links, and the same founder attention. None of them ever crosses the threshold where the cluster effect kicks in, so none of them compound. You end up with twenty posts and the search visibility of five. This is the exact pattern Google's scaled content abuse policy targets from the other direction: pages "generated for the primary purpose of manipulating search rankings and not helping users," regardless of who or what produced them (Google Search Central). Volume without a real buyer question behind each post, and without enough depth in any one place to actually help someone, is the failure mode from both directions at once.
Picking clusters is a filtering exercise, not a brainstorm. You will generate a dozen or two candidate pillar topics in an afternoon. The discipline is in cutting most of them before you write anything.
Score every candidate on three axes and multiply, do not average, because a zero on any axis should zero out the whole cluster:
| Axis | Question it answers | Kills the candidate when |
|---|---|---|
| Demand | Do enough people actually search this, across the cluster's likely 20 to 30 posts? | The whole topic is a handful of low-volume terms with no room to grow |
| Right to win | Can a domain your age realistically rank here in 6 to 12 months? | Every result on page one is a decade-old incumbent with an unrelated moat |
| Buyer proximity | Does this cluster sit near a real purchase decision for your product? | The topic is popular but has nothing to do with why someone would buy from you |
A cluster that scores well on demand and right to win but poorly on buyer proximity will get you traffic that never converts. A cluster with high buyer proximity but no demand gets you nothing to rank. You need all three.
The cut has to happen before the first post, not after the tenth. Once a pillar page is live, the sunk cost makes it painful to abandon, and that is exactly when scattering sets in.
Write the one-paragraph case for each candidate cluster: who searches it, why they buy because of it, and where the domain-level gap sits versus competitors. If you cannot write that paragraph honestly, do not add the cluster. Three strong clusters you finish will outperform seven half-built ones every time, and finishing is the entire point of narrowing the list this early.
Once a cluster is chosen, the next job is not "what keywords should we target." It is "what does our buyer actually ask, at every stage between not knowing us and choosing us." Keywords are a proxy for that; the questions are the real object.
The best question lists are not invented at a desk. They come from four sources you likely already have:
Cross-reference all four against your cluster's scope. A question that shows up in two or more sources is a strong signal it belongs in the cluster; a question that only shows up once might be a keyword variant in disguise, which brings up the next filter.
The most common way founders overbuild a cluster is writing a new post for every keyword variant instead of every distinct intent. "How to reduce churn," "reduce SaaS churn," and "lower customer churn rate" are the same question asked three ways, not three posts. Merge them into one article that targets the intent, and let it rank for all three phrasings.
Two posts targeting the same intent inside one cluster (or, worse, across two different clusters) is keyword cannibalization: your own pages compete for the same position instead of each owning a distinct piece of the map. We cover the detection and the fix in how to find and fix keyword cannibalization; the cheapest prevention is simply never assigning two briefs to overlapping intent in the first place.
A question map tells you what could be written. A gap analysis tells you what to write first, by comparing your coverage against competitors who already rank.
Ahrefs' documented content gap workflow pulls the keywords your competitors rank for that you do not, filters that list down by minimum search volume and a difficulty ceiling, then splits what is left into two action types (Ahrefs):
Treat the two differently. A domain-level gap becomes a new brief inside the cluster it belongs to. A page-level gap becomes a task for the post that already exists, which is the same content-decay work described in content refresh strategy 2026: the fix is often a section added to a post you already published, not a new one.
A gap list sorted by search volume alone will point you at terms you cannot win for another year. Filter every gap by the same right-to-win test from the scoring table above before it earns a slot in the backlog. A domain-level gap with real volume and a difficulty score your domain can realistically climb is the highest-ROI post in your entire backlog: it is proven demand, no internal cannibalization risk, and a real shot at ranking within a reasonable window. Write those first, inside whichever of your 3 to 7 clusters they belong to.
Selection tells you what to write. Sequencing tells you in what order, and order is where most 30-post plans quietly fail even after picking the right clusters.
The pillar page ships first in every cluster, before any of its supporting posts. Every article you publish after it links up to that page, so the pillar needs to exist as a link target from day one. Writing supporting posts before the pillar means going back to insert links retroactively into every one of them, which is exactly the retrofitting problem the next section covers.
After the pillar, ship the single highest-intent supporting post, the one closest to a buying decision, second. That gives the cluster a conversion anchor early instead of waiting twenty posts to answer the question that actually moves a reader toward your product.
One post per week, per active cluster, is sustainable for a solo founder running an automated pipeline; two is a stretch most people cannot hold past the first month. At one post a week, a 20-to-30-post cluster takes five to seven months to complete, which lines up with the six-to-twelve-month window most sources, including HubSpot's own restructuring, describe for topical authority to show up as a slope rather than a step (HubSpot).
That HubSpot case is worth citing directly: when the company restructured more than 12,000 posts, including roughly 2,500 on the Sales blog alone, around the pillar-cluster model, it reported steady month-over-month gains in first-page rankings and hundreds of keywords climbing toward page two and three, explicitly framed as compounding, not an overnight jump. As HubSpot's senior content strategist Leslie Ye put it: "basic SEO practices get you on the field. Topic clusters help you level up" (HubSpot). That is the annuity this whole exercise is buying: not a spike, a slope that keeps paying out.
Running three clusters at once at that cadence means roughly three posts a week across the whole blog, which is a realistic ceiling for one founder with an automated writer, and a brutal one without.
Link every new post into its cluster the moment it ships: up to the pillar, across to one or two siblings, and back from the pillar to it. Waiting until post 25 to "do the linking pass" means auditing every prior post by hand to find where the new one fits, which is the exact tedium that makes teams skip linking altogether. Semantic SEO automation covers how to automate the mechanical half of this, finding entity overlap and gap coverage across a growing blog; this post is the judgment call above it, deciding which clusters and which posts earn a slot in the first place. Do both and a 30-post plan does not need a linking sprint at the end, because there is nothing left to retrofit.
Three signals tell you a cluster is compounding, and all three show up in Search Console before they show up in your revenue numbers.
Impressions rise across the whole cluster, not just the pillar page. If only the pillar gets impressions and the supporting posts stay flat, the links between them are not doing their job. Average position on the supporting posts climbs even before clicks do, since position moves first and clicks follow once a post clears the top few results. And the pillar page starts surfacing for queries you never wrote a post about, which is Google reading the whole cluster as one topic rather than a stack of separate pages.
Only add an eighth cluster once two or three of your existing ones show all three signals for at least a couple of months running. Every AI answer engine assembling a response now works by breaking a question into sub-queries and pulling from multiple related pages to build it, what Google calls a "query fan-out" technique: "Both AI Overviews and AI Mode may use a 'query fan-out' technique, issuing multiple related searches across subtopics and data sources, to develop a response" (Google Search Central). A connected cluster feeds that process; one isolated post cannot. Adding a new cluster before the existing ones reach that density just splits your publishing budget and your internal links across more unfinished territory, the same scattering mistake this post opened with, at a later and more expensive stage.
If you are weighing whether to run this whole process by hand or hand it to a pipeline, the honest answer is that the strategy work, scoring clusters, mapping intent, calling the gap analysis, deserves a founder's judgment. The mechanical half, drafting each post, linking it into the cluster, fact-checking it, and opening it as a pull request, is exactly what we built Lyra to take off your plate. We describe the traffic outcome one connected, sustained approach produced for us in why we built Lyra.
Picking the right 3 to 7 clusters is judgment; publishing 30 connected posts inside them without losing the thread is a pipeline problem. Lyra writes each post in your cluster, links it into the ones you already have, fact-checks the claims, and opens a pull request you merge.
Step by step
Score candidate clusters
Rate each candidate pillar on demand, your right to win it, and how close it sits to a buyer decision. Cut anything that scores low on two of the three before you write post one.
Map the question landscape
Pull real questions from support tickets, sales calls, Search Console queries, and People Also Ask. One post per distinct buyer intent, not per keyword variant.
Run a gap analysis
Split competitor keyword gaps into domain-level (topics you don't cover at all) and page-level (a thinner page you already have), then filter both for winnable difficulty before ranking your backlog.
Sequence the publishing order
Ship the pillar first, then the highest-intent supporting post, then round out the cluster. Cross-link every new post into the cluster as you go instead of retrofitting it at post twenty-five.
FAQ
Three to seven, not fifteen. HubSpot's own topic-cluster guidance recommends starting with three to five pillar candidates. Each cluster needs 15 to 30 supporting posts before it carries real weight, and a solo founder's pipeline cannot feed more than a handful of clusters that deep at once.
A content calendar answers when to publish. A topic cluster strategy answers what to publish and in what order, so each post links to a pillar and its siblings instead of shipping as an unconnected, orphaned article.
Watch three signals in Search Console: impressions rising across the whole cluster (not just the pillar), average position on supporting posts climbing even before clicks do, and the pillar page picking up new ranking queries it never targeted directly. That last one is the cluster effect showing up.
Only after your existing clusters show the compounding signals above for at least two to three months. Adding a cluster too early splits the internal links and the publishing cadence that made the first ones work, which is the same scattering mistake at a later stage.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Tell us about your blog and the founder will walk through it with you.
Keep reading
Pricing page SEO: how to structure prices so AI Overviews and ChatGPT quote them right, plus the verification habit that stops a cited price going stale.
The exact content structure that gets pages cited by AI: the answer block, self-contained chunks, definition callouts, and the byline, run as a checklist.
A content refresh strategy for 2026: detect content decay in Search Console, refresh 2-4 sections, re-verify every fact, and ship it as a quarterly PR.