页面明明已经更新，蜘蛛抓到的却还是三周前的版本；后台换了标题，结果里还是老标题；栏目停更了，CDN 还在按老规则一直返回缓存内容。这类问题多数不是蜘蛛的问题，而是缓存层级没理清。
先分清缓存发生在哪一层
同一个 URL 的响应，可能经过好几层缓存。排查时不要一上来就清 CDN，先定位是哪一层在“扣留”旧内容。
- 浏览器缓存：由 Cache-Control、Expires、ETag 等响应头控制，主要影响真实用户。它对蜘蛛的影响有限，但会干扰你自己的测试判断。
- CDN 边缘缓存：缓存节点按缓存键存副本，命中后不回源。这是很多“蜘蛛看到旧页面”的真正原因。
- 源站页面缓存与对象缓存：插件、框架、反向代理生成的静态副本。后台更新了数据，缓存层没被清掉，对外就还是旧的。
自查时重点看这几项
- 抓一次文章页，用命令行看响应头里的 Age、X-Cache、CF-Cache-Status 之类字段，判断这次是命中还是回源。
- 对比源站直连的结果和走 CDN 的结果。两边不一致，说明缓存层没同步。
- 检查 HTML 文档的缓存时间。内容型页面通常适合几分钟到几小时的短缓存，可以配上允许使用陈旧副本的策略；图片、样式这类静态资源才适合长缓存加文件指纹。
- 确认发布流程里有没有“主动刷新受影响地址”这一步，而不是干等过期。
- 核对缓存键。带参数、带地区、带设备区分的规则，容易让同一个页面产生多份副本，也可能让更新只覆盖了其中一份。
容易被忽略的两个细节
缓存键里带了不该带的参数
如果缓存键包含所有查询参数，一个页面能裂成几十份副本，刷新时很难全部覆盖；如果缓存键忽略了本该区分的参数，不同内容又会互相串页。规则要写清楚：哪些参数参与区分，哪些直接忽略。
更新后的验证方式
发布完不要只看自己那个浏览器。先用无痕窗口或直接请求一次，再观察蜘蛛下一次抓取时拿到的是哪个版本。也可以在访问日志里留意同一个 URL 连续抓取返回的字节数是否发生变化。
缓存不是越短越好。缓存时间压得太短，源站压力上来了，抓取速度反而可能变慢。关键是把“更新后能及时失效”做成流程，而不是靠碰运气。
把缓存纳入日常运维
建议在发布清单里固定三步：发布后主动刷新受影响的地址、抽查两到三个页面的响应头、观察一两天日志里的抓取版本。遇到改版或批量更新，先小范围验证再全量推。缓存本身是好事，它让蜘蛛抓得更快、源站更稳，出问题的只是失效机制没跟上内容变化。