缓存是站点加速的常规手段，但它同时也是抓取环节里最容易出问题的部分。CDN、反向代理、页面缓存插件、对象存储，只要有一层配置不当，蜘蛛或访客就可能拿到几小时甚至几天前的页面、错误的状态码，或者一个本该登录后才可见的内容。这类问题往往不容易被察觉，因为你在浏览器里刷新一下看到的是新内容，而缓存节点上还留着旧版本。
缓存为什么会干扰抓取
搜索引擎蜘蛛请求页面时，看到的通常是缓存节点的响应，而不是源站。如果缓存层没有正确区分请求来源、没有透传源站返回的头部信息，就会出现几种典型情况：
- 页面已经更新，但缓存仍返回旧 HTML，蜘蛛判断内容未变化，减少后续访问；
- 源站返回 404 或 500，缓存层却用旧的 200 页面兜底，形成软 404；
- 带参数的地址被缓存成同一个键，不同内容互相覆盖；
- 登录态、地区、语言等差异化内容被统一缓存，用户看到错误版本。
自查要点
1. 缓存头是否合理
检查源站返回的 Cache-Control、Expires、ETag、Last-Modified。HTML 文档不建议设置过长的强缓存，通常用较短的 max-age 配合协商缓存更稳妥；图片、字体、JS/CSS 这类带指纹的静态资源可以设长一些。注意 CDN 自身的缓存规则可能覆盖源站头部，两边要对照着看。
2. 状态码是否被缓存
404、410、301、5xx 是否进入了缓存，是常见盲区。一次源站抖动产生的 5xx 如果被缓存几十分钟，蜘蛛和访客都会看到错误页面。建议在 CDN 侧明确哪些状态码不缓存，或只缓存极短时间。
3. 缓存键是否过粗或过细
键太粗，忽略 UA、语言、登录态，会把不同内容混在一起；键太细，把随机跟踪参数都算进去，命中率接近零，回源压力反而更大。可以先梳理站点实际需要的区分维度，再做取舍。
4. 刷新与预热流程
内容发布后是否自动刷新对应 URL，栏目页、列表页、首页是否在刷新范围内，这些都需要在流程里写清楚。只刷新详情页，列表页仍显示旧标题，蜘蛛顺着列表走就会拿到过期链接。
上线后的检查动作
- 用命令行请求目标 URL，观察响应头里的 Age、X-Cache、Cache-Control 等字段；
- 对比源站直连与经过 CDN 两条路径返回的 HTML 是否一致；
- 抽查已发布的新内容，确认列表页、详情页、站点地图里的链接都是新地址；
- 把缓存异常纳入日常监控，比如 5xx 比例、回源率、命中率的突变；
- 改版或批量更新时，提前确认缓存刷新方式，避免旧页面长期残留。
缓存的目标是减少重复回源，不是让内容“冻”在原处。凡是会影响抓取判断的头部和状态码，都值得单独确认一次。
缓存策略没有统一答案，页面类型、更新频率、服务器承载能力不同，取舍也不同。但只要把缓存头、状态码、缓存键和刷新流程这四项固定下来定期核对，就能减少“蜘蛛看到的是旧版本”这类问题带来的运营困扰。