网站索引优化，多层缓存返回不同版本时怎样定位一致性问题
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /e5e1262b6601.html
📄
网站索引优化，多层缓存返回不同版本时怎样定位一致性问题
先看一个典型矛盾：同一 URL 在 CDN 边缘节点返回旧版 HTML，回源却拿到新版；搜索引擎抓取到的页面标题、正文和站内实际渲染不一致。要定位一致性，不能只看某一个缓存层，而要在同一请求链上逐层比对“缓存键、缓存状态、响应变体”这三类证据。缓存键不一致通常表现为部分节点或部分用户拿到旧版；缓存状态不一致通常表现为回源正常但边缘持续旧版；响应变体不一致通常表现为同一 URL 因 Cookie、语言、设备或压缩方式不同而返回不同内容。
矛盾现象：回源正确，抓取结果却像旧版
这类现象常见于页面更新后：源站已经发布新标题、新价格或新正文，但搜索摘要、抓取快照或部分地区访问仍显示旧内容。它不一定说明索引没更新，也可能是某一层缓存把旧响应继续给了爬虫。要区分“索引问题”和“缓存一致性问题”，先确认抓取请求实际经过了几层缓存：浏览器缓存、CDN 边缘缓存、反向代理缓存、应用层对象缓存、数据库查询缓存，任何一层返回旧版本，都会让最终响应看起来像旧版。
此时最危险的动作是直接提交重新抓取或改 robots.txt。重新抓取只能让爬虫再次请求，如果请求仍被旧缓存命中，结果不会改变；robots.txt 的抓取限制不等于可靠的索引移除，也不解决缓存版本不一致。正确顺序是先固定一个可复现请求，再沿链路逐层排除。
两种解释：缓存键设计问题，还是响应变体污染
第一种解释是缓存键设计问题。缓存系统按某个键存储响应，如果键没有包含影响内容的全部维度，例如只按路径缓存，却忽略查询参数、语言、登录状态、A/B 测试分组或移动端标识，那么不同版本会互相覆盖。表现是：同一 URL 在不同时间、不同节点、不同用户之间随机返回新旧版本，回源日志却显示源站每次都返回正确版本。
第二种解释是响应变体污染。缓存键本身完整，但源站或中间层对同一键返回了不同变体，例如压缩与非压缩、HTTP 与 HTTPS、带尾斜杠与不带尾斜杠、大小写不同的路径、不同 Accept-Encoding 或不同 User-Agent 触发不同模板。表现是：某类请求稳定拿到旧版，换一个请求头或换一个入口就拿到新版，且旧版不是随机出现，而是与某个请求特征绑定。
区分证据：看缓存状态、命中键和变体头
要区分这两种解释，可以按下面顺序收集证据。假设一个页面更新后，爬虫抓取仍显示旧标题，而人工在浏览器无痕窗口看到新标题，这只能说明两者请求特征不同，不能直接判定缓存层有问题。
- 固定请求并记录响应头。用同一 URL、同一方法、同一请求头分别请求边缘节点和源站，记录返回的缓存状态头、Age、ETag、Last-Modified、Vary 以及实际正文摘要。若边缘显示命中且 Age 很大，回源显示新内容，说明旧版停留在边缘层。
- 比对缓存键组成。检查缓存配置中该路径的键是否包含查询字符串、Cookie、语言、设备分组、协议和主机名。若键缺少某个实际影响正文的维度，就更接近第一种解释。
- 检查 Vary 与内容协商。若响应头声明按 Accept-Encoding、User-Agent 或 Cookie 变化，但缓存层没有按同样维度区分存储，就可能把一种变体返回给另一种请求。此时更接近第二种解释。
- 做最小差异请求。只改变一个请求特征，例如只改 Accept-Encoding，或只改语言头，观察返回版本是否稳定切换。若切换与单一特征强相关，说明是变体污染；若切换与节点或时间相关，说明是缓存键或过期策略问题。
- 查看回源日志与缓存日志的对应关系。若回源日志显示同一缓存键在短时间内收到多次不同响应，说明源站或应用层输出了不稳定变体；若回源日志稳定，而边缘返回不同版本，说明问题在缓存层。
取舍条件：先清缓存还是先改缓存键
如果证据指向缓存键缺少维度，先清缓存只能短期恢复，下一次不同变体写入后仍会互相覆盖。此时应优先修正缓存键，把影响正文的维度纳入键或明确禁止缓存。代价是缓存命中率可能下降，回源请求增加，需要评估源站承载能力。
如果证据指向响应变体污染，先改缓存键可能无效，因为键已经区分了维度，问题在于源站对同一键返回了不同内容。此时应优先稳定源站输出，例如统一尾斜杠、统一大小写、固定压缩策略、避免同一 URL 因登录态返回不同正文。代价是可能需要调整应用路由或模板逻辑，改动范围比清缓存大。
一个可操作的判断方法是：先做一次只清边缘缓存的受控动作，然后立即用固定请求复测。如果旧版不再出现，且后续不同请求特征也不再触发旧版，说明只是过期或单次污染；如果旧版很快再次出现，或只在某类请求特征下出现，就不要继续反复清缓存，应转向缓存键和变体检查。这个动作的结果直接决定下一步是修缓存配置还是修源站输出。
验证一致性时不要混淆索引与缓存
缓存一致性问题解决后，索引是否更新仍需要单独观察。站点地图不保证收录，提交 URL 也不保证立即替换摘要。若缓存层已经稳定返回新版，但搜索摘要仍旧，可能是索引尚未更新，也可能是抓取频率、页面权重或摘要生成策略导致，不能仅凭一次抓取结果归因。此时应保持同一 URL 的稳定响应，避免在排查期间频繁改标题、改状态码或改 robots.txt，否则会引入新的变量。
最终判断标准不是“某次请求看起来对了”，而是同一 URL 在边缘、回源和不同请求特征下都能稳定返回同一版本。达到这个状态后，再观察抓取和索引变化，才具备可比较的前提。
