快速答案：先保留页面级证据
Googlebot 抓取异常排查要先回到原始日志、URL 状态、robots、服务器响应和渲染证据。只有确认异常发生在同一页面组或同一模板后，才适合进入修复。
基础事实：先看这些字段
| 排查对象 | 抓取频率异常、5xx、404、重定向链、robots 阻断和重要页面未被访问。 |
|---|---|
| 第一证据 | 服务器日志、Search Console 抓取统计、页面状态码和时间窗口。 |
| 常见误判 | 把低价值页面少抓取、短期波动或缓存差异误当成全站故障。 |
| 修复顺序 | 先保证重要 URL 可访问、可抓取、可渲染，再处理 sitemap 和内链入口。 |
| 验收方式 | 普通 URL 与 cache-bust 都要 200，canonical 和 robots 信号保持一致。 |
从日志和页面组开始
先按目录、模板、语言路径和业务价值拆分 URL。只有同组页面连续出现异常，才说明可能存在共同原因。
单个 URL 偶发异常不应直接触发全站改动。先记录时间、状态码、用户代理、服务器节点和是否命中缓存。
区分抓取问题和索引问题
Googlebot 没有抓取、抓取后不收录、已经收录但排名下降，是三类不同问题。
没有抓取时看发现路径和访问条件；抓取后不收录时看 canonical、重复内容和页面价值；排名下降时再看意图和竞争页面。
用可回退动作处理异常
修复动作应从最小范围开始，例如单个模板、单类重定向或一组重要 URL。不要因为一条报错就改全站规则。
复验时保留普通 URL、cache-bust、日志样本和下一次观察窗口。
参考要点：发布前后怎么验收
修复或发布后，先验收公开页面本身：HTTP 状态、canonical、robots、标题、正文、图片、FAQ JSON-LD、内部链接和移动端阅读效果。
如果普通 URL 与 cache-bust URL 看到的内容不同，优先定位缓存层；如果两者一致但内容结构仍差，再回到正文、模板或脚本层处理。
这类技术文章的结论应保持证据边界，不承诺收录、排名、流量或询盘结果。
延伸阅读
常见问题
这类技术诊断能直接保证排名恢复吗？
不能。诊断和修复只能证明页面条件、抓取条件或渲染条件被改善，最终收录、排名和流量仍由搜索引擎综合判断。
为什么要同时看普通 URL 和 cache-bust URL？
普通 URL 可能命中缓存，cache-bust 更容易看到新鲜结果。两者一致时，才更适合判断前台修复是否已经公开生效。
发现一个页面异常就要改全站模板吗？
不一定。先判断异常是否来自单篇正文、缓存、插件、模板还是服务器层。只有样本证明是共同组件问题时，才考虑模板级修复。
修复后应该保留哪些记录？
至少保留修复前页面、修复动作、负责人、上线时间、普通 URL 复验、cache-bust 复验、canonical/index 状态和下一次观察窗口。
