内容改完了，自己刷新浏览器看到的是新版，但蜘蛛抓回去的仍然是几天前的旧页面——这种情况在启用 CDN 或页面缓存的站点上并不少见。缓存本身是站点运营里必要的一环，问题往往出在缓存策略没有跟着内容更新的节奏走。
为什么蜘蛛更容易拿到旧缓存
普通访客多数带着浏览器缓存访问，按一次刷新可能就绕过了缓存；而蜘蛛请求通常是一个全新的、干净的请求，它会正常命中 CDN 边缘节点或服务端页面缓存。如果这些缓存没有及时失效，蜘蛛拿到旧版本反而比访客更稳定。另一个常见原因是缓存键设置不当，比如只按 URL 缓存，却忽略移动端 UA、Cookie 或语言参数，导致不同版本的内容互相覆盖。
先分清站点上到底有几层缓存
- 浏览器缓存：由 Cache-Control、Expires、ETag 控制，影响重复访问的用户，也影响部分抓取工具的重复请求。
- CDN 边缘缓存：节点就近返回内容，更新后需要主动刷新或等待 TTL 到期。
- 服务端页面缓存与对象缓存：常见于 CMS 插件、反向代理（如 Nginx fastcgi_cache、Varnish）。
- 静态化与数据库查询缓存：静态文件不重新生成，前台就会一直停留在生成前的版本。
自查清单
- 检查 HTML 文档的缓存头。页面 HTML 一般不适合设置过长的强缓存，用较短的 max-age 配合 ETag 或 Last-Modified，让蜘蛛能拿到较新的版本；图片、CSS、JS 等带指纹的静态资源可以设长缓存。
- 确认 CDN 缓存键包含必要维度。至少区分 HTTP 与 HTTPS、移动端与桌面端（如果返回不同 HTML）、多语言或地区版本。
- 排查是否有页面在 CDN 上被设为永久缓存，或自定义 TTL 过长（例如 30 天）。内容型页面通常不适合这种设置。
- 检查缓存插件是否把登录态、表单结果、个性化推荐等私有内容缓存成了公共版本。
- 确认发布内容后是否有自动刷新（purge）动作。不少 CMS 插件只在保存时刷新当前 URL，首页、栏目页、列表页不会跟着更新。
- 检查 CDN 的“忽略查询字符串”设置，避免把带参数与不带参数的页面混成同一份缓存。
- 确认回源失败时节点的行为。部分 CDN 在源站异常时会继续返回过期缓存，排查问题时容易被误导。
更新后怎么验证蜘蛛看到的是哪一版
不要只看自己的浏览器。可以用命令行请求并带上明确的缓存绕过头，观察响应头里的 Age、X-Cache、CF-Cache-Status 等字段，判断这次返回是命中缓存还是回源。再与 CDN 控制台的刷新记录对照，确认刷新确实生效。修改重要页面后，间隔一段时间再抓一次，确认内容已经稳定为新版。
如果站点有日志，可以留意蜘蛛访问目标页面时的响应大小与状态码，并与源站日志比对，判断它命中的是节点缓存还是源站。这比单纯看“蜘蛛来过没有”更有参考价值。
两个常见误区
- 以为清空浏览器缓存就等于全网更新。浏览器只是最外层，节点缓存和服务端缓存还在。
- 把缓存 TTL 设得越长越好。对内容频繁更新的站点，长 TTL 省下的那点回源压力，远不如内容不一致带来的麻烦。
缓存策略的目标不是让内容永远缓存，而是让该缓存的缓存、该更新的更新。发布流程里最好把刷新与验证写成固定步骤，而不是靠临时想起。
落到流程上
把缓存刷新与内容发布绑定：发布后自动刷新相关 URL（含首页、栏目页、列表页），再抽检一两个页面确认生效。大改版或批量更新前，提前和负责 CDN 的同事确认刷新方式与生效时间。日常监控方面，可以定期抽查核心页面的响应头，确认缓存没有长期停留在旧版本上。