网站被百度收录：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fe8a16be28bd.html
📄
网站被百度收录：多层缓存返回不同版本时怎样定位一致性问题
如果同一 URL 在不同网络、不同机房或不同请求头下返回的 HTML 不一致，而你已经确认源站模板没有分叉，那么优先怀疑的不是百度抓取本身，而是缓存链路里存在“按维度分片”的副本：CDN 边缘节点、反向代理缓存、应用层页面缓存各存了一份，且失效时间或键规则不同。定位顺序应从离源站最近的一层往外逐层冻结，而不是先动 robots.txt 或提交入口。
先确认“不同版本”差在哪些字节，而不是差在观感
多层缓存导致的不一致，通常不是整页完全不同，而是局部字段错位。用同一 URL 连续取三次响应，分别记录：HTTP 状态码、Content-Length、Last-Modified、ETag、Age、X-Cache 一类回源标记，以及正文中与收录直接相关的部分——title、canonical、hreflang、分页链接、结构化数据块。把三次结果并排比对，先找出第一处出现差异的字段。这一步的价值在于：如果差异只出现在 canonical 或分页链接上，问题多半在应用层缓存键漏掉了分页参数；如果 title 与正文主体一起变化，更可能是 CDN 缓存了旧版整页。
需要提醒的是，抓取工具看到的状态码一致，并不能证明内容一致。304 与 200 都可能携带不同正文，必须落到字节层面比较，否则会把“缓存命中”误判为“版本一致”。
按缓存层级逐层冻结，找出哪一层在返回旧副本
有效做法是给请求加一个能穿透缓存的标记，例如带随机查询串或特定请求头，观察响应是否回到源站版本。假设源站版本为 A、CDN 版本为 B、代理版本为 C，可以按下面的顺序做：
- 直接请求源站（绕过 CDN 与代理），确认当前发布版本是哪一个。
- 固定同一台边缘节点，重复请求同一 URL，看响应是否稳定落在 B 或 C。
- 更换节点或地区再请求，判断差异是“单节点残留”还是“全局旧版本”。
- 对应用层缓存单独清一次，再观察 CDN 是否仍返回旧内容。
如果清掉应用层缓存后，CDN 仍返回旧版本，说明 CDN 的缓存键或 TTL 才是主因；如果 CDN 已更新、代理仍返回旧内容，则问题在反向代理的失效通知没有送达。这个判断会直接决定下一步是改缓存键、缩短 TTL，还是修失效回调。
一个会让上述结论失效的反例
如果差异只出现在带 Accept-Encoding 或 User-Agent 变化的请求上，而普通请求完全一致，那么问题可能不是缓存副本，而是内容协商或压缩层在按请求头返回不同变体。此时逐层清缓存不会解决问题，反而会掩盖真实原因。判断方法是：固定其他条件，只改一个请求头，看差异是否稳定复现。稳定复现，就应先查变体缓存键是否包含了该请求头；不稳定复现，才回到缓存副本的排查路径。
用可复现的最小对照，决定下一步动作
假设某分类页在源站已把 canonical 从第 1 页指向自身、第 2 页指向第 1 页，但 CDN 仍返回旧 canonical。清一次 CDN 后，若该 URL 的 canonical 立即正确，且 24 小时内不再回退，说明是 TTL 与失效通知的问题，下一步应检查发布流程是否在内容更新后主动触发失效，而不是等自然过期。若清完后短时间内又回退，说明缓存键没有包含会改变 canonical 的维度（如分页参数、语言参数），下一步应改缓存键规则，而不是反复手动清缓存。
对百度收录而言，canonical 与分页链接长期不一致，会让抓取端在不同时间拿到互相矛盾的信号，进而影响对页面关系的判断。但要注意，缓存一致性问题修好后，收录状态不会立刻同步变化；抓取量或某条统计归零，也不能单独证明处理正确，还需要结合后续抓取日志中该 URL 返回的版本是否稳定来确认。
交接给开发或运维时，带上可验证的对照记录
把“某页面缓存有问题”换成可执行的记录：同一 URL、同一时间窗、不同缓存层返回的 title 与 canonical 对照，以及穿透缓存前后的响应差异。这样对方能直接定位到是缓存键、TTL 还是失效回调，而不是重新从“有没有被收录”开始排查。记录里应注明测试是否绕过了 CDN、是否固定了节点，避免把网络波动当成版本差异。
完成上述对照后，下一步不是立即提交收录，而是先确认源站、CDN、代理三层对同一 URL 返回的版本已经收敛到同一个结果，再观察抓取端拿到的版本是否随之稳定。只有这一步稳定了，后续关于收录的讨论才有意义。
