Topic cluster engineering: a quantitative approach.

Why "topic clusters" usually fail in practice

The HubSpot-era topic cluster model is intuitive: one pillar page, ten supporting articles, internal links between them. But intuition stops short of telling you how many links, which direction, which anchor text strategy, and how often. Most agencies hand-wave through these questions and call it a day.

Our team's background is half marketing, half engineering. When we onboarded our 30th client and saw the same vague advice churning out the same mediocre results, we did what we'd do with any other unsolved measurement problem: we treated the topic cluster as a directed graph and started measuring it.

The dataset: 74 clusters, 5,200 articles

Across 18 months of client work we instrumented 74 topic clusters totaling 5,200 articles and 38,000 internal links. For each cluster we logged: pillar URL, supporting URLs, link source/target/anchor, weekly traffic per URL, average position per URL, and content age. The data lives in our Postgres warehouse alongside the SERP scrape; we joined them weekly.

Then we built a graph for each cluster — pillar as the root node, supporting articles as children, internal links as edges — and asked: which graph properties correlate with traffic growth on the pillar over 6+ months?

Finding #1: There's an optimal link-density window

We expected "more links = more authority transfer" to hold linearly. It doesn't. Link density follows an inverted-U curve.

The sweet spot is 4-6 outbound internal links per supporting article, with at least one link to the pillar and the rest to peer supporting articles. Below 4, you're not transferring enough signal. Above 10, you start looking like an internal-link farm and Google's algorithms apparently de-weight the cluster as a whole.

Finding #2: Bidirectional links beat hub-and-spoke

The classic topic-cluster diagram shows links flowing inward to the pillar. Reciprocal links between supporting articles correlated more strongly with pillar growth than links from supporting to pillar.

Specifically: clusters where supporting articles linked to each other (peer-to-peer) at a 1:1 ratio with their pillar links saw 2.1x the pillar growth of pure hub-and-spoke clusters. The mechanism we hypothesize: bidirectional peer links signal a coherent topical neighborhood, which raises the topical authority of every node in the neighborhood, including the pillar.

This matches what we observe in AI engine citation patterns: AI engines cite clusters of related articles, not isolated pages. Building a coherent neighborhood pays off in both surfaces.

Finding #3: Anchor text diversity within a 3-5 phrase pool

Pure exact-match anchors ("topic cluster engineering" → pillar) underperformed. Random-phrase anchors also underperformed. The winning pattern was 3-5 anchor phrase variants used in rough rotation.

For the pillar URL of this very article, the anchors we'd use across the cluster are: "topic cluster engineering", "quantitative topic cluster model", "graph-theoretic content architecture", "internal link density", "how topic clusters transfer authority". That's the rotation. Each anchor variant gets used 18-25% of the time across cluster internal links.

Finding #4: Article age matters at the cluster level, not just the page level

Here's where it got interesting. We expected freshness to matter per article. It does — but the cluster-level median age mattered more.

Clusters where the median supporting article was older than 22 months showed declining pillar traffic regardless of how new the pillar itself was. Clusters with median age under 14 months grew. The implication: refreshing the pillar alone doesn't save a stale cluster. You have to maintain the supporting articles too.

This matches what we found in our AEO field report at the page level — AI engines de-weight content older than 14 months for time-sensitive topics. At the cluster level the same effect compounds.

Finding #5: Pillar word count plateaus at ~3,200 words

The "ultimate guide" school of thought says longer pillar = better pillar. Our data shows a plateau:

• Below 1,800 words: pillars underperform regardless of cluster quality
• 1,800-3,200 words: linear increase in performance
• 3,200-5,000 words: marginal increase, mostly noise
• 5,000+ words: no measurable benefit, slight increase in bounce rate

The takeaway: aim for 2,500-3,200 words on pillars. Push the depth into supporting articles. A 6,000-word pillar with 3 supporting articles loses to a 2,800-word pillar with 12 supporting articles, every time.

Finding #6: Update cadence — the "1/3 rule"

Across our 74 clusters, the highest-performing ones followed roughly the same update cadence: about 1/3 of supporting articles touched per quarter. Not full rewrites — micro-updates: refreshed examples, updated numbers, new sub-section, dated update block.

This produced a "rolling refresh" where, over 9 months, every article in the cluster had been touched at least once. We've automated this in client editorial calendars: every article carries a last_substantive_update field, the CMS sorts by it, and the editorial team works the queue from oldest first.

Putting the model into practice

Here's the operational checklist we now run for every cluster engagement:

1. Map the graph. Pillar at the center, 8-15 supporting articles around it. Sketch in actual node-edge form, not as a Notion list.
2. Set link targets. Each supporting article links to the pillar (1) and to 4-5 peer supporting articles. Pillar links back to 6-10 supporting articles, with descriptive anchors.
3. Define the anchor pool. 3-5 phrase variants per target. Document them. Enforce them in the CMS.
4. Set the word-count band. Pillar 2,500-3,200 words. Supporting articles 1,200-1,800 words.
5. Build the refresh queue. 1/3 of cluster touched per quarter, oldest first.
6. Instrument it. Track pillar traffic, average position, and supporting-article tail performance weekly. Re-cluster if any node decays past 6 months without recovery.

What this looks like in real client work

One of our SaaS clients had a sprawling 47-article "guide" structure with no clear pillar and inconsistent linking. Audit revealed median internal links per article was 1.2 (well below the 4-6 sweet spot) and median article age was 19 months. We restructured into three coherent clusters of 12-15 articles each, with explicit pillars, applied the linking model, and started a 90-day refresh queue.

Six months later: pillar traffic up 134%, supporting article tail traffic up 61%, AI engine citations (tracked via our AEO pipeline) up 4.2x. The detailed breakdown lives in our case studies.

Where this connects to the rest of our methodology

Topic clusters aren't a standalone tactic. They sit on top of the same content architecture decisions that drive long-tail TH performance, the same multilingual setup discussed in our hreflang guide, and the same query-intent research that powers our quarterly trend reports. Treat them as a system, not as separate projects.

Our content engineering service includes cluster mapping and the linking model as a default deliverable. If you want a one-off audit of your existing clusters against the framework above, email us or talk to SEO Agency Bangkok who run on the same data layer. For the technical CMS side, Bluewich can implement the link-density tracking and refresh queue as a custom dashboard.