How Many Cluster Articles Does a Pillar Need?
A topic cluster is not a checklist of “X supporting posts.” It is a map of unique intents around one parent topic: the pillar answers the broad question; each cluster page owns a narrower question people actually type. The right number is the number of those intents you can serve without overlapping, not a quota borrowed from someone else’s site.
When two URLs chase the same intent, they cannibalize. Rankings stall, internal links fight, and the pillar never becomes the obvious hub. When you stop at unique intent, every new URL adds a new door into the same topic—and the pillar can rank as the authoritative center.
This guide shows how to size a cluster from search demand, how keyword clustering and automation fit without flooding the site, and how to know when another article would hurt more than it helps.
- Count distinct search intents, not a fixed number of cluster articles per pillar.
- Each cluster URL should own one query family the pillar cannot fully satisfy.
- Overlapping intents cause cannibalization and weaken the hub page.
- Stop when leftover keywords are variants, not new jobs-to-be-done.
- Automation and programmatic SEO scale coverage only after intent is unique.
One Cluster Article Per Intent the Pillar Cannot Cover
The count starts from the pillar’s gaps. List the questions a hub-level page would bury or skip—comparisons, step-by-steps, audience-specific jobs—and give each of those a spoke. Anything the pillar already answers in full does not get a second URL.
A cluster article is a spoke with its own job. It answers a comparison, a how-to, a specific audience, or an objection. It is not a synonym, a modifier, or a lightly rewritten version of the pillar keyword. If two queries land on the same SERP intent, they share one spoke. If the pillar already ranks for that intent, you do not need another page.
Teams often treat a mid-size topic as needing a handful of supporting pieces as a planning default. Tight topics fall well below that; wide topics can run past it. Use any default only as a starting sketch, then let distinct intents—not a template—set the actual number. Keyword clustering and how to build a topic cluster belong in their own guides; this page stays on the count decision.
A completeness checklist is the wrong stop condition. If a spoke does not own a unique job the pillar cannot do, it splits crawls and relevance instead of adding another door into the topic.
The count — Count distinct SERP intents the pillar cannot satisfy—not synonyms, not a completeness checklist. Extra spokes dilute authority instead of compounding it.
Working ranges by how wide the topic actually is
Planning bands are sketches, not quotas. Once you treat each cluster URL as a job the pillar cannot finish, the useful starting range is simply how many distinct intents sit around the hub. For a narrow product or feature pillar—one SKU, one workflow, one tightly named capability—a short set of unique-intent articles is usually enough: a comparison, a setup or how-to, an audience-specific use case, and a couple of objections or alternatives. When the topic mixes education, comparison, and commercial research, the band widens, because more SERPs actually want different page types.
A hub can grow beyond a narrow set only if every extra URL still owns a different SERP. Count first: inventory the intents you see in SERPs and in real questions, then map leftovers onto pages you already have. Mint a new spoke only when nothing existing can honestly satisfy that leftover.
Crowded copies versus lean coverage
A crowded cluster looks busy and still underperforms: a stack of near-duplicate “best X for Y” posts, overlapping intros, and internal links that cannibalize each other. A lean cluster looks quieter: fewer URLs, each with a job the others cannot do—how it works, who it is for, how it compares, what to do when it fails. Coverage is the set of intents you own, not the number of files in the CMS. When leftover intents sit outside the topic boundary, a second pillar is usually healthier than stretching one page family until the hub can no longer speak with one voice.
Range, not target — Use a short set of spokes for a narrow pillar and a wider set when education, comparison, and commercial research mix—then stop unless each extra URL still owns a different SERP.
When to add another cluster article—and when to stop
Those ranges only tell you where to start. The live decision is whether the next leftover query deserves its own URL or belongs on a page you already have. Treat every candidate as a gate: if it fails, you do not publish.
Stop when remaining keywords are only modifiers of an existing page, when two drafts would target the same SERP, or when demand is too thin to justify maintenance. Prefer expanding or merging a current spoke over another lookalike. Every new spoke must also earn a two-way internal link with a unique anchor; if it cannot, it should not exist. How you wire those links is covered in the site’s cluster-and-links operating piece—the rule here is simply that a spoke without that link is a split, not coverage.
Add or stop — Add a cluster article only when it owns a different SERP and can earn a unique two-way link; otherwise expand, merge, or stop so authority compounds instead of splitting.
Scale cluster volume without multiplying thin spokes
That setup still leaves the scaling question. Once you know when to add a spoke and when to stop, the next pressure is volume—and the failure mode is specific. It is not generic “more content, less quality.” It is automation multiplying cluster articles that never passed the unique-intent test, so the pillar’s authority splits across lookalikes instead of compounding on distinct SERPs.
Treat templates and content automation as a drafting layer, not a quota machine. Run them only on intents that already survived the add-or-stop check: a leftover query, a different result set, a job the pillar cannot finish. Programmatic SEO belongs in the same gate. Use it to cover true entity-and-intent combinations—locations, products, audiences, comparisons that each own their own SERP—not a pile of rewrites of the same pillar question with swapped modifiers.
Before you publish the next cluster article, refresh underperformers and merge overlaps. Link equity on a hub is finite; a thin extra URL is a leak. If volume still needs to grow after that cleanup, split a new pillar at the topic boundary rather than stuffing one family past its intent map. Coverage then stays one spoke per distinct search job, and the cluster scales without becoming a pile of pages that compete with each other.
Scale rule — Scale only intents that already earned a unique SERP; automate drafts, not lookalikes—and split a new pillar before one hub’s map is stuffed.
Key Takeaways
Map leftover SERP intents against your pillar, keep only the spokes that own a different job, and publish the next cluster article that compounds authority instead of splitting it.