The pattern that holds up at scale is a genuine sub-hierarchy, clusters of clusters, rather than one pillar page linking directly to 200 flat spoke pages. A single pillar has a practical ceiling on how much on-page internal linking remains useful before individual links carry negligible weight and the page itself becomes an unreadable directory rather than a page that genuinely represents the topic. Introducing sub-pillars beneath the main pillar preserves a clear, traversable hierarchy at any scale, which matters both for users trying to navigate and for Google’s systems trying to parse how the pages relate to each other.
Why flat scaling breaks down
At 10 pages, a single pillar linking out to every spoke works fine. The pillar page reads naturally (a genuine overview with links to each subtopic), each spoke is one click from the pillar, and the link list on the pillar page is short enough to be a real piece of content rather than a wall of links. Google’s internal linking documentation is clear that internal links carry context and help establish relative importance and relationship between pages, and at this scale that mechanism does exactly what it’s supposed to.
At 200 pages, the same structure collapses under its own weight. A pillar page listing 200 links stops functioning as content and starts functioning as a sitemap. Each individual link, diluted among 199 others, carries a fraction of the contextual weight it did when there were only 10. Users scanning the pillar page can’t meaningfully evaluate 200 options, so the page fails at its actual job, helping someone find the right subtopic, well before it fails at any ranking mechanism. And a page that reads like an auto-generated link dump is a weak candidate to rank for the pillar-level query itself, since it no longer looks like a genuine, useful overview.
The sub-hierarchy pattern
The fix is to introduce an intermediate layer: instead of Pillar to Spoke-1 through Spoke-200, the structure becomes Pillar to Sub-Pillar-A/B/C/D (each covering a genuine sub-grouping within the topic) to the individual spokes beneath each sub-pillar. A reasonable shape looks like this in prose:
- Top-level pillar covers the overall topic at a genuinely broad level and links to a manageable number of sub-pillars, each representing a real, independently coherent sub-theme within the topic (not an arbitrary bucket invented just to split the count).
- Sub-pillars each cover their sub-theme in enough depth to justify their own existence and independent ranking potential, and link out to a manageable number of individual spoke pages within that sub-theme.
- Spoke pages answer the specific, narrow questions within their sub-theme, and link back up to their sub-pillar and laterally to closely related spokes within the same sub-theme, not across the whole 200-page cluster.
This keeps every layer of the hierarchy at a link count that still carries real contextual weight, typically somewhere in the range of a handful to a couple dozen links per page depending on the topic’s natural breadth, rather than one page trying to represent 200 relationships at once. It also means the pillar page’s job stays honest: it’s still a genuine overview a human would find useful, not a directory.
A concrete example makes the shape easier to picture. Take a topic like “commercial insurance,” scaling from a handful of pages to well past 200. At 10 pages, a single pillar covering commercial insurance broadly can link directly to spokes on general liability, workers’ comp, commercial auto, and a handful of others, and that pillar page reads fine as an overview. Once the site has built out full coverage, workers’ comp alone might have 40 spoke pages (state-specific requirements, claims process, disputed claims, coverage minimums by industry, exemptions), commercial auto might have another 30, general liability another 35, and so on across a dozen distinct insurance lines. At that point the top-level pillar shouldn’t try to link to all 200-plus spokes directly; it links to a sub-pillar for each insurance line (a “workers’ compensation insurance” sub-pillar, a “commercial auto insurance” sub-pillar), and each of those sub-pillars carries the direct links to its own 30-40 spokes. The top pillar’s link list stays around a dozen entries, one per insurance line, each one a real, weighted recommendation, and the sub-pillar layer absorbs the count that would otherwise have overwhelmed a single page.
Preventing pillar authority dilution specifically
The concern behind the question, that a pillar’s authority gets diluted as the cluster grows, isn’t really about a fixed pool of “authority” being spread thinner (Google has never confirmed a discrete finite-authority mechanism working that way). It’s more concretely about two things: link context weight per link declining as link count grows on a single page, and the pillar’s own on-page content losing focus if it tries to summarize 200 subtopics instead of describing the sub-hierarchy at a reasonable level of abstraction. The sub-pillar pattern solves both: the top pillar’s direct link list stays short (proportional to sub-pillar count, not spoke count), and its on-page content can genuinely describe the topic’s major sub-themes without cramming in every individual spoke.
Practical guidance
When a cluster is still under roughly 20-30 pages, a flat pillar-to-spoke structure is usually fine and adding sub-pillars prematurely just adds unnecessary hierarchy. Once a cluster’s natural subtopics start exceeding what a single overview page can meaningfully list and describe, that’s the signal to introduce a sub-pillar layer, grouped around genuine sub-themes the audience would recognize, not arbitrary alphabetical or numerical splits. Keep spoke-to-spoke lateral linking scoped to the sub-pillar’s own group rather than cross-linking the entire 200-page cluster indiscriminately, and make sure every pillar and sub-pillar page still reads as a genuinely useful piece of content on its own, not merely a navigation aid. There’s no Google-confirmed link count threshold where dilution kicks in; the practical test is whether a human landing on the pillar page could actually use it to find what they need, and whether each page’s link list is short enough that every link still represents a real, weighted recommendation rather than one entry in an exhaustive index.
Handling clusters that grow past two layers
Some topics are broad enough that even a two-layer hierarchy, pillar to sub-pillar to spoke, isn’t enough once the cluster keeps expanding. If a sub-pillar itself starts accumulating so many spokes that its own link list becomes unwieldy (the workers’ comp sub-pillar growing from 40 spokes to 100 as the site adds state-by-state and industry-by-industry pages), the same logic applies again: introduce a third layer beneath that sub-pillar rather than letting any single page’s link list balloon past the point where it’s still readable and genuinely useful. In practice this looks like a sub-pillar splitting into state-level groupings, each with its own short page linking to the specific spokes for that state. The general principle scales indefinitely: whenever a page’s outbound link list within the cluster grows past what a human would actually read through and use, that’s the signal to add another layer beneath it, not to keep flattening everything into one page’s link list. Sites rarely need more than two or three layers of sub-hierarchy even at several hundred pages, because the branching factor compounds quickly (a dozen sub-pillars times a few dozen spokes each already covers a few hundred pages cleanly).
It’s also worth being deliberate about what triggers a new sub-pillar versus what just becomes an additional spoke under an existing one. A new sub-pillar is warranted when the sub-theme is substantial enough to support its own broad, moderately-searched query in its own right, something people would plausibly search for at that level of generality, not just a convenient bucket for organizing the site’s file structure. If a proposed sub-theme can’t support genuine standalone search demand at the sub-pillar level, it’s usually better folded in as a spoke under a neighboring sub-pillar, or as a section within an existing sub-pillar’s page, rather than given its own sub-pillar that ends up thin and mostly functioning as a redirect layer.
