SEO 指南 July 31, 2026 8 分钟阅读

谷歌 SEO 六层诊断流程图：先定位最早失败的层级

一套真正有用的谷歌 SEO 诊断流程，不是再给你一张更长的 checklist，而是当页面没有 impressions、落到错误语言页、曝光不转 clicks，或 clicks 不转下一步动作时，告诉你应该先查哪一层。

最实用的规则只有一句：把症状路由到最早失败的层级。Google 的 SEO 入门指南、Search Essentials、链接可抓取指南、JavaScript SEO 基础、canonical 文档、URL 检查工具帮助、网页索引报告帮助和效果报告帮助一起定义了这六层应该怎么查。

谷歌 SEO 诊断流程图：把常见症状路由到最早失败的层级

直接答案：不同症状应该先去查哪一层？

症状	优先检查层级	先看什么	不要先做什么
新页面几乎没有 impressions	先查发现，再查抓取	内部 `<a href>` 链接、sitemap、状态码、robots	还没证明页面能被找到和抓到，就先重写标题
Search Console 显示“已发现”或“已抓取”但未收录	先查渲染，再查索引	raw HTML、rendered DOM、`noindex`、canonical、重复簇、页面价值	信号还在冲突时，不要反复请求收录
错误 URL 或错误语言页在拿展示	查索引	自引用 canonical、hreflang、内链、重定向、translations	不要先把问题归咎于排名
已有 impressions，但 clicks 很弱	查排名	查询与页面是否匹配、title、首屏答案、结果页格式、摘要兑现度	不要把低 CTR 直接等同于“这个词没戏”
已有 clicks，但没有带来动作	查转化	下一步动作是否清楚、CTA 是否贴合阶段、布局与埋点是否有效	不要把流量本身当作终点

这篇是整个集群里的“路由页”。更完整的工作流看 Google SEO 指南，完整审计执行看谷歌 SEO 审计清单，如果问题明显落在第四层，再进入 Google 收录故障排查。

如果分歧不是“先查哪一层”，而是“这个判断到底有多强的证据”，下一步就接到谷歌 SEO 证据矩阵。一旦路由清楚，就把发现记进可下载的谷歌 SEO Audit 工作表，再开始改模板或正文。如果你想看这条路由怎样落到一组真实 Fennec 双语页的发布健康检查上，可继续看谷歌 SEO 检查示例。

六层诊断流程

第一层：发现

先问一个问题：Google 能不能通过可抓取路径找到首选 URL？

检查：

是否至少有一个来自可索引页面的真实 <a href> 内链；
XML Sitemap 是否列出首选 canonical URL；
URL 结构是否稳定，而不是依赖隐藏参数或跳转；
页面是否成为话题集群里的孤岛页。

常见失败模式：

链接只有在 JavaScript 交互后才出现；
sitemap 列的是一个 URL，模板实际内链指向另一个 URL；
支柱页链接到的是重定向地址或跟踪变体。

验收方式是：同一个首选 URL 同时出现在源 HTML 内链、sitemap 和最终 200 页面里。在 Fennec 里，链接检查工具和 Sitemap 检查工具适合先找候选问题，但最终仍要回到源 HTML。

第二层：抓取

确认“能发现”之后，再确认 Googlebot 能否拿到稳定响应。

检查：

最终状态码和跳转跳数；
robots.txt 是否允许抓取页面及关键资源；
响应头里的 X-Robots-Tag；
同一 URL 是否能稳定返回一致响应。

常见失败模式：

soft 404 或空错误壳子仍返回 200；
你希望 Google 读取 noindex，却又被 robots.txt 挡住；
内链让 Google 先经过不必要的跳转链。

验收时看最终 HTTP 响应，而不是只看浏览器能不能打开。如果页面连稳定、真实的响应都给不出来，后面的内容优化都不是主修复点。

第三层：渲染

如果页面可抓取但行为仍异常，就对比 JavaScript 前后到底发生了什么。

检查：

raw HTML；
rendered DOM；
Search Console URL 检查里的 Google 视图（若可用）；
title、H1、正文、canonical、robots 指令和内链是否都存在。

常见失败模式：

主体内容依赖一个会失败的客户端请求；
canonical 或 hreflang 在 hydration 后被替换；
给用户看的下一步 CTA 存在，但 Google 渲染后 DOM 里并没有。

验收标准是：关键内容不依赖脆弱的客户端状态。在 Fennec 里，可以先用 Bot Simulator做快速对比，再回到 Search Console 核对 Google 侧状态。

第四层：索引

这一层的问题是：Google 是否接受了你想要的 URL，作为正确的索引入口。

检查：

noindex 或 X-Robots-Tag；
自引用 canonical，还是 canonical 到其他 URL；
是否存在重复或近重复版本；
hreflang 和语言路由是否一致；
Google 选择的 canonical 是否和你声明的一样。

常见失败模式：

英文页和中文页把信号持续送给错误同级页；
页面技术上可访问，但被 Google 当成重复簇处理；
页面能抓到，但内容过薄、过模糊，不足以占一个独立收录位。

验收时结合 URL 检查工具帮助和网页索引报告帮助，再和页面真实 HTML、内链一起对照。

第五层：排名

如果页面已经收录，接下来要问的是：它是否真的值得承接这个查询和结果格式。

检查：

页面类型是否符合当前结果页主流模式；
首屏是否直接回答任务；
页面是否增加了原创证据、流程或决策支持；
站内是否已有另一个页面更适合承接该意图。

常见失败模式：

用户需要工具或排查流程，你却发布了一篇泛指南；
多个页面都想覆盖同一个宽泛查询族；
只看 average position，就断定整页内容弱。

验收时看查询层 impressions、目标语言路由和页面角色是否清晰。如果页面拿到的展示对应错了任务，只改标题通常不够。

第六层：转化

有排名不是终点。最后一层问的是：这次访问有没有走向有价值的下一步。

检查：

搜索摘要承诺和落地页体验是否一致；
页面是否把下一步动作讲清楚；
CTA 是否符合读者当前阶段；
数据埋点是否真的记录了你关心的动作。

常见失败模式：

指南页带来 clicks，却没有明确下一步；
页面过早把用户推向不相关的产品页；
团队因为流量上涨就宣布成功，但没有任何合格动作增长。

验收时看页面到产品页的移动、工具启动、下载、demo 请求或其他明确业务动作。在 Fennec 里，指南页通常只在上下文充分时，才自然连接到网站审计、技术 SEO或 GSC Management。

一个实际可执行的 Fennec 工作流

Fennec 里最常见的三种情况，可以这样套用：

新子页面没有 impressions。先查发现和抓取：确认支柱页已经给出内链、sitemap 列的是同一 canonical URL，页面返回稳定 200。
中文查询落到英文页。先查索引路由：确认自引用 canonical、双向 translations、hreflang 和内链没有持续偏向错误语言 URL。
页面拿到 clicks，但没有带来审计启动。先查转化：对比搜索摘要、首屏答案，以及指向网站审计或其他工具的 CTA 是否出现在正确位置。

如果你在完成路由后需要完整审计队列，继续读谷歌 SEO 审计清单。如果症状明确卡在收录层，直接深入 Google 收录故障排查。如果你需要负责人和时间窗，再接上谷歌 SEO 30／60／90 天执行表。

这套流程的限制

这套流程可以减少盲改，但不会消除不确定性。

Search Console 会隐藏低量查询，数据也可能延迟出现；
URL 检查 live test 只能证明当前可访问，不能承诺未来一定收录；
一张排名截图不足以证明根因；
技术完全健康的页面，仍可能因为缺少独特价值而表现平平。

它的作用是缩小“最可信的首查层级”，不是把 SEO 伪装成完全确定的系统。

每次修复后都要记录什么

每次改动后，至少记录：

改的是哪个 URL 或模板；
变更发布日期；
你判断卡住的是哪一层；
当时支持该判断的证据；
准备重复的验证动作；
之后观察 impressions、clicks 或动作数据的窗口。

这才是“诊断流程”和“靠感觉排查”的真正区别。

来源

问答

谷歌 SEO 诊断流程最先应该决定什么？

最先要决定的是：最早失败的层级到底是哪一层，可能是发现、抓取、渲染、索引、排名或转化。起点应该是最早能解释症状的层，而不是最显眼的抱怨。

这和完整 SEO 审计是一回事吗？

不是。这篇的作用是把症状快速路由到正确起点；如果你需要完整证据表、抽样、负责人和优先级，再进入完整审计流程。

只看 Search Console 就能确定根因吗？

不能。Search Console 提供重要状态和表现信号，但仍要回到 HTML、渲染结果、canonical、内链和页面角色，才能把原因叫作已确认。

谷歌 SEO 六层诊断流程图：先定位最早失败的层级

直接答案：不同症状应该先去查哪一层？