真正有用的谷歌 SEO Audit 工作表，不是一个花哨表格，而是一张把每个问题都钉在真实 URL 或模板上的工作队列。它应该同时写清楚：最早失败层级是什么、证据是什么、谁来修、修完后怎么验证，以及哪天回来看结果。
下载模板：
表里自带的是示例行，不是真实站点数据。开始正式审计前，先删掉示例，再导入 Google Sheets 或 Excel，保留原列名，方便后续批次横向对比。
直接答案：这张工作表到底要记什么？
每一行至少回答六个问题：
- 受影响的是哪个 URL 或哪个模板；
- 最早失败的是哪一层；
- 哪份证据证明它真的有问题；
- 谁负责最小可行修复；
- 修完后用什么动作复核；
- 什么时候回来看结果。
如果这六项里有一项空着，这条发现通常还不够具体，不能排优先级。
这张资产最适合放在谷歌 SEO 六层诊断流程图之后、谷歌 SEO 审计清单之前：前者先帮你判断该查哪一层，后者再把这些行扩展成更完整的样本审计。如果团队连“什么算证据”都还没统一，就先回到谷歌 SEO 证据矩阵。如果你想看一组真实双语发布是怎样把“现在能填的字段”和“必须等 Google 数据的字段”分开处理，可继续看谷歌 SEO 检查示例。
工作表字段说明
| 列名 | 记录什么 | 为什么重要 |
|---|---|---|
URL或模板 | 完整 URL、路由模式或共享模板名 | 防止只写抽象问题，不写范围 |
语言 | en、zh 或 all | 让语言路由和 hreflang 问题显性化 |
页面角色 | 支柱页、子话题、产品页、Wiki、模板等真实角色 | 避免拿错页面类型去修 |
查询或任务 | 主要查询族或用户任务 | 保持和搜索意图绑定 |
失败层级 | 发现、抓取、渲染、索引、排名或转化 | 强迫团队先判断最早失败点 |
证据来源 | Response、源 HTML、Rendered DOM、URL Inspection、Performance report 等 | 把证明和猜测分开 |
证据摘要 | 一句客观事实 | 方便交接，不用重写问题 |
Google状态 | 已索引、已抓取未收录、备用页、canonical 冲突等 | 保留 Google 当前视图 |
优先级 | P0、P1、P2 或观察 | 显式表达紧急程度 |
负责人 | 工程、内容、SEO 运营、数据等 | 让发现变成行动 |
下一步动作 | 最小安全修复 | 避免无限扩大改动面 |
验证检查 | 准备重跑的检查动作 | 让“修复完成”可被验证 |
验证日期 | 计划复核日期 | 防止改完就忘 |
状态 | 示例、处理中、已修复、验证中、观察 | 让队列可持续维护 |
备注 | 样本 URL、发布批次、限制说明 | 保留上下文，但不污染主字段 |
一行应该怎么写，才算能执行？
先从症状开始，但不要把症状直接当结论。
没用的写法：
流量跌了，可能是内容质量差。
能执行的写法：
/zh/blog/google-seo-guide/->索引-> URL Inspection 显示自引用 canonical 正确，但正文内链持续偏向英文页 -> 补强中文集群回链 -> 等下一次抓取后在 Search Console 复核 query-page-language 路由。
这种结构的价值在于：每一个动作都能对应到一个已观察状态，而不是靠感觉推进。
这张工作表的实际使用顺序
1. 先路由，不要先填表
先用谷歌 SEO 六层诊断流程图判断这次最早失败的是发现、抓取、渲染、索引、排名还是转化。不要凭印象直接填。
2. 先写证据，再写解释
适合写进表里的证据来源包括：
- 线上 HTTP 响应；
- 源 HTML；
- rendered DOM；
- URL Inspection；
- 网页索引报告；
- 效果报告；
- Fennec 的 Audit、链接检查工具、Canonical 检查工具、Sitemap 检查工具和 Bot Simulator。
如果一行里只有“工具告警”，没有可重现实测，这行还没写完整。
3. 一行只放一个问题
如果十个页面都受同一个模板缺陷影响，就把“模板”写成主体，样本 URL 放在 备注。如果一个页面同时有三种问题，就拆成三行，否则负责人和验证日期会混在一起。
4. 下一步动作要足够小
不要写“提升页面质量”或“继续优化 SEO”。应该写能落实的最小动作，例如：
- 从支柱页补一条可抓取正文内链；
- 移除错误语言 canonical；
- 恢复渲染后缺失的主文章正文；
- 重写首屏答案，让它更贴近主查询任务；
- 把 CTA 放到用户真正需要下一步的位置。
5. 发布前就定义好验证动作
没有验证动作，这一行就不算完成。常见验证方式包括：
- 源 HTML 与 sitemap 都指向同一个首选 URL；
- URL Inspection 与线上响应对 canonical 判断一致；
- rendered DOM 已经包含缺失正文；
- Search Console 开始让目标查询落到目标语言页；
- 页面终于把有效访问送到 GSC Management或其他合理下一步。
这张资产怎么接回整个集群
需要页面角色边界和完整工作流时，先回谷歌 SEO 指南。需要把行项目扩展成抽样、负责人和优先级更完整的审计批次时，转到谷歌 SEO 审计清单。如果团队总把 Google 官方说明、页面实测和行业推论混在一起，就先用谷歌 SEO 证据矩阵统一口径。
在 Fennec 里的实际顺序通常是：
- 先用 Audit或专项检查器找候选问题；
- 用六层诊断流程图判断起点；
- 把发现记进这张工作表；
- 上线后再用 Search Console 或 GSC Management验证结果。
这样做，审计才会从“很多 warning”变成“可以复盘的运营系统”。
这张工作表主要防哪几类误判？
把症状直接写成根因
“点击低”不是根因。“搜索结果承诺的任务和页面实际交付不一致”才是可验证的候选原因。
把 Google 规则和猜测混写
如果某一行写的是“Google 因为 dwell time 惩罚了这页”，那证据列已经出错了。Google 文档、页面实测和解释性推论必须分开。
什么都标 P0
不是每个 warning 都值得最高优先级。错误语言 canonical 落在高价值落地页上，可能是 P0 或 P1；一条准确但不够强的 meta description，通常不是。
改完 CMS 字段就把行关掉
一行不是“有人改了”就算结束，而是必须等你写下来的验证动作真的确认状态改变，才算完成。
双语集群第一批最值得先写哪些行？
对于英文 + 简体中文的 Google SEO 集群，第一批工作表行通常优先覆盖：
- 一组支柱页；
- 一组子话题页；
- 一个承担转化接力的产品页；
- 一个负责发现支持的 Wiki 页；
- 一个模板级发布风险，例如 canonical、hreflang 或渲染漂移。
这个范围足够发现重复缺陷，也不会假装整站已经被完整审计。
来源
- Google Search Central：SEO 入门指南
- Google Search Central：Search Essentials
- Google Search Central：技术要求
- Google Search Central：让链接可供 Google 抓取
- Google Search Central：JavaScript SEO 基础
- Google Search Central：构建并提交 Sitemap
- Google Search Console 帮助：网址检查工具
- Google Search Console 帮助：网页索引报告
- Google Search Console 帮助：效果报告
问答
谷歌 SEO Audit 工作表里最少应该记录什么？
至少要记录受影响 URL 或模板、最早失败层级、证据、负责人、最小修复动作，以及准备复核的日期。
一行应该代表一个页面，还是一个问题？
一行应代表一个有证据支持的问题。如果同一个模板影响很多 URL，就把模板写成主体，并在备注里列代表性样本。
有了工作表，还需要 Search Console 吗？
需要。工作表负责整理决策，真正的证据仍来自 Search Console、线上响应、渲染结果和页面实测。
