每个新内容站都会遇到同一个纠结：一个题深挖，还是多个题铺开。答案不是”平衡”——而要看站点在哪个阶段。下面是基于阶段的决策规则、可直接抄进仓库的内容计划模板、以及帮你判断何时切换策略的 Search Console 检查命令。
问题背景
前 60 天搜索引擎根本不知道你的站是干什么的。铺得太广会主题混乱；挖得太深又没东西爬。正确节奏是：一个 hub 先挖深，再开第二个 hub 铺广度，再回头补深度。大多数独立开发者把顺序做反了，因为对的顺序看起来”慢”。
判断标准
- 站点上线不满 60 天、文章不到 30 篇——强烈建议先一个 hub 挖深。
- 一个 hub 已经有 30+ 篇、其他还没有——是时候开第二个 hub 铺广度。
- 已有 3+ 个 hub，但每个只有 10 篇——回到流量最好的那个 hub 继续挖。
- Search Console 显示某个 hub 展示量集中——先把这个 hub 做透再开新方向。
- 主 hub 平均排名 < 30——说明深度在生效。
快速结论
全新站点先一个 hub 挖深到 30 篇左右，再开第二个 hub。前 90 天不要同时铺 5 个方向。
开始前准备
- 老实选锚定 hub——认知 × 需求两方面都最强的那个。
- content schema 强制单 hub 归属。
- 用 Search Console 数据决定何时开 hub 2，不凭感觉。
实操步骤
- 挑一个锚定 hub。 认知 × 需求按 1-5 分打分：
# scripts/hub-score.yml
candidates:
- id: indie-dev
knowledge: 5
demand: 4
competition: 3 # 越小越好
score: 6 # knowledge + demand - competition
- id: ai-tools
knowledge: 3
demand: 5
competition: 5
score: 3
- id: prompt-library
knowledge: 4
demand: 4
competition: 4
score: 4
# 选 score 最高的- 锚定 hub 里规划 25-30 篇长尾。 20 行 YAML 进仓库：
# content-plan/indie-dev.yml
hub: indie-dev
pillar: "2026 怎么从零做一个独立内容站"
cluster:
- astro-deploy-firebase
- firebase-hosting-go-live-checklist
- firebase-custom-domain
- firebase-cache-and-deploy-update
- firebase-route-404-causes
- what-is-firebase-hosting
- firebase-hosting-free-tier
- is-vercel-good-for-content-sites
- vercel-deploy-astro
- vercel-custom-domain
# ... 再补 15-20 个
cadence: 3/周
target_complete: 2026-07-15-
定一个发布节奏并坚持 8 周。 每周 2-3 篇。hub 1 没到 25 篇之前别开 hub 2。
-
prebuild 接一个 hub 进度检查：
// scripts/hub-progress.mjs
import { readdirSync, readFileSync } from 'node:fs';
import matter from 'gray-matter';
const counts = {};
for (const f of readdirSync('src/content/articles/zh/indie-dev')) {
const { data } = matter(readFileSync(`src/content/articles/zh/indie-dev/${f}`, 'utf8'));
counts[data.category] = (counts[data.category] || 0) + 1;
}
const lead = Math.max(...Object.values(counts));
const anyOther = Object.values(counts).filter(c => c !== lead).some(c => c > 10);
if (lead < 25 && anyOther) {
console.warn('WARN: 锚定 hub 还没到 25 就开了第二个');
}- hub 2 用 Search Console 真实信号选，不要凭感觉。 拉 hub 1 在搜索里出现的 query：
curl -X POST "https://www.googleapis.com/webmasters/v3/sites/$SITE/searchAnalytics/query" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
--data '{
"startDate":"2026-03-22","endDate":"2026-05-22",
"dimensions":["query"],"rowLimit":200
}' \
| jq -r '.rows[].keys[0]' | head -40找其中反复出现、但不属于 hub 1 的名词——那是 hub 2 候选。
-
接下来 8 周按 60/40 倾向 hub 1，直到 hub 2 也到 25 篇左右。
-
总数到 100 篇时按 hub 复盘流量，加码表现最好的那个。脚本 + Search Console 输出：
hub articles impressions(28d) clicks(28d) CTR
indie-dev 34 42,000 1,260 3.0%
ai-tools 28 11,200 180 1.6%
prompt-library 22 4,300 62 1.4%
# → indie-dev 赢；下一批 20 篇分配给它- 总数到 150-200 篇后，才同时开 hub 3 和 hub 4。
执行检查清单
- 锚定 hub 由书面打分选出，不靠感觉。
- 内容计划 YAML 至少列出锚定 hub 的 25 个 cluster slug。
- prebuild 在锚定 hub 没到 25 时打开第二个就告警。
- hub 2 决策由 Search Console 数据驱动。
上线后验证
- 8 周后锚定 hub 已经 20+ 篇被收录。
- cluster 关键词平均位置从 > 50 向 20 靠近。
- Search Console 曝光集中在锚定 hub（>70%）——这就是”深”的样子。
容易踩的坑
- 第一个月就开 5 个 hub——主题权威哪里都建立不起来。
- 一个 hub 挖得太深，覆盖到根本没人搜的子子子主题。深度上限是”Search Console 真实 query + 邻近 autocomplete”。
- hub 2 一兴奋就丢了 hub 1，半截 hub 没法排名。
- 把 8 篇文章的 hub 叫做”深”——2026 年深度的标准是 20-30 篇起。
- 不看 Search Console 的真实信号，凭感觉决定加码哪个方向。
- 把 hub 2 当创意决策——它其实是数据决策。
FAQ
- 我有几个一样想做的 hub 怎么选: 挑需求和你的认知优势组合最强的那个，其他 hub 等 90 天不会损失什么。
- 什么算”挖得够深”: 主要长尾变种都覆盖了，25-30 篇加至少一篇强 pillar 把它们串起来。
- Google 真的奖励主题权威吗: 是的，2026 年尤其明显。主题覆盖深的站，即便单个长尾查询排名也更高。
- 能不能用 AI 假装广度: 可以试，但 Google 现在很快就能识破薄 AI 广度。真深度必须有人工 fact-check 和结构化输入。
- pillar 文章先写还是后写？: 后写。先写 cluster，pillar 自然从你写出来的内容里浮出来。先写 pillar 会写成空泛的抽象稿。