收录网站：多层缓存返回不同版本时怎样定位一致性问题
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /fc9b53792761.html
📄
收录网站：多层缓存返回不同版本时怎样定位一致性问题
先给结论：当同一收录网站页面在不同网络、不同账号或不同设备上看到不同版本时，不要先怀疑索引本身，而要先确认差异是否来自缓存层。判断依据是“变化是否与请求路径绑定”——如果清空本地缓存、换网络后版本随之改变，问题在缓存；如果所有路径都稳定返回旧版本，才需要继续查索引与内容层。
矛盾现象：同一收录网站页面出现两个版本
典型表现是：在办公网络打开收录网站的内页，标题和正文是旧版；用手机流量打开同一地址，却是新版。或者未登录状态看到旧版，登录后台预览看到新版。两种版本都“看起来正常”，没有报错，这最容易让人误判为搜索引擎只抓到了旧版。
此时要先固定一个前提：你比较的是同一个 URL，而不是带参数的变体。如果地址栏里出现了 ?v=、?from= 这类参数，那已经是不同请求，比较结果不成立。
两种解释：源站未更新，还是缓存各自为政
解释一：源站确实只发布了旧版。发布流程中，新内容写入了草稿库或某个分片，但对外读取的库、模板或静态文件没有同步。这时所有缓存层拿到的都是旧内容，缓存只是忠实转发。
解释二：源站已是新版，但多层缓存各自保存了不同时间的副本。常见链路包括浏览器缓存、CDN 边缘节点、反向代理缓存、应用层对象缓存。每一层都有自己的过期时间和键规则，某一层提前刷新、另一层未刷新，就会出现版本分裂。
两种解释的处置方向完全相反：前者要改发布流程，后者要改缓存失效策略。用错方向，会反复“清缓存”却始终不生效。
区分两种解释的证据：看版本随什么变化
可以按下面这组对照来收集证据，注意每步只改一个变量：
- 换一个从未访问过该页的浏览器或无痕窗口。若立刻是新版，说明本地浏览器缓存是旧版来源之一。
- 换网络（例如从公司 Wi-Fi 切到手机热点）。若版本改变，说明差异发生在网络路径上的缓存节点，而不是源站。
- 在 URL 后加一个无意义参数请求同一页面。若带参数是新版、不带参数是旧版，说明缓存键没有包含该参数，命中了旧副本。
- 直接请求源站 IP 或绕过 CDN 的回源地址。若回源是新版而对外是旧版，问题被锁定在 CDN 或反向代理层。
如果以上四步拿到的始终是同一个旧版本，那么更可能是源站未真正更新，而不是缓存分裂。这时应回到发布流程检查，而不是继续刷新缓存。
一个注明假设的短例子
假设某收录网站的文章页设置了浏览器缓存 10 分钟、CDN 缓存 1 小时、应用层对象缓存 5 分钟。运营在 10:00 更新了正文。10:05 后应用层已过期并回源取到新版，但 CDN 仍持有 09:30 生成的旧副本，于是外部访客看到旧版，而后台预览（不走 CDN）看到新版。这个例子说明：多层缓存过期时间不一致时，旧版本会在最慢的那一层存活到它自己的过期点。据此，下一步动作应是缩短关键内容页的 CDN 缓存时间，或在发布时主动触发对应 URL 的缓存失效，而不是反复重发内容。执行后再次用“换网络 + 无痕”对比，若两处版本一致，才能进入索引层复查。
确认一致后再看收录状态
版本一致并不等于收录正常。需要分别核查：robots.txt 的抓取限制只影响抓取，不等于可靠的索引移除；站点地图提交不保证收录；HTTPS 也不保证安全无漏洞或排名提升。不同搜索引擎对缓存、抓取和索引的处理与支持情况不同，应分别核查，不要用一家的表现推断另一家。
把顺序固定下来：先确认对外返回的版本唯一，再判断抓取与索引状态。这样后续任何波动都有可比对的基线，不会把缓存造成的版本差异误当成收录故障。
