Topic Cluster Too Shallow to Rank for the Pillar

Q: How do I find articles that should link to the pillar but don't?

Use Google Search Console -> **Links -> Internal links** and check the pillar's inbound count, then cross-reference a full-site crawl (Screaming Frog or Sitebulb) to list topically-related pages that don't link to it. Add contextual links from those pages.

1 pillar + 2 supporting articles isn't a cluster — it's a stub. Real clusters run 8-12 supporting pages, ship over 2-3 months, and link bidirectionally. Here's how to design, build, and wire one.

Published: May 19, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

TL;DR: A pillar plus 2 supporting articles is a stub, not a cluster. The fastest fix is to commit to depth: a practical floor of 8-12 supporting pages per pillar (HubSpot frames pillars as broad enough to anchor many subtopics, and practitioner guidance as of June 2026 puts a useful starting band at roughly 8-15), each targeting a distinct sub-intent, shipped steadily over 2-3 months, with bidirectional internal links (pillar links down to every supporting page; each supporting page links up to the pillar plus 2-3 sibling pages). Then wait 6-12 months — topical authority compounds slowly.

You read about “topic clusters” in an SEO guide and built one: a 4,000-word pillar on “Claude API,” plus 2 supporting articles. Six months later the pillar ranks at position 32, the two satellites rank 60+, and none gets meaningful traffic. The strategy isn’t wrong. The problem is that 1 pillar + 2 satellites isn’t a cluster — it’s a stub.

Topical authority is a function of coverage breadth and depth. Industry guidance in 2026 converges on 8-12 supporting articles per pillar; a site with ~20 interconnected articles on a topic routinely outranks a single 5,000-word guide, even a technically superior one. Below: how to design the cluster, ship it over 2-3 months, wire it bidirectionally, and avoid the “treat clustering as a checkbox” failure that produces stubs.

Which bucket are you in

Diagnose before you build. Most shallow clusters fail for one of six reasons, ordered by how often they’re the culprit.

#	Cause	Fastest signal to check	Fix
1	Named the strategy, never committed the volume	Pillar has 2-3 supporting pages, no growth in 3+ months	Steps 1-2: brainstorm + ship 8-12
2	Editorial calendar moved on mid-cluster	Supporting pages cluster around one publish month, then nothing	Step 2: resume the cadence
3	Existing related articles don’t link to the pillar	Pillar URL appears in few/no related articles’ internal links	Steps 4-5: wire the links
4	Supporting pages target the same intent as the pillar	Pillar + satellites have near-identical titles / same primary query	Step 3: differentiate intent (or consolidate)
5	Satellites don’t link to each other	Satellite-to-satellite link count is mostly 0	Step 5: add sibling links
6	Pillar is too broad	Pillar tries to cover 4+ distinct user intents	Split into 2-3 narrower pillars

If you’re not sure which bucket applies, the detailed breakdown below has a “how to spot it” check for each.

Common causes

1. “Pillar / cluster” adopted as a buzzword without committing to volume

You read about clusters, published a pillar + 2 quick satellites, and called it done. The model assumes 8-12 supporting pages; you stopped at 2.

How to spot it: Pillar has 2-3 supporting articles and hasn’t grown in 3+ months. The strategy was named but never resourced.

2. Editorial calendar moved on before the cluster was complete

You shipped the pillar in January and 2 satellites in February — then March’s calendar moved to a different topic. The cluster never got finished.

How to spot it: Supporting articles bunch around one publish month, then stop. Classic editorial-calendar drift.

3. Existing articles aren’t internally linked to the pillar

You may already have 8 articles on Claude sub-topics, written before “pillar/cluster” was a strategy. None of them link to the pillar. The cluster is mechanically present but not connected.

How to spot it: Open Google Search Console -> Links -> Internal links, find the pillar URL, and check its inbound internal-link count. If most of your topically-related pages don’t point at the pillar, the cluster isn’t wired. A crawl (Screaming Frog, Sitebulb) confirms it page by page.

4. Supporting articles target the same sub-intent as the pillar

Pillar is “Claude API guide.” Satellites are “Claude API tutorial” and “Claude API how-to.” All three chase the same query — they cannibalize rather than complement. (See Cluster overlap / keyword cannibalize.) As a rule of thumb, if a supporting page ranks for the same primary keyword as the pillar, it’s cannibalizing and should be re-scoped or consolidated.

How to spot it: Pillar and satellites share similar titles and target the same broad query. In Search Console, two of your URLs surface for the identical query — designed overlap, not designed complement.

5. Satellites don’t link forward to each other

Pillar links to satellite A, which links back to the pillar. Pillar links to satellite B, which links back to the pillar. A and B never link to each other. The cluster is a hub-and-spoke without a web.

How to spot it: Crawl satellite-to-satellite link counts. If they’re mostly 0, the cluster is undirected on the satellites’ side.

6. The pillar is too broad

Pillar is “Everything about Claude” — covering API, web app, mobile app, and enterprise. Each of those deserves its own pillar. The current page is too horizontal, so no satellite can link to it credibly.

How to spot it: The pillar attempts 4+ distinct user intents. Split it into 2-3 narrower pillars instead.

Shortest path to fix

Ordered by ROI. Step 1 designs; Steps 2-3 build; Steps 4-6 connect.

Step 1: Brainstorm 15-20 sub-topics real readers ask

For your pillar topic, list what readers actually want. You won’t write all of them, but you need a roadmap:

Pillar: Claude API

Real sub-topics (questions readers ask):
1. Authentication / API keys
2. Rate limits + retry logic
3. Streaming responses
4. Tool use / function calling
5. Prompt caching for cost
6. Batch API for bulk jobs
7. Vision / image input
8. Computer use
9. Token counting + cost calculation
10. Comparison with OpenAI API
11. Migrating from OpenAI
12. Error codes + troubleshooting
13. Best practices for production
14. Choosing a model (Sonnet vs Haiku vs Opus)
15. Common pitfalls
16. Webhook integration patterns
17. Building agents on top
18. PDF / document input
19. JSON mode / structured outputs
20. Latency optimization

15-20 candidates gives you a backlog you can sequence.

Step 2: Publish 8-12 supporting articles steadily over 2-3 months

Don’t dump all of them in a week — a batch publish looks generated and gives weaker freshness signals. Pace it:

Week 1:    pillar
Week 2-12: 1-2 satellites per week  (target 8-12 total)

A steady cadence signals an actively-developed cluster. If your topic is competitive, plan for the upper end of the range (or more); 2026 guidance is clear that depth beats breadth — three deeply built clusters outperform ten shallow ones.

Step 3: Each satellite targets a distinct sub-intent

Each supporting article should:

- Have a primary keyword different from the pillar's
- Answer a sub-question the pillar only mentions in passing
- Cover that sub-topic MORE comprehensively than the pillar's section on it
- Link back to the pillar via descriptive, keyword-rich anchor text
- Link forward to 2-3 sibling satellites where naturally relevant

Intent differentiation is the whole game. If a satellite doesn’t cover its sub-topic in more depth than the pillar’s paragraph on it, you’ve built a cannibalizer, not a reinforcer.

Step 4: Pillar links forward to every satellite

In the pillar body, each section that a satellite expands on should link out to it:

## Authentication

Setting up an API key is the first step (see our
[authentication guide](/articles/claude-api-authentication/) for the full process).
[brief content here]

## Rate limits

[brief content; deep dive in
[rate limits + retry](/articles/claude-api-rate-limits/)]

The pillar is the hub and the satellites are spokes; the pillar should link to every satellite, by section. As a sanity check, 2026 internal-linking guidance suggests roughly 2-5 contextual links per 1,000 words and keeping total links on a page under ~150, so a long pillar comfortably accommodates one link per satellite without looking stuffed.

Step 5: Satellites link to each other

For each satellite, pick 2-3 closely-related siblings and link them from body text:

<!-- inside claude-api-streaming.mdx -->
When streaming, you'll want to handle rate-limit errors gracefully — see
[Claude API rate limits + retry](/articles/claude-api-rate-limits/).

For batch jobs that don't need streaming,
[Batch API](/articles/claude-api-batch/) is usually cheaper.

A cluster with internal cross-links is a graph; without them it’s a hub-and-spoke. A graph beats a spoke for topical authority because it keeps every page within a few clicks and signals to Google that the set is a coherent body of work, not scattered posts. Keep priority pages within 3 clicks of the homepage — pages buried 4+ clicks deep get crawled less and are treated as less important.

Step 6: Wait 6-12 months, then measure

Topical authority compounds slowly. Don’t expect movement in week 2. A realistic trajectory:

Month 1:  cluster shipped
Month 3:  pillar starts moving (e.g. position 32 -> ~20)
Month 6:  pillar reaches position 8-12; satellites stabilize ~15-25
Month 12: pillar holds top 5; satellites each settle top 10-20

Sites that implement clusters correctly commonly report meaningful organic-traffic gains within 6-12 months relative to standalone posts on the same topic. If a supporting page has been indexed for 6+ months with zero organic sessions, revise, re-scope, or consolidate it. And if at month 6 the pillar hasn’t moved at all, the cluster probably isn’t the bottleneck — depth, backlinks, or competition is the real issue.

How to confirm it’s fixed

Run these checks before declaring the cluster healthy:

Volume: the pillar has 8+ live supporting articles, each on a distinct sub-intent.
Inbound links to the pillar: in Search Console (Links -> Internal links) the pillar is among your most-linked pages; every satellite points at it.
Sibling links: a crawl shows satellite-to-satellite links averaging 2+ per page, not 0.
No cannibalization: in the Performance report, no satellite and the pillar both surface for the same primary query (see keyword cannibalization).
Click depth: every cluster page is reachable within 3 clicks of the homepage.
Indexed: all cluster URLs show “Indexed” (not “Discovered – currently not indexed”) in Page indexing.

Prevention

Plan the cluster before publishing the pillar: brainstorm 15-20 sub-topics, commit to 8-12 satellites.
Track cluster completion as a metric. “Pillar shipped” without satellites isn’t a cluster yet.
Keep the pillar narrow enough to focus; if it spans 4+ intents, split it into multiple pillars.
Make every satellite target a distinct sub-intent and cover it more deeply than the pillar does — designed complement, not designed overlap.
Link bidirectionally: pillar -> every satellite, satellite -> 2-3 siblings, every satellite -> pillar.
Budget compound time: 6-12 months for ranking signals to consolidate. Expect slow, not instant.

FAQ

How many supporting articles does a topic cluster actually need? Aim for 8-12 per pillar as a practical floor. HubSpot recommends choosing a topic broad enough to anchor many subtopics, and practitioner guidance as of June 2026 lands around an 8-15 starting band; competitive topics warrant the upper end or more, and you expand from there based on performance. Two satellites is a stub.

Is it better to have many clusters or a few deep ones? A few deep ones. 2026 guidance is consistent: three deeply developed clusters beat ten shallow ones on both classic SEO and AI-overview visibility. Depth and internal coherence win.

How fast should I publish the supporting articles? Over 2-3 months at 1-2 per week, not all in one batch. A steady cadence reads as an actively-maintained cluster; a same-day dump of 10 posts looks generated and gives weaker signals.

How do I find articles that should link to the pillar but don’t? Use Google Search Console -> Links -> Internal links and check the pillar’s inbound count, then cross-reference a full-site crawl (Screaming Frog or Sitebulb) to list topically-related pages that don’t link to it. Add contextual links from those pages.

How long until I see ranking improvement? Typically 6-12 months. Expect the pillar to start moving around month 3 and consolidate by months 6-12. If a supporting page is indexed 6+ months with zero organic sessions, re-scope or consolidate it.

My satellites are competing with the pillar in search. What happened? That’s keyword cannibalization — the satellites target the same primary query as the pillar. Re-scope each satellite to a distinct sub-intent that it covers in more depth, or consolidate the weakest into the pillar. See Cluster overlap / keyword cannibalize.

Tags: #Content ops #Site quality #Site audit #Troubleshooting #Pillar / Cluster