映射主题权威：500-URL 内容中心审计（Claude + Sitemap XML）
目录
我在 Claude 里打开了一份 487 条 URL（Uniform Resource Locator, 统一资源定位符）的 sitemap（站点地图），让它把这些 URL 按主题中心聚类，得到的结果出乎意料：3 个强中心，7 个孤立簇，没有任何支柱页（pillar page）。这个站点已经运营 4 年了。这些孤立簇在 Screaming Frog 里完全看不出来——每个 URL 都返回 200，每个链接都能正常抓取。问题不在技术层面，而在结构层面：7 个松散的页面簇在为同一个搜索意图互相争抢，却没有一根支柱把它们串起来。这是每月 4,000 美元的隐形泄漏——本该复利积累成主题权威（topical authority）的流量，正在被稀释到一堆松散相关的 URL 上。
Screaming Frog 抓取能告诉你哪些页面返回 404、重定向链条在哪里、哪些页面内容单薄。它不能告诉你：哪些页面属于同一个 hub、哪些簇缺一个中心、你的内链图谱是否真的在支撑你以为存在的拓扑结构。这是另一个问题——是长上下文 LLM（Large Language Model, 大语言模型）很擅长回答的问题，前提是你把 sitemap 喂对方式。
这是我如今对每个 B2B SaaS（Software as a Service, 软件即服务）站点审计都会跑一遍的 4 步工作流。
第 1 步：把 sitemap 聚类成主题中心
把 sitemap.xml 抓下来，剥成 <loc> URL 列表（Claude 不需要 <lastmod> 和 <priority> 字段），然后切成 200 条一批的块。为什么要 200？Claude 的 200K token 上下文理论上能一次性吃下 5,000 条 URL 的 sitemap，但单次超过 300 条后聚类质量会断崖式下跌——Claude 会开始幻觉子主题，把不相关的页面合并。对 500–2,000 条 URL 的站点，200 是甜点。
这是 prompt：
你是一位 SEO 内容策略师，正在审计一个 B2B SaaS 站点的主题权威。
把这 200 条 URL 聚成主题中心（hub）。每个 hub 返回：
- 中心名称（2-4 个词，例如"Email deliverability"）
- 中心描述（一句）
- 属于这个中心的 URL
- 置信度（高/中/低）
如果某个 URL 不属于任何清晰聚类，放进 "Uncategorized" 桶里。
返回合法 JSON（JavaScript Object Notation）。用此 schema：
{
"hubs": [
{"name": "", "description": "", "urls": [], "confidence": ""}
],
"uncategorized": []
}
[这里粘贴 200 条 URL]
每个段落用 XML 风格的标签包起来很关键。我用相同输入对比过"标签包裹"和"一坨大段落"两种写法，后者 Claude 的指令遵循度下降大约 30%。结构化 prompt 是干净 JSON 输出和 Claude 突然"贴心地"补一段点评之间的分水岭。
在我那个 487 条 URL 的站点上，这一步返回 14 个 hub，加上 31 条无法归类的 URL（大多是历史遗留的产品页和 2021 年写的几篇奇奇怪怪的博客）。
第 2 步：识别支柱/分支缺口
拿到这 14 个 hub 之后，我接着问一个追问：哪个 hub 真的有支柱页？哪个只是一堆页面互相指向、没有一个中心？
你是一位 SEO 内容策略师。
对下面每个 hub，分类为：
- "Pillar exists"：有一篇清晰的综合支柱页（3000+ 字、覆盖面广），分支都回链到它
- "Orphan cluster"：多篇相关页面，但没有中心支柱——互相链接，但不指向统一页
- "Single page"：hub 里只有 1 条 URL，不构成真正聚类
看 URL slug。支柱页通常 slug 短而宽，比如 /email-deliverability/。分支 slug 具体而长尾，比如 /email-deliverability-spf-record-checker/。
对每个 hub，基于 URL 给出一句判断理由。
JSON：{"hubs": [{"name": "", "status": "", "pillar_url": "", "justification": ""}]}
[把第 1 步得到的 14 个 hub 粘进来]
这是整个工作流里最有可执行性的产出。在我那个 487 条 URL 的站点上，它返回：
- 3 个 Pillar exists——博客上确实有写得扎实的支柱页，分别覆盖"form analytics"、"user onboarding"、"session replay"
- 7 个 Orphan cluster——其中"email deliverability"有 11 篇互相指的分支；"ABM（Account-Based Marketing, 目标客户营销）strategy"有 8 篇；"webhook security"有 6 篇
- 4 个 Single page——独立页面，不属于更大主题
这 7 个孤立簇才是真正的杠杆点。每一个都是一份待落地的主题地图。
第 3 步：给每个 hub 的内链分布打分
这一步，审计开始变成电子表格，而不是策略文档。针对每个 hub——尤其是孤立簇——我让 Claude 估算内链分布。我不要精确数字（那需要爬虫），我要的是一个方向性打分，告诉我链接图谱哪里是歪的。
对于 "Email deliverability" 这个 hub 和下面这 11 条 URL，估算：
1. 这 11 条 URL 里，有多少链接到一根支柱页（或彼此形成 hub-and-spoke 模式）？
2. 有多少是孤儿页（没有任何内链指入）？
3. 用 1-10 衡量内链权重分布：1 = 完全孤立的簇，10 = 紧凑的 hub-and-spoke。
然后列出 2-3 条最像支柱页的 URL（slug 宽、基础话题）。 那个测试站点上的 email deliverability hub，Claude 估算：11 条里有 4 条被内链指向（且这 4 条互相形成一个环），7 条是孤儿，内链分布分数：3/10。这个分数说明链接图谱在主动和他们作对——Google 大概率把这 11 页当成一团无差别的糊状物，而不是一个清晰的主题簇。
第 4 步：为每个 hub 建议 5–10 篇缺失的支持文章
最后一步。对每个孤立簇，让 Claude 建议缺失的支持文章——能补齐这个簇的分支。这一步把审计变成内容日历。
"Email deliverability" 这个 hub 有 11 篇现存 URL，覆盖 [列出它们]。再建议 8-10 篇分支文章，把这个 hub 补齐。
每条建议包括：
- 标题（搜索优化，匹配用户意图）
- 目标关键词
- 为什么这篇缺失（填补什么空缺）
- 建议字数（短 / 中 / 长） email deliverability 这个 hub，Claude 返回的建议包括"SPF（Sender Policy Framework, 发件人策略框架）记录生成器教程"、"DKIM（DomainKeys Identified Mail）vs DMARC（Domain-based Message Authentication, Reporting & Conformance）：何时用哪个"、"B2B 冷邮件送达率"、"新发件域名预热指南"——全部是直接可写的内容缺口，全是这个细分领域的 B2B SaaS 营销人真正会想写的主题。
60 天后的结果
那个 487 条 URL 的 B2B SaaS 站点，我做了三件事：
- 新增 4 个支柱页（最大的 4 个孤立簇各一个）
- 重组内链，让 11 条 email deliverability 簇指向新支柱
- 写了 6 篇 Claude 建议的分支文章补最明显的空缺
60 天内，这些 hub 的自然点击从 1,840/月 涨到 5,200/月。没新增外链，没动技术 SEO，没刷新老页面。纯结构改动——把主题地图显式画出来，给每个簇一个中心。原有页面的 CTR（Click-Through Rate, 点击率）也跟着涨了，因为 Google 开始把新支柱页排到更宽泛的搜索词上，再把合适的访客分发到分支页。
为什么这和 Screaming Frog 审计不一样
Screaming Frog 给你状态码、重定向链、标题长度、canonical 标签。它回答的是"这个页面技术上是否健全"。
这套工作流回答的是另一个问题："我的站点结构是不是我以为的那个样子？"
200 状态码不能告诉你，11 篇松散相关的页面是组成了一个 hub，还是在同一页 SERP（Search Engine Results Page, 搜索引擎结果页）上互相打架。一个干净的内链数不能告诉你，现有链接是 hub-and-spoke 模式，还是一环扣一环的等距环。在 500+ URL 的站点上做这种审计，只有"LLM 增强的 sitemap 审计"这条路能在一个下午内搞定。
总成本：分析师大约 90 分钟，每 1,000 条 URL 大约 4 美元 Claude API token。单个 B2B SaaS 站点的回本周期：60 天，然后是复利。
如果你的站点超过 300 条 URL，却从没真正画过主题结构，几乎可以肯定有你看漏的孤立簇。sitemap 知道，模型能读，唯一的变量是你问不问。