给站点接上 CDN 或反向代理缓存之后，访问速度通常会有明显改善，但随之而来的是一类不太显眼的问题：源站内容已经更新，访客和搜索蜘蛛看到的却还是旧版本。它不像宕机那样立刻暴露，却会让内容一致性和抓取判断慢慢出现偏差。
缓存层为什么会影响抓取
缓存的作用是减少回源、加快响应。当蜘蛛请求一个页面时，中间缓存直接返回副本，请求根本没有到达源站。如果这份副本是几天前的，蜘蛛拿到的就是过期内容。访客同样如此，改过的标题、价格、公告都要等缓存过期才能看到。
更麻烦的是，多次抓取都命中同一份旧副本时，容易让人产生误判：明明已经处理过的内容，为什么蜘蛛那边还是老样子。
几类常见的配置疏漏
HTML 页面缓存时间设得过长
把 HTML 的缓存时间设置成一天甚至一周，对更新频繁的栏目页、列表页并不合适。这类页面每天都有新内容，缓存时间应该短一些，或者改用主动刷新。
缓存键忽略 URL 参数
有些缓存配置只按路径做键，忽略查询参数。这样一来，?page=2 和 ?page=3 可能命中同一份缓存，分页内容就会串位，蜘蛛抓到的列表和实际不符。
动态接口被当作静态资源缓存
接口返回的 JSON、带登录态的页面、购物车页面如果被公共缓存，不仅会串用户数据，也会让蜘蛛抓到并不属于公开范围的内容。
CDN 与源站内容不一致
源站改了内容，CDN 未刷新；或者多台缓存节点之间刷新时间不同步，同一个 URL 在不同节点返回不同版本。蜘蛛分布在不同地区时，看到的页面可能并不一致。
一份可执行的自查清单
- 列出需要缓存的资源类型，区分静态资源、HTML 页面、动态接口，分别设定策略。
- 检查 HTML 缓存时间，确认更新频繁的栏目页没有被设成过长的 TTL。
- 确认分页、筛选、排序参数是否进入了缓存键，避免不同参数共用同一份缓存。
- 核对带登录态的接口是否被公共缓存，必要时补上不缓存的响应头。
- 抽查几个刚更新过的地址，对比源站与 CDN 返回的内容是否一致。
- 确认刷新机制：改完内容后是能主动刷新，还是只能等过期。
- 在不同地区、不同节点各抽查一次，确认返回版本统一。
- 把缓存命中率和回源情况纳入日常监控，出现异常能及时看到。
缓存更新和蜘蛛访问怎么配合
内容更新后，比较稳妥的做法是先刷新缓存，再让页面进入正常的抓取流程。如果站点有自己的推送或提交机制，可以按先刷新、再通知的顺序操作，避免蜘蛛先抓到旧副本。
对于更新频繁的列表页，可以把缓存时间设短一些；图片、字体、样式表等静态资源则可以设长一些，靠文件名带版本号来控制更新。这样既保住了速度，又不会让正文长期滞后。
缓存不是设一次就一劳永逸的配置，它更像一个需要跟着内容节奏调整的开关。
把缓存纳入日常巡检
可以固定每周抽几个更新过的页面，比对源站与缓存返回的内容，顺便看看日志里是否出现同一地址反复回源或长期不回源的情况。发现不一致就及时刷新，并回头检查规则本身。
缓存问题的特点是安静：站点不报错，页面也能打开，只是内容慢了一拍。定期自查，比等到访客反馈再处理要省事得多。