很多站点更新内容后，自己在浏览器里刷新看到了新版本，就默认搜索引擎也会看到同一份。实际上，中间可能隔着 CDN、反向代理、对象缓存、页面缓存等多层缓存，蜘蛛拿到的可能是几小时甚至几天前的旧页面。缓存本身不是问题，问题在于“你看到的”和“蜘蛛看到的”不一致，而且没人定期核对。
先搞清楚缓存链路有哪几层
自查之前，先把页面从源站到访问者之间经过的缓存层列出来，常见的有：
- 浏览器缓存：由 Cache-Control、Expires 控制，对搜索引擎影响相对小。
- CDN 边缘节点缓存：按缓存键存放副本，TTL 到期才回源。
- 反向代理 / 网关缓存：Nginx、Varnish 一类，规则写错容易长期缓存 HTML。
- 应用层页面缓存：框架或插件生成的静态化文件、对象缓存。
- 数据库与查询缓存：一般不影响最终 HTML，但会拖慢回源速度。
任何一层把 HTML 缓存住，都可能造成蜘蛛与真实内容脱节。
三个最常见的坑
1. HTML 被当成静态资源长期缓存
把 .html 或动态路径设置成 TTL 7 天、30 天，上线初期看不出问题，内容一改就出问题。首页、栏目页、列表页这类更新频繁的页面，TTL 应该短一些，或者配合主动刷新机制。
2. 缓存键里带了不该带的维度
有些配置会把 User-Agent、Cookie、Referer 一起作为缓存键。结果就是同一个 URL 在不同 UA 下生成多份副本，蜘蛛拿到的那份可能恰好是旧版本，或者是一个被裁剪过的页面。要确认缓存键只包含必要维度，并检查 Vary 头有没有把爬虫引向错误的副本。
3. 回源失败后继续返回旧副本
源站短暂 5xx 时，CDN 若配置了“过期后继续提供旧内容”，访问者看不到报错，但蜘蛛可能长时间拿到过期页面。这类策略要写清开启条件和最长保留时间，别让它无声无息地拖上几周。
自查怎么做
- 选 5–10 个代表性 URL：首页、最新栏目页、刚更新的详情页、一个长期不变的页面。
- 用带蜘蛛 UA 的请求抓取响应头，记录 Age、X-Cache、Cache-Control、Last-Modified、ETag 等字段。
- 和源站直连的响应做对比，重点看内容长度、正文关键句、时间戳是否一致。
- 更新一篇内容，观察各层缓存多久后同步，记录实际延迟。
- 确认主动刷新通道可用：CDN 刷新入口、应用层缓存清理方式，是否有人会用、有没有权限。
判断标准很朴素：把蜘蛛拿到的 HTML 存下来，和你预期的最新版本逐段比一次。不一致，就是缓存没管好。
日常运营里的几条习惯
- 重要更新走“先刷新缓存、再观察”的流程，别发完就等自然过期。
- 给缓存 TTL 做一张表，按页面类型分层：首页和列表页短 TTL，详情页可稍长。
- 回源异常时的兜底策略写清楚，最长保留时间要有上限。
- 把缓存核对放进每周巡检，和日志抽样一起做。
- 改版或迁移前，先确认缓存清理顺序：应用缓存 → 源站 → CDN 边缘。
缓存优化的目标不是让命中率越高越好，而是让“命中”和“正确”同时成立。对站点运营来说，蜘蛛看到的版本是否等于你正在维护的版本，比省下多少回源流量更重要。