用途
SEO Site Health Audit 用于对技术性 SEO 审计结果进行分诊，重点是根据对排名和流量的实际影响来排序，而不是依据原始问题数量或严重性标签。它不依赖特定技术栈，最终产出映射到业务影响的优先级修复待办清单。
适用场景
- 在运行 Ahrefs Site Audit 或其他全站爬虫之后
- 审查一长串技术问题并需要确定优先级时
- 规划技术性 SEO 冲刺时
- 上线前或迁移后的技术验证
- 季度技术健康检查
- 开发时间有限，必须挑选最高杠杆修复项时
不适用场景
- 运行爬虫本身（直接使用爬虫工具）
- 诊断具体流量下降（使用 seo-traffic-diagnosis）
- 单页面审计（使用 seo-onpage）
- 纯技术策略或结构化数据设计（使用 seo-technical）
所需输入
- Ahrefs Site Audit（或同等工具）的爬取结果
- Search Console 覆盖率与 Core Web Vitals 数据
- 站点的自然流量概况（哪些页面带来流量）
- 相关方时间与开发者可用产能
- 仅在通过 Ahrefs 拉取爬取数据时，确认 Ahrefs MCP 已连接。任何同等爬虫的导出文件本身即可满足第一项输入。
分诊框架
按三个维度评估，而非仅看严重性标签。
维度 1：页面级流量影响
将受影响的 URL 分层：
- Tier 1：按自然流量排名前 10% 的页面
- Tier 2：有排名但尚未带来显著流量的页面（第 2-3 页结果）
- Tier 3：存在但没有有意义排名的页面
Tier 1 的修复价值通常是 Tier 3 的 10 倍。
维度 2：影响机制
每个问题评为 HIGH、MEDIUM 或 LOW。评级依据 references/issue-impact-table.md，该文件覆盖的问题族按查找顺序包括：可索引性、可爬取性、可渲染性、Core Web Vitals、结构化数据、内部链接完整性、hreflang、页面元素、图片、安全与信任，并附带一个「搁置或跳过」清单。评级按行而非按族确定。
维度 3：工作量
- S（小）：配置更改、单个模板编辑、站点地图重新生成
- M（中）：主题或组件更改、重定向映射、模板级修复
- L（大）：架构变更、重新平台化、框架迁移、结构化数据全面改造
分诊矩阵
将三个维度组合为优先级分数：
| Tier | 机制 | 工作量 | 优先级 |
|---|---|---|---|
| Tier 1 | HIGH | S | P0（本周完成） |
| Tier 1 | HIGH | M | P1（本冲刺完成） |
| Tier 1 | HIGH | L | P2（规划为项目） |
| Tier 1 | MEDIUM | S | P1 |
| Tier 1 | MEDIUM | M | P2 |
| Tier 1 | MEDIUM | L | P3 |
| Tier 1 | LOW | S | P3（方便时批量处理） |
| Tier 1 | LOW | M-L | 除非出现证据，否则搁置 |
| Tier 2 | HIGH | S | P1 |
| Tier 2 | HIGH | M-L | P2 |
| Tier 2 | MEDIUM | S | P2 |
| Tier 2 | MEDIUM | M-L | P3 |
| Tier 3 | HIGH | S | P3 |
| Tier 3 | 其他 | 任意 | 搁置 |
MEDIUM 行遵循一条规则：同一 Tier 和工作量下，MEDIUM 问题比 HIGH 问题低一个优先级带。被参考文件评为 LOW-MEDIUM 的行，若 URL 为 Tier 1 则采用 MEDIUM 行，否则采用 LOW 行。
P0-P1 工作获得团队关注。P2 进入路线图。P3 批量归入日常维护。搁置是对降级的诚实处理。
工作流程
- 拉取爬取结果：Ahrefs Site Audit + Search Console + Core Web Vitals
- 对 URL 分层：使用自然流量数据，为每个受影响 URL 标记 Tier 1、2 或 3
- 按机制分类每个问题：在 references/issue-impact-table.md 中查找 HIGH、MEDIUM 或 LOW 评级
- 估算每类修复的工作量：将类似修复归组为一个工作量估算
- 应用分诊矩阵：分配 P0-P3 或搁置
- 聚类修复：将共享工作量的修复归组，一次模板更改可解决数百个问题
- 构建待办清单：P0 优先，然后是 P1 等。添加修复描述、负责人、预期影响
- 添加衡量方式：什么指标能确认修复有效？在发布前定义
- 交接：输出用于开发待办清单和 seo-audit-orchestration
- 修复后重新爬取：确认解决。更新待办清单
值得寻找的高杠杆聚类
- 全站重定向链清理：一次站点地图更新加内部链接更新可一次性解决数千个「重定向链」问题。
- 模板上意外的 noindex：改一行代码可重新索引数百或数千页面。
- 站点地图新鲜度管道：损坏的站点地图重新生成任务会影响所有依赖 Search Console 看到正确 URL 的问题。
- 分面导航上的 canonical 不一致：模板级 canonical 修复可解决整个电商分类树的重复内容问题。
- 恢复 robots.txt：被回退的生产 robots.txt 可在数天内恢复全站下降。
- Hreflang 块修复：一次模板更改可解决整个多语言站点的 hreflang 问题。
- 资产管道层面的图片优化：修复构建过程可解决数千个单独资产问题。
发现这些聚类时，即使单个问题看起来很小也要优先处理，因为聚类影响很大。
失败模式
- 严重性崇拜：把每个「critical」标签都当成真正关键。很多不是。按机制和流量影响分诊。
- 数问题：报告「我们修复了 1200 个问题」而不展示流量或排名影响，会浪费工程公信力。
- 跳过分层：先修复 100 个 Tier-3 问题再修 5 个 Tier-1 问题是无效忙碌。
- 单问题修复：多数问题成簇出现。当 800 个问题共享同一根因时只修一个重定向链是错误的单位。
- 不重新爬取：「已修复」但未验证会留下疑问。重大修复后务必重新爬取。
- 忽视 Search Console：Ahrefs 看到的只是其爬虫发现的。Search Console 反映 Google 实际看到和索引的。两者都要用。
- 把 Core Web Vitals 当清单：CWV 是实地数据，不是实验室数据。为真实用户体验优化，而非合成分数。
- 为展示而修复低机制问题：干净的技术报告若没有流量增长，对谁都没帮助。
- 不衡量：在修复前定义能证明修复有效的指标。
输出格式
一份站点健康分诊文档，包含：
- 摘要：总问题数、前 3 个修复聚类、预期影响，或按数据可用性规则说明差距
- URL 分层：如何分类及每层数量
- 问题分类：按机制类别、层级、优先级带的计数
- 优先级待办清单：P0-P3 排序。每项包含：问题、受影响 URL、修复描述、工作量、预期影响、负责人
- 修复聚类：共享修复的问题组。最高杠杆的放在最前
- 衡量计划：每个修复或聚类，什么能证明有效
- 方法论：使用的爬虫、日期、范围、注意事项
长度：5-12 页加一个待办清单电子表格。
数据不可用时
该技能输出依赖其无法自行生成的数据、测量或工具结果。当所需输入、工具或数据源不可用或无法验证时，认可的产出是附有差距说明的可交付物：需要什么、实际获得或验证了什么、输出的哪些部分受影响。编造、估算或插值所需数字来完成可交付物在任何时候都不被认可。说明差距本身就是完整答案。
参考文件
- references/issue-impact-table.md：常见爬虫问题到机制评级和典型修复工作量的映射表，外加聚类信号和搁置或跳过清单。该文件是每个问题评级的唯一真实来源；上述分诊矩阵将评级加层级加工作量转换为优先级带。