seo-site-health-audit

SEO 网站健康度审计

根据对排名和流量的影响，而不是问题数量或严重程度标签，对 Ahrefs Site Audit（或任何同类爬虫）的技术 SEO 发现进行分类。与技术栈无关。生成按优先级排列、并与业务影响对应的修复待办清单。

---

适用场景

• 运行 Ahrefs Site Audit 或其他全站爬取后
• 审查大量技术问题并需要确定优先级时
• 规划技术 SEO 冲刺时
• 上线前或迁移后的技术验证
• 每季度进行技术健康检查
• 开发人员时间有限，必须选择收益最高的修复项时

不适用场景

• 执行爬取本身（请直接使用爬虫工具）
• 诊断具体的流量下降（请使用 seo-traffic-diagnosis）
• 单页审计（请使用 seo-onpage）
• 纯技术策略或 Schema 设计（请使用 seo-technical）

---

所需输入

• Ahrefs Site Audit（或同类工具）的爬取结果
• Search Console 覆盖率和 Core Web Vitals 数据
• 网站资源的自然流量概况（哪些页面带来流量）
• 可用的相关方时间和开发人员产能
• 仅当通过 Ahrefs 获取爬取结果时，需确认 Ahrefs MCP 已连接。提供任何同类爬虫的导出文件即可单独满足第一项输入。

---

框架：按 SEO 影响分类，而非按严重程度

爬虫会将问题标记为“严重”“警告”“提示”。这些标签有用，但并不足够。两个都标为“严重”的问题，对网站资源的实际影响可能截然不同。

从三个维度进行分类。

维度 1：页面级流量影响

问题影响的是带来大量自然流量的页面，还是没有带来流量的页面？

一个流量为零的标签归档页上的“严重”问题，优先级低于流量排名前 10 的落地页上的“警告”问题。

按受影响的 URL 分级：

• 第 1 级： 按自然流量排名前 10% 的页面
• 第 2 级： 有排名但尚未带来显著流量的页面（搜索结果第 2 至第 3 页）
• 第 3 级： 存在但没有显著排名的页面

在大多数情况下，修复第 1 级页面的价值是修复第 3 级页面的 10 倍。

维度 2：影响机制

这个问题是否真的会影响排名或流量？有些“严重”问题只是外观问题或理论上的问题。

为每个问题评定 HIGH、MEDIUM 或 LOW。每种问题类型的等级及各等级定义，以 references/issue-impact-table.md 为准。请在那里查找问题，而不是重新判断，并采用其中给出的等级。

参考文档覆盖的问题类别按查找顺序为：可索引性、可抓取性、可渲染性、Core Web Vitals、结构化数据、内部链接完整性、hreflang、页面元素、图片、安全与信任。文档还列出了通常不值得专门投入处理、应搁置或跳过的发现。

同一类别中的不同问题可能有不同等级。可索引性问题大多为 HIGH；内部链接完整性的问题则逐项从 MEDIUM 到 LOW 不等。必须按具体问题行评定，不能按类别评定。

优先修复第 1 级 URL 上等级为 HIGH 的问题。

维度 3：工作量

有些问题只需 5 分钟即可修复，有些则需要多个冲刺。

• S（小）： 配置更改、单个模板编辑、重新生成站点地图
• M（中）： 主题或组件更改、重定向映射工作、模板级修复
• L（大）： 架构更改、重新搭建平台、框架迁移、Schema 全面改造

---

分诊矩阵

将三个维度合并为优先级评分。

这里的机制是问题影响表为该问题标注的 HIGH / MEDIUM / LOW 等级。三个等级都有对应行：参考表将很大一部分问题类型评为 MEDIUM，而 Tier 1 页面上的 MEDIUM 问题仍需要划分优先级。

层级	机制	工作量	优先级
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 行遵循一条规则：在相同层级和工作量下，MEDIUM 问题的优先级比 HIGH 问题低一档。参考表评级为 LOW-MEDIUM 的问题，如果 URL 属于 Tier 1，则采用 MEDIUM 行；否则采用 LOW 行。

P0-P1 工作优先占用团队精力。P2 纳入路线图。P3 批量纳入常规维护。暂缓则如实体现降级处理。

---

工作流

1. 获取抓取结果。 使用 Ahrefs Site Audit + Search Console + Core Web Vitals。
2. 划分 URL 层级。 使用自然流量数据。将每个受影响的 URL 标记为 Tier 1、2 或 3。
3. 按机制对每个问题分类。 在 references/issue-impact-table.md 中查找 HIGH、MEDIUM 或 LOW 等级。
4. 估算每种修复类型的工作量。 将相似修复归为一组，并估算工作量。
5. 应用分诊矩阵。 分配 P0-P3 或暂缓。
6. 对修复进行聚类。 将工作量相同的修复归为一组：一次模板修改就可能解决数百个问题。
7. 建立待办列表。 先列 P0，再列 P1，以此类推。添加修复说明、负责人和预期影响。
8. 加入衡量方式。 哪项指标可以确认修复有效？发布前先定义。
9. 移交。 输出将进入开发待办列表和 seo-audit-orchestration。
10. 修复后重新抓取。 确认问题已解决，并更新待办列表。

---

值得关注的高杠杆聚类

以下模式在修复后通常会带来显著成效：

• 全面清理重定向链。 更新一次站点地图并更新内部链接，就能一次性解决数千个“重定向链”问题。
• 模板意外设置了 noindex。 只需修改一行代码，就能让数百或数千个页面重新编入索引。
• 站点地图更新流水线。 站点地图重新生成任务出现故障，会影响所有依赖 Search Console 识别正确 URL 的问题。
• 分面导航中的 canonical 不一致。 修复模板级 canonical 设置，就能解决整个电商类目树中的重复内容问题。
• 恢复 robots.txt。 还原被回退的生产环境 robots.txt，可能在几天内挽回全站流量下滑。
• 修复 Hreflang 区块。 修改一次模板，就能解决整个多语言网站中的 Hreflang 问题。
• 在资源流水线中优化图像。 修复构建流程，就能解决数千个单独的资源问题。

发现这些模式时，即使单个问题看起来影响不大，也应优先处理。聚类后的影响很大。

---

失败模式

• 崇拜严重程度。 把每个标为“严重”的问题都当成真正严重的问题。很多并非如此。应根据机制和流量影响进行分诊。
• 只数问题。 报告“我们修复了 1,200 个问题”，却不说明流量或排名影响，会损害工程团队的公信力。
• 跳过分级。 在修复 5 个 Tier-1 问题之前先修复 100 个 Tier-3 问题，只是在瞎忙。
• 逐个修复问题。 大多数问题都是成群出现的。若有 800 个问题根因相同，只修复一条重定向链并不是正确的工作单位。
• 不重新抓取。 不验证就声称“已修复”，会让人存疑。重大修复后务必重新抓取。
• 忽略 Search Console。 Ahrefs 只能看到其爬虫发现的内容。Search Console 反映 Google 实际看到并编入索引的内容。两者都要用。
• 把 Core Web Vitals 当成清单。 CWV 是现场数据，不是实验室数据。应针对真实用户体验优化，而非合成评分。
• 为了好看而修复机制影响低的问题。 技术报告再漂亮，若没有流量提升，也毫无帮助。
• 不做衡量。 修复之前，先定义能证明修复有效的指标。

---

输出格式

一份网站健康状况分诊文档，包含：

1. 摘要。 问题总数、排名前三的修复集群、预期影响；若存在数据缺口，则按数据可用性规则说明。
2. URL 分级。 URL 的分类方式及各级数量。
3. 问题分类。 按机制类别、级别和优先级区间统计数量。
4. 优先级待办事项。 按 P0-P3 排序。每项包含：问题、受影响的 URL、修复说明、工作量、预期影响、负责人。
5. 修复集群。 将可通过同一修复方式解决的问题分组，并按杠杆效应从高到低排列。
6. 衡量计划。 针对每项修复或集群，说明如何证明其有效。
7. 方法。 使用的爬虫、日期、范围、注意事项。

长度：5-12 页，另附待办事项电子表格。

---

所需数据不可用时

此技能的输出依赖于它无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时，获准的输出是说明数据缺口的交付物：需要什么、实际获取或验证了什么，以及输出中哪些部分受到影响。绝不可为了完成交付物而捏造、估算或插补所需数值。说明数据缺口本身就是完整的答复。

---

参考文件

• references/issue-impact-table.md - 常见爬虫问题对应的机制等级和典型修复工作量映射表，另含集群信号及暂缓或跳过清单。此文件是每个问题等级的权威来源；上方的分诊矩阵会将等级、级别和工作量转化为优先级区间。