CDN 的作用是把内容放到离用户更近的节点上，减少回源压力。但缓存一旦配置不当，蜘蛛和用户拿到的可能是几个小时甚至几天前的旧页面。新内容已经发布，抓取结果里却还是旧标题、旧价格、旧库存，这类问题在运营中并不少见。
先确认蜘蛛看到的是不是缓存版本
最直接的办法是用不同的 User-Agent 请求同一个 URL，比较响应头和正文。如果返回头里带有 Age、X-Cache: HIT 之类的字段，说明命中了缓存。再对比源站直接访问的结果，就能判断缓存是否把旧内容暴露出去。
也可以借助日志：如果某个 URL 在源站日志里长时间没有记录，但页面明明有更新，可能是 CDN 一直在用缓存响应蜘蛛，源站根本没收到请求。
缓存键和缓存时长要分清
- 缓存键：有些 CDN 默认把查询参数、Cookie、User-Agent 都算进缓存键，导致同一篇内容被缓存很多份；也有些配置忽略查询参数，把不同参数页面混成同一个缓存。需要结合站点实际情况确认。
- TTL：静态资源可以设长一些，HTML 页面通常不宜太长。新闻、商品、活动页这类更新频繁的内容，TTL 需要更短。
- 回源规则：哪些请求必须回源、哪些可以命中缓存，最好按目录或内容类型区分，而不是全站一个策略。
更新之后要主动刷新
发布新内容、修改标题或价格后，如果只等 TTL 自然过期，蜘蛛可能在缓存过期前反复抓到旧版本。常见的做法是通过 CDN 提供的刷新接口提交 URL，或者把内容管理系统和刷新动作绑定在一起。
刷新时注意范围
刷新单个 URL 比整站刷新更可控，整站刷新容易在短时间内造成回源压力。列表页、首页、栏目页和详情页的刷新优先级也不一样，详情页通常最需要及时更新。
别忽略缓存分层
有些 CDN 有多层缓存，边缘节点刷新了，中间层可能还有旧副本。刷新后最好再验证一次实际响应，而不是提交完就认为已经生效。
几个容易踩的坑
- 把带 Set-Cookie 的响应缓存下来，导致不同用户看到同一份登录态页面。
- 忽略 Vary 头，把移动端和桌面端页面混用同一份缓存。
- 源站更新后没有通知 CDN，缓存一直保留旧版本。
- 把 404 或 500 错误页也缓存住，错误状态被持续返回。
缓存的目标是让重复请求更快，不是让所有请求都变成缓存。该回源的时候要回源，该刷新的时候要刷新。
自查之后做什么
建议定期抽查重点页面的响应头，记录缓存命中情况和 TTL 设置。把更新频繁的栏目单独列出来，配置更短的缓存时间或自动刷新。对蜘蛛和用户都重要的页面，尽量保证源站内容、CDN 缓存和页面展示三者一致。
如果站点同时使用蜘蛛池或主动推送来辅助 URL 发现，也要注意推送的 URL 是否会被 CDN 缓存返回旧内容。发现和抓取只是第一步，抓到的内容是否新鲜，同样影响后续判断。