缓存是站点运营里最不显眼、也最容易出岔子的一环。它能让页面变快，也能让蜘蛛在几天里反复拿到同一份旧内容：标题改了、价格换了、商品下架了，用户看到的是新版，搜索引擎拿到的却还是缓存层里的副本。这类问题不报错、不报警，只在抓取结果里慢慢显形。
为什么缓存问题容易被漏掉
因为从浏览器里看不出来。运营人员在自己电脑上刷新，看到的是本地缓存或者已经刷过的 CDN 节点，很容易得出“已经更新了”的结论。而蜘蛛从另一个地区、另一个节点回源，得到的可能是几小时前甚至几天前的页面。
更麻烦的是，缓存出问题时页面往往仍然正常返回 200。状态码没错，内容却对不上，这种安静的错误最难排查，也最容易被归因到别的地方去。
常见的几类缓存坑
- 发布新内容后缓存未刷新：正文已经更新，缓存里还是旧版，蜘蛛抓到的标题和页面实际内容不一致。
- 缓存键包含了动态参数：同一篇文章按不同参数被缓存成多份，命中率下降，回源压力反而更大。
- 把错误页也缓存了：短暂的 404 或 500 被缓存住，蜘蛛连续几天只能看到错误页。
- 缓存了重定向规则：A 页跳 B 页的配置改过了，缓存里还留着旧跳转，蜘蛛一直在绕路。
- 回源失败直接吐错误码：源站抖动时 CDN 未做兜底，蜘蛛会把这段异常记在抓取记录里。
可以按顺序做的自查
- 先理清缓存层级：本地浏览器缓存、CDN 节点缓存、源站或应用层缓存各自管什么，谁负责刷新，出问题时先看哪一层。
- 检查 HTML 的缓存头设置。max-age 是否给得过长，是否把 HTML 和图片、CSS、JS 这类静态资源用了同一套策略。
- 确认缓存键的组成。带查询参数的页面、带地区或设备区分的页面，是否会各自生成一份缓存副本。
- 检查错误页是否被缓存。建议 404、500 这类响应设置较短的缓存时间或不缓存，避免异常状态被固化。
- 用不同地区、不同 UA 的实际请求验证，而不是只看自己浏览器里的刷新结果。有条件时对比响应头里的缓存命中标识。
- 检查回源失败时的表现。源站短暂不可用时，返回的是缓存旧页还是 5xx，这决定了蜘蛛看到的是内容还是故障。
- 把刷新动作写进发布流程。内容更新、栏目调整、模板改版之后，明确由谁触发刷新、多久之内完成。
改版期间要格外留心
模板更换、URL 调整、站点迁移这些动作，常常同时改动缓存规则和跳转规则。两者叠加，最容易出现“用户看到新版、蜘蛛看到旧版加旧跳转”的情况。改版上线后，建议挑几个代表性页面，分别用浏览器和抓取工具实际请求一次，对比内容是否一致。
缓存不是设一次就完事的开关，而是需要跟着内容节奏一起维护的环节。发布越快、更新越频繁的站点，越需要把刷新当成流程的一部分。
小结
缓存本身没有对错，关键在是否与内容更新节奏对齐。把层级理清、把错误页排除在外、把刷新动作写进发布流程，就能减少大量“明明改了却抓不到”的困惑。这类自查不需要复杂工具，需要的是一次次实际的请求验证，以及不依赖本地浏览器刷新的习惯。