百度不收录：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /716c43a510bf.html
📄
百度不收录：多层缓存返回不同版本时怎样定位一致性问题
先把“百度不收录”这个判断降级为待验证假设：你看到的差异未必发生在百度侧，而可能来自浏览器、CDN、反向代理、应用缓存、对象存储或抓取工具各自拿到不同版本。定位一致性问题的核心动作是固定一个URL，用同一请求头序列逐层取样，比较状态码、响应头和正文指纹，直到找出第一个不一致的层，再决定是清缓存、改键规则还是改发布流程。
先固定一条可复现的取样路径
不要一上来就刷新页面看结果，那样变量太多。选一个具体URL，记录它当前的完整响应：HTTP状态码、Content-Length、ETag、Last-Modified、Cache-Control、Age，再对正文做一次哈希。假设这个页面刚发布过内容更新，但不同人看到旧标题和新标题，那么这条记录就是基准线。
取样顺序建议从外到内：先绕过本地浏览器缓存，再检查CDN边缘节点，再看反向代理，最后看应用或对象存储。每一步都保留原始响应，不要只看渲染后的页面截图。正文哈希比“看起来一样”可靠，因为空格、编码和注入脚本都可能造成肉眼难辨的差异。
把“不同版本”拆成可区分的证据
版本不一致通常有几种可区分的原因，处理方式完全不同：
- 缓存键设计过粗：同一URL因设备、地区、登录态或查询参数不同，被分配到不同缓存对象。证据是带不同请求头取样时，
Vary或缓存键规则解释得通。 - 多层TTL不一致：CDN已过期，反向代理仍返回旧内容，或反过来。证据是各层
Age和Cache-Control对不上，且刷新后只有某一层变化。 - 发布未原子化：静态文件、模板和数据分多次上线，中间窗口内组合出混合版本。证据是同一时间不同层引用不同资源版本号。
- 抓取工具自身缓存：本地DNS、代理或调试工具留存了旧响应。证据是换网络、换工具后结果改变，而服务端日志没有对应请求。
这里的关键取舍是：不要用“清一次缓存”解决所有情况。缓存键问题清完还会复现；发布原子性问题清缓存只是掩盖了流程缺陷。先归类，再动手。
用一次对照请求判断问题在哪一层
选两个时刻做对照：发布后立即请求一次，等待超过最长TTL后再请求一次。两次都记录完整响应头和正文哈希。假设第一次CDN返回旧哈希、应用返回新哈希，第二次CDN也变成新哈希，那么问题更可能是CDN TTL尚未到期，而不是百度不抓取。反过来，如果应用层自己都返回旧内容，那百度看到旧版本只是结果，不是原因。
这个动作的结果会直接决定下一步：如果第一个不一致层在CDN，检查缓存键和刷新机制；如果在反向代理，检查代理缓存规则和回源头；如果在应用或对象存储，检查发布流程和版本指针。不要跳过中间层直接去改百度相关配置，那会让后续核对失去参照。
把分歧转成可核对的项目记录
当多个角色对“页面到底是什么版本”有不同理解时，口头争论没有意义。建一张最小核对表，每行是一次取样：时间、取样位置、请求头摘要、状态码、正文哈希、与基准是否一致。谁看到旧版本，就补一行自己的取样条件。这样分歧会收敛为“哪一层、在什么条件下、返回了哪个版本”。
如果核对后发现百度侧拿到的确实是旧版本，再考虑抓取和索引层面的动作；如果百度侧拿到的已经是新版本，那么“百度不收录”的表述就不准确，问题应回到收录判断本身。注意，robots.txt限制抓取不等于可靠的索引移除，站点地图也不保证收录，这两点只能作为辅助信息，不能替代版本一致性核对。
最后给一个可执行的收尾条件：当同一URL在所有取样层的正文哈希一致，且持续超过最长TTL后仍一致，才把版本问题标记为关闭。关闭后再观察百度侧表现，否则你会在一个还没稳定的版本上反复调整，下一步动作也就没有可靠依据。
