真正有用的谷歌 SEO 审计，不是生成一百条警告，而是找出最早失败的层级，用证据确认影响，指定负责人，并定义可以验证修复是否成功的检查方式。
建议按照以下顺序：
- 发现；
- 抓取与响应；
- 渲染；
- 索引与规范 URL；
- 搜索意图与内容质量；
- 点击与业务结果。
Google 的 Search Essentials说明了进入搜索结果的最低技术要求、垃圾内容政策和核心实践。满足这些要求不代表保证抓取、索引或排名，因此审计必须区分技术资格、Google 已观察到的状态和实际表现。
如果你已经知道当前症状，只需要判断最可能先卡在哪一层，可以先走更短的谷歌 SEO 诊断流程图；当你需要完整证据表和审计队列时，再回到这篇。
先建立审计证据表
每个问题占一行。没有受影响 URL 和证据时，不要只写“canonical 有问题”或“内容质量差”。
如果团队总是把 Google 官方说明、页面实测和解释性推论混在一起，先用谷歌 SEO 证据矩阵统一证据口径，再分配修复动作。
如果你需要把这张证据表直接下载成可复用模板，方便审计交接、发布跟进和复盘，可以继续用可下载的谷歌 SEO Audit 工作表。如果你想看这张清单如何压缩成一次真实双语发布验收，可继续看谷歌 SEO 检查示例。
| 字段 | 应记录什么 |
|---|---|
| URL 或模板 | 完整 URL、路由模式或页面类型 |
| 预期角色 | 应索引、重定向、合并还是保持私有 |
| 失败层级 | 发现、抓取、渲染、索引、搜索匹配或转化 |
| 证据 | HTTP、HTML、截图、Search Console 状态或查询数据 |
| 影响范围 | 单个 URL、模板、语言版本或全站 |
| 优先级 | P0、P1、P2 或观察 |
| 负责人 | 开发、内容、设计、数据或运营 |
| 修复 | 能解决根因的最小改动 |
| 验证 | 用什么检查、在什么日期确认结果 |
这张表可以避免两个常见错误：把工具警告直接当成已确认故障，以及没有判断页面是否本来就应该索引便开始修复。
选择有代表性的页面样本
不要只审计首页。第一轮至少选择：
- 首页；
- 一个高价值产品或服务页；
- 一篇英文文章及其中文对应页；
- 一个 Wiki 或 Glossary 页面；
- 一个 JavaScript 较重的工具；
- 一个曾经有点击但近期下滑的页面；
- 一个 Search Console 报告未索引的 URL；
- 一个重定向、一个 404 和一个主动 noindex 页面。
如果缺陷来自共享组件，再从样本扩展到全部相关模板；如果只是单页问题，就保持范围，不要顺手重构全站。
第一层：Google 能否发现首选 URL
检查每个重要页面是否具备：
- 至少一个可抓取的
<a href>内链； - 稳定的首选 URL；
- 出现在正确的 XML Sitemap；
- 没有意外成为孤岛页；
- 内链直接指向最终地址，而不是重定向链。
Google 在链接最佳实践中建议使用可抓取链接和描述性锚文本。Sitemap 有助于发现，但不能替代导航，也不保证索引。
可先用 Fennec 的链接检查工具和 Sitemap 检查工具收集候选问题，再检查源 HTML，确认问题真实存在。
应保存的证据
- 链接来源页和实际锚文本；
- 链接存在于原始 HTML 还是只有渲染后才出现；
- Sitemap 地址和修改时间；
- 重定向经过几跳；
- 重要孤岛页候选列表。
第二层：Googlebot 能否获得正确响应
请求首选 URL 并记录：
- 最终状态码；
- 重定向目标和跳数；
- robots.txt 判定；
X-Robots-Tag；- 响应是否稳定；
- 重要 CSS、JavaScript 和图片资源能否访问。
页面通常需要返回 HTTP 200 和可索引内容才具备搜索资格。被 robots.txt 阻止的 URL 仍可能被 Google 知道，同时 Google 可能无法读取页面上的 noindex。可以使用 Robots.txt 检查工具，但还要查看真实响应。
curl -I -L https://example.com/preferred-page
curl -L https://example.com/robots.txt
常见故障模式
| 症状 | 可能原因 | 下一项检查 |
|---|---|---|
间歇性 5xx | 源站、部署或超时 | 服务器日志与 Crawl Stats |
错误页返回 200 | Soft 404 模板 | 主要内容和状态路由 |
| URL 连续跳转两次 | 旧内链或迁移链 | 内链与 Sitemap 来源 |
| robots.txt 阻止页面 | 规则冲突 | 页面应该被抓取还是移除 |
第三层：渲染结果是否包含重要内容
比较：
- 服务器返回的 HTML；
- 浏览器渲染后的 DOM；
- Search Console 的已索引视图和实时测试。
Google 的 JavaScript SEO 文档将抓取、渲染和索引描述为不同阶段。关键内容不应依赖用户点击、不稳定 API 或仅客户端存在的状态。
检查：
- title、H1、正文、链接、canonical 和 robots 指令；
- hydration 或 console 错误；
- 只有互动后才出现的内容；
- 不同设备、语言、Cookie 或登录状态下的差异；
- 只为爬虫隐藏的文字。
可以用 Fennec Bot Simulator进行对比，但 Google 的已记录状态和实时视图仍应使用 Search Console URL 检查。
第四层：Google 是否索引预期的规范 URL
对于单个 URL，URL 检查工具可以显示 Google 已索引版本、抓取详情和 Google 选择的 canonical。实时测试只能检查当前可访问性，不能预测所有索引决定，也不能保证 Google 最终选择哪个 canonical。
检查以下信号是否一致：
- HTTP 状态与重定向；
- HTML canonical；
noindex或X-Robots-Tag；- 内部链接；
- Sitemap URL；
- hreflang 对应关系；
- Google 选择的 canonical。
Google 的网页索引报告还强调：不是每个未索引 URL 都是错误。重复页、重定向、筛选 URL 和主动排除页面可能完全符合设计。
按页面意图诊断
| 报告状态 | 首先要问什么 |
|---|---|
| 已抓取，目前未编入索引 | 页面是否独立、完整并获得站内支持？ |
| 已发现，目前未编入索引 | 是否刚发现、服务器是否健康、URL 是否值得抓取？ |
| 重复网页，用户未选定规范网页 | 内链、重定向和 Sitemap 支持哪个版本？ |
| 备用网页，具有适当 canonical | 这是预期重复页，还是 canonical 误设？ |
被 noindex 排除 | 指令是否有意设置，且 Google 能否抓取？ |
| Soft 404 | 页面是否兑现承诺，并返回正确状态？ |
批量修改模板前，先用 Canonical 检查工具核对样本。
第五层：页面是否真正匹配查询
确认技术资格后，再审计搜索匹配。
对每个重要落地页记录：
- 主要用户任务；
- Search Console 中的主要查询；
- 这些查询当前主流结果类型；
- 首屏答案是否直接；
- 是否有原创证据、流程、数据或决策支持；
- 作者和来源是否清晰；
- 是否与站内另一个页面重叠；
- 是否获得相关主题集群的内链。
Google 的以用户为中心的内容指南强调原创信息、深入分析、清晰来源，以及相对于其他结果的额外价值。
不要只用字数衡量质量。简洁的工具页可能比长篇通用文章更好地完成任务；一篇两千字文章如果只是改写现有搜索结果，仍然缺少价值。
页面级检查
- Title 与 H1 做出同一个准确承诺；
- 前 100–150 字回答主要问题；
- 标题按照用户决策组织，而不是关键词变体；
- 时效性结论有当前一手来源；
- 示例明确标注“示例”或“实测”；
- 限制与失败模式清晰；
- 页面链接到下一步有用动作；
- 英中页面事实相同，但不是机械翻译。
第六层：搜索可见度是否产生有效结果
把四类指标分开：
- Impressions： Google 曾考虑让页面匹配查询；
- Clicks 和 CTR： 搜索结果获得访问；
- Engagement： 用户真正使用了页面；
- Conversion： 用户完成有价值的下一步。
有排名但 CTR 接近零，可能是意图或摘要问题；点击正常但没有下一步使用，则可能是产品、UX 或测量问题。
对于 Fennec，有效结果可以是从指南进入网站审计、启动技术检查、使用专项工具，或者返回监测修复效果。不要把每次访问视为同等价值。
不要夸大优先级
| 优先级 | 定义 | 示例 |
|---|---|---|
| P0 | 阻止高价值页面访问、索引或关键操作 | 全站 noindex、部署故障、canonical 指向错误域名 |
| P1 | 明显影响一个高价值模板或已有表现页面 | 渲染后缺少正文、canonical 指向错误语言 |
| P2 | 影响质量或效率，但没有立即大规模损失 | 摘要较弱、决策信息不足、内链经过重定向 |
| 观察 | 暂无足够证据支持修改 | 正常抓取波动、预期排除的重复页 |
优先级需要综合影响、范围、证据可信度和可逆性。工具显示红色，不会自动把问题变成 P0。
90 分钟第一轮审计
0–15 分钟：确定范围
- 列出收入、线索和高点击页面；
- 选择代表性模板；
- 记录近期发布或迁移；
- 导出最新页面级 Search Console 对比。
15–35 分钟：发现与抓取
- 抓取内链和 Sitemap；
- 抽样状态码与重定向；
- 检查 robots.txt 和响应头；
- 找出孤岛页和 Soft 404 候选。
35–55 分钟：渲染与索引
- 对比原始和渲染输出；
- 检查两个重要 URL 和两个排除 URL；
- 对比声明 canonical 与 Google 选择版本；
- 抽查一组双语页面的双向 hreflang。
55–75 分钟：内容与查询匹配
- 检查增长最多和下滑最多的落地页；
- 将主要查询与首屏答案对应；
- 找出一个重叠页面、来源缺口或缺少的决策模块。
75–90 分钟：行动计划
- 只保留有证据的问题；
- 指定负责人和优先级；
- 写明验证方法和复查日期；
- 选择一个能够安全完成的 P0／P1 批次。
审计最终应该交付什么
完成的审计不是包含数百条警告的 PDF，而是一份简洁队列，每项都包含：
受影响 URL 或模板 → 失败层级 → 证据 → 影响 → 负责人 → 修复 → 验证日期
从最早失败的层级开始，一次完成一个有限批次，再根据结果扩大范围。需要完整运营框架时，可回到谷歌 SEO 实战指南，或直接开始一次 Fennec 网站审计。
问答
谷歌 SEO 审计应该先检查什么？
先确认重要 URL 能被发现、抓取、正确渲染并具备索引资格，再检查关键词和外链。应优先修复最早失败的层级，因为后面的优化无法补偿前面的阻断。
所有未索引 URL 都需要修复吗？
不需要。重定向、重复 URL、筛选页、私有页面和主动 noindex 的页面可能本来就应该排除。操作前要比较 URL 的预期角色和 Google 报告的原因。
网站多久需要做一次 SEO 审计？
关键技术与流量信号应持续监控；模板发布后应做针对性检查；迁移、改版、流量下滑或大规模内容变动后应立即审计，正常情况下可每季度进行一次深度复查。
