一句话先说结论： 1 个 pillar 加 2 篇辅助文章只是 stub，不是 cluster。最快的修复是补深度——每个 pillar 先配 8-12 篇卫星作为实用下限（HubSpot 把 pillar 定义为「宽到能撑起很多子话题」，而截至 2026 年 6 月，业界实操的起步区间大致是 8-15 篇），每篇打不同的子 intent，分 2-3 个月稳定发出，并做好双向内链（pillar 往下链到每篇卫星；每篇卫星往上链 pillar，再链 2-3 篇同级卫星）。然后等 6-12 个月——话题权威是慢慢复利的。
你在某篇 SEO 指南里读到「topic cluster」，于是建了一个：4000 字的 pillar 文章「Claude API」，外加 2 篇辅助。6 个月后 pillar 排在第 32 位，两篇卫星排 60+，没一篇拿到有意义的流量。策略本身没错，问题是 1 pillar + 2 卫星根本不是 cluster——是 stub。
话题权威是覆盖广度和深度共同决定的。2026 年的行业共识收敛到每个 pillar 配 8-12 篇卫星;一个有 ~20 篇相互链接的同主题文章的站点,常常能压过一篇单独的 5000 字长文,哪怕那篇长文技术上更优。下面讲:怎么设计 cluster、怎么在 2-3 个月内发出、怎么做双向接线,以及怎么避开「把 cluster 当 checkbox」这个会产出 stub 的失败模式。
你属于哪一类
先诊断,再动手。绝大多数太浅的 cluster 都败在以下六个原因之一,按命中率从高到低排列。
| # | 原因 | 最快的判断信号 | 怎么修 |
|---|---|---|---|
| 1 | 喊了策略、没投入量 | pillar 只有 2-3 篇卫星,3+ 个月没增长 | Step 1-2:头脑风暴 + 发够 8-12 篇 |
| 2 | 编辑日历中途转移了 | 卫星都挤在某一个发布月,之后断更 | Step 2:恢复发布节奏 |
| 3 | 已有相关文章没链到 pillar | pillar URL 在相关文章的内链里很少/没有出现 | Step 4-5:把链接接上 |
| 4 | 卫星打和 pillar 一样的 intent | pillar 和卫星标题几乎一样、抢同一个主 query | Step 3:做 intent 差异化(或合并) |
| 5 | 卫星之间不互链 | 卫星到卫星的链接数大多是 0 | Step 5:补同级链接 |
| 6 | pillar 太宽 | pillar 想覆盖 4+ 个不同用户 intent | 拆成 2-3 个更窄的 pillar |
如果你拿不准自己属于哪一类,下面的逐条拆解里每一条都给了「如何判断」的检查方法。
常见原因
1. 把 pillar / cluster 当 buzzword、没承诺量
你读过 cluster,发了一篇 pillar 加 2 篇随手写的卫星,就算完事了。可这套模型假设的是 8-12 篇卫星,你停在了 2。
如何判断: pillar 只有 2-3 篇辅助文章,而且 3+ 个月没增长。策略被命名了,但从来没真正投入资源。
2. 编辑日历在 cluster 完成前就转移了
你 1 月发了 pillar,2 月发了 2 篇卫星——然后 3 月的编辑日历转去做别的话题了,cluster 永远没写完。
如何判断: 辅助文章全挤在某一个发布月,之后就没了。典型的编辑日历漂移。
3. 已有文章没内链到 pillar
你可能早就有 8 篇 Claude 子话题文章,都是在「pillar/cluster」成为策略之前写的,没有一篇链到 pillar。cluster 机械上存在,但没有连起来。
如何判断: 打开 Google Search Console -> 链接(Links) -> 内部链接(Internal links),找到 pillar URL,看它的内链入链数。如果你大部分主题相关的页面都没指向 pillar,说明 cluster 没接线。用爬虫(Screaming Frog、Sitebulb)能逐页确认。
4. 卫星打和 pillar 一样的子 intent
pillar 是「Claude API guide」,卫星却是「Claude API tutorial」和「Claude API how-to」——三篇都在抢同一个 query,这是 cannibalize(自相蚕食),不是互补。(见 Cluster overlap / 关键词蚕食。)一条经验法则:如果一篇卫星排的是和 pillar 相同的主关键词,那它就是在蚕食,应该重新定位或合并掉。
如何判断: pillar 和卫星标题相似、打同一个宽 query。在 Search Console 里,你有两个 URL 在同一个 query 下出现——这是设计出来的重叠,不是设计出来的互补。
5. 卫星之间不往前互链
pillar 链到卫星 A,A 链回 pillar;pillar 链到卫星 B,B 链回 pillar。但 A 和 B 之间从不互链。这个 cluster 是 hub-and-spoke(轮辐式),没有结成网。
如何判断: 爬一遍卫星到卫星的链接数。如果大多是 0,说明在卫星这一侧 cluster 是无向的。
6. pillar 太宽
pillar 是「Claude 的全部」——覆盖 API、web app、移动 app、企业版。这些里每一个都该有自己的 pillar。当前这个页面太横向了,以至于没有哪篇卫星能可信地链上去。
如何判断: pillar 试图覆盖 4+ 个不同用户 intent。该把它拆成 2-3 个更窄的 pillar。
最短修复路径
按收益从高到低。Step 1 设计;Step 2-3 建设;Step 4-6 连接。
Step 1:头脑风暴 15-20 个真读者会问的子话题
围绕你的 pillar 话题,列出读者真正想要的东西。你不会全写,但你需要一份 roadmap:
Pillar:Claude API
真子话题(读者会问的问题):
1. Authentication / API key
2. Rate limit + retry 逻辑
3. Streaming 响应
4. Tool use / function calling
5. Prompt caching 省钱
6. Batch API 批量任务
7. Vision / 图像输入
8. Computer use
9. Token 计数 + 成本计算
10. 和 OpenAI API 对比
11. 从 OpenAI 迁移
12. 错误码 + troubleshooting
13. 生产环境最佳实践
14. 选模型(Sonnet vs Haiku vs Opus)
15. 常见 pitfall
16. Webhook 集成模式
17. 在它之上建 agent
18. PDF / 文档输入
19. JSON mode / 结构化输出
20. Latency 优化15-20 个候选给你一个可以排期的 backlog。
Step 2:2-3 个月内稳定发出 8-12 篇卫星
不要一周全堆出来——批量发布看着像机器生成,而且新鲜度信号更弱。要有节奏:
第 1 周: pillar
第 2-12 周:每周 1-2 篇卫星(目标总共 8-12 篇)稳定的 cadence 会发出「这是个活跃维护的 cluster」的信号。如果你的话题竞争激烈,就按区间上限(甚至更多)来规划;2026 年的指南讲得很清楚——深度胜过广度:三个建得很深的 cluster 能压过十个浅 cluster。
Step 3:每篇卫星打一个独特的子 intent
每篇辅助文章都应该:
- 主关键词和 pillar 不同
- 回答 pillar 只一笔带过的子问题
- 在这个子话题上比 pillar 的对应小节讲得「更全」
- 用描述性的、含关键词的 anchor 回链 pillar
- 在自然相关处往前链 2-3 篇同级卫星Intent 差异化是整件事的核心。如果一篇卫星在它的子话题上讲得没有比 pillar 里那一段更深,那你建的是 cannibalizer(蚕食者),不是 reinforcer(加强者)。
Step 4:pillar 往前链到每一篇卫星
在 pillar 正文里,每个被某篇卫星展开的小节都应该链出去:
## Authentication
设置 API key 是第一步(完整流程见我们的
[authentication guide](/articles/claude-api-authentication/))。
[这里简略]
## Rate limits
[简略内容;深入见
[rate limits + retry](/articles/claude-api-rate-limits/)]pillar 是 hub,卫星是 spoke;pillar 应该按小节链到每一篇卫星。做个 sanity check:2026 年的内链指南建议大致每 1000 字配 2-5 个上下文链接、并把单页总链接数控制在 ~150 以内,所以一篇长 pillar 完全装得下「每篇卫星一个链接」,不会显得堆砌。
Step 5:卫星之间互链
对每篇卫星,挑 2-3 篇关系最近的同级卫星,在正文里链过去:
<!-- 在 claude-api-streaming.mdx 里 -->
streaming 时你需要优雅地处理 rate-limit 错误——见
[Claude API rate limits + retry](/articles/claude-api-rate-limits/)。
不需要 streaming 的批量任务,
[Batch API](/articles/claude-api-batch/) 通常更便宜。有内部交叉链的 cluster 是一张图;没有就只是 hub-and-spoke。图胜过轮辐,因为它让每个页面都在几次点击之内,并向 Google 表明这一组是一个连贯的整体,而不是零散的几篇。让重要页面都在距首页 3 次点击之内——埋在 4+ 次点击深处的页面会被爬得更少、被当作更不重要。
Step 6:等 6-12 个月再衡量
话题权威是慢慢复利的。不要指望第 2 周就有动静。一个现实的轨迹:
第 1 月: cluster 发出
第 3 月: pillar 开始动(比如从第 32 位 -> ~20)
第 6 月: pillar 到第 8-12 位;卫星稳定在 ~15-25
第 12 月:pillar 守住 Top 5;卫星各自落在 Top 10-20把 cluster 做对的站点,常报告在 6-12 个月内、相对同主题的零散文章拿到可观的自然流量增长。如果一篇辅助文章已经被索引 6+ 个月、却 0 自然会话,就该修订、重新定位或合并它。而如果到第 6 个月 pillar 一点都没动,那 cluster 多半不是瓶颈——深度、外链或竞争才是真问题。
怎么确认修好了
在宣布 cluster 健康之前,把这几项跑一遍:
- 数量: pillar 有 8+ 篇上线的辅助文章,每篇打一个独特子 intent。
- 指向 pillar 的入链: 在 Search Console(链接 -> 内部链接)里,pillar 是你内链最多的页面之一;每篇卫星都指向它。
- 同级链接: 爬虫显示卫星到卫星的链接平均每页 2+ 个,而不是 0。
- 没有蚕食: 在 效果(Performance) 报告里,没有任何卫星和 pillar 在同一个主 query 下同时出现(见 关键词蚕食)。
- 点击深度: 每个 cluster 页面都在距首页 3 次点击之内可达。
- 已索引: 所有 cluster URL 在 网页索引编制(Page indexing) 里都显示「已编入索引」,而不是「已发现 - 尚未编入索引」。
预防建议
- 发 pillar 之前先把 cluster 规划好:头脑风暴 15-20 个子话题,承诺 8-12 篇卫星。
- 把 cluster 完成度当成一个指标来追踪。只发了 pillar、没卫星,还不算 cluster。
- 让 pillar 窄到足够聚焦;跨 4+ 个 intent 就拆成多个 pillar。
- 让每篇卫星打一个独特子 intent,并在该子话题上比 pillar 讲得更深——设计互补,不设计重叠。
- 双向链:pillar -> 每篇卫星,卫星 -> 2-3 篇同级,每篇卫星 -> pillar。
- 预留复利时间:排名信号要 6-12 个月才合并。预期是慢,不是立刻。
常见问题
一个 topic cluster 到底需要多少篇辅助文章? 目标是每个 pillar 8-12 篇作为实用下限。HubSpot 建议选一个宽到能撑起很多子话题的主题,而截至 2026 年 6 月,业界实操的起步区间大致落在 8-15 篇;竞争话题要按上限甚至更多,再根据效果往上扩。2 篇卫星只是 stub。
是建很多个 cluster 好,还是几个很深的好? 几个很深的好。2026 年的指南一致:三个建得很深的 cluster,在传统 SEO 和 AI 概览可见度上都能压过十个浅的。深度和内部连贯性才赢。
卫星该发多快? 分 2-3 个月、每周 1-2 篇,别一次性堆出来。稳定的 cadence 读起来像个在维护的 cluster;同一天甩出 10 篇看着像机器生成,信号更弱。
怎么找出「本该链到 pillar 却没链」的文章? 用 Google Search Console -> 链接 -> 内部链接 看 pillar 的入链数,再交叉对照一次全站爬取(Screaming Frog 或 Sitebulb),列出那些主题相关却没链到它的页面,然后从这些页面补上上下文链接。
多久能看到排名改善? 通常 6-12 个月。预期 pillar 在第 3 个月左右开始动,在第 6-12 个月之间稳定下来。如果一篇辅助文章被索引 6+ 个月还是 0 自然会话,就重新定位或合并它。
我的卫星在搜索里跟 pillar 抢排名,怎么回事? 这是关键词蚕食——卫星打的是和 pillar 一样的主 query。把每篇卫星重新定位到一个它能讲得更深的独特子 intent,或者把最弱的那篇合并进 pillar。见 Cluster overlap / 关键词蚕食。