缓存问题往往先在抓取上暴露
CDN 和反向代理缓存的初衷是减少回源、加快访问。但对搜索引擎蜘蛛来说，它拿到的响应并不一定来自你的源站。如果缓存键设计得过于宽松、过期时间设置得过长，或者发布新内容后没有及时刷新，蜘蛛就可能反复拿到同一份旧副本，误以为页面一直没有变化。这类问题在日常访问中很难被察觉，因为普通用户看到的也是缓存副本，打开速度还很快，没有人会去追问内容是不是最新的。
自查可以从这几个方向入手
1. 缓存键是否把不该合并的请求合并了
缓存键决定了哪些请求共享同一份缓存。合并得太多，就会把本该区分的页面混在一起：
- 是否忽略了移动端与桌面端的区分，把两套模板缓存成一份；
- 是否忽略 Cookie 或登录态，把个性化页面缓存成公共副本；
- 是否把查询参数一律忽略，导致分页、筛选页共用同一份缓存；
- 是否把不同语言、不同地区的版本合并到同一个键上。
2. 缓存时长与刷新机制
HTML 通常适合较短的缓存时间，带指纹的静态资源可以长缓存。重点检查：
- 首页、列表页等更新频繁的页面，缓存时间是否偏长；
- 发布、更新、删除内容后，是否有主动刷新或按目录批量刷新的流程；
- 刷新只覆盖 CDN 边缘，还是同时覆盖源站前面的代理缓存；
- 有没有可自助操作的刷新入口，还是只能等技术手动处理。
3. 回源请求与状态码
缓存节点回源时的行为，会直接影响蜘蛛对站点的判断。留意回源是否带上了正确的 Host、协议与路径；更要注意回源返回的 5xx、404 是否被缓存下来。被缓存的错误响应会在一段时间内持续返回给蜘蛛，影响比源站短暂故障更大。
4. 多节点生效不一致
多节点、多机房的环境下，同一时间不同节点可能返回不同版本。如果规范化标签、canonical、hreflang 恰好落在版本不一致的页面上，蜘蛛拿到的信号就会互相矛盾，难以判断哪个才是主版本。
一个简单的检查方法
用命令行工具直接看响应头最省事：观察 Age、X-Cache、Cache-Control、Via 等字段，多次请求同一个 URL，确认命中情况与过期时间是否符合预期。发布新内容后隔几分钟再请求一次，看看返回的是不是新版。带查询参数、带移动端 UA、带不同语言头的请求各测一次，能较快发现缓存键的问题。
缓存不是一次性配置，而是一条需要跟着内容节奏持续维护的链路。
日常维护的几条建议
- 把刷新动作写进发布流程，而不是等出现问题再补救；
- 不同类型的页面使用不同缓存策略，不要全站一套参数；
- 错误响应设置较短缓存或不缓存，避免错误状态被放大；
- 记录每次策略调整的时间与原因，方便后续回溯；
- 改动后观察日志中的状态码分布与来源 IP，确认回源比例回到合理区间。
缓存的收益很明确，代价是链路变长、变量变多。定期做一遍这类自查，能减少用户看到新版、蜘蛛看到旧版这种不对称情况，出问题时也少走一些弯路。