很多站点上线后会把流量交给 CDN 处理，缓存配置通常是照着默认模板点几下就完事。日常访问看不出问题，但搜索引擎蜘蛛抓到的可能是几个小时前的页面，甚至是一张被缓存下来的错误页。这类情况不会在后台报警，只能靠定期自查发现。
先确认蜘蛛看到的是哪一份内容
自查的第一步不是改配置，而是先取一份样本。可以用 curl -I 带上常见的蜘蛛 UA 请求几个 URL，观察返回头里的 Age、X-Cache、Cache-Control 等字段，再和浏览器直接访问的结果对比。如果带蜘蛛 UA 时命中了缓存，返回的时间和正文却和源站对不上，说明缓存规则对爬虫同样生效，需要留意。
缓存时长与内容更新频率是否匹配
- 首页、栏目页这类变化频繁的位置，缓存时间不宜过长，否则新发布的文章会延迟出现在列表里。
- 文章详情页更新较少，可以设置较长的缓存时间，但编辑修改后要有主动刷新机制。
- CSS、JS、图片等静态资源可以设置长缓存，但要配合文件名版本号，避免改完之后用户和蜘蛛还拿到旧文件。
需要注意的是，缓存时间不是越长越省事。内容更新和缓存刷新之间的时间差，就是蜘蛛可能抓到旧内容的窗口。
回源失败时返回了什么
源站短时间不可用时，如果 CDN 返回的是 200 状态码加一个「服务繁忙」页面，蜘蛛会把这张页面当成正常内容处理，反复几次之后可能影响对该地址的判断。更稳妥的做法是让源站故障以 5xx 状态返回，或者在配置允许时透传状态码。这一点可以在抓取日志里核对：如果某个地址长期返回 200，但正文内容和平时明显不同，往往就是缓存兜底页。
更新内容后的刷新动作
- 文章发布或修改后，对对应 URL 触发一次缓存刷新，不要只刷首页。
- 栏目页、标签页如果依赖列表缓存，同样需要刷新，否则新文章的内链迟迟拿不到。
- 批量更新（比如改模板、改导航）后，按目录或按文件类型批量刷新，并记录刷新时间，方便和日志对照。
抓取与缓存的几处常见冲突
- CDN 对未知 UA 做了拦截或验证码，蜘蛛请求被挡在门外，日志里只剩 403。
- 缓存规则按目录匹配，把 sitemap、robots.txt 也缓存了，修改后长时间不生效。
- 移动端和桌面端走不同缓存，两边内容不一致，容易造成判断混乱。
- 多地节点回源策略不同，同一地址在不同地区返回的正文存在细微差异。
自查的目的不是追求配置完美，而是让「源站内容」和「蜘蛛拿到的内容」尽量一致，出现差异时能快速定位在哪一层。
一份可执行的自查清单
- 用蜘蛛 UA 抽样请求首页、栏目页、详情页各若干条，记录状态码与 Age 值。
- 核对 robots.txt 与 sitemap 是否被缓存，修改后能否即时生效。
- 确认源站故障时返回的状态码，避免把兜底页当成正常内容。
- 检查内容更新后是否有刷新流程，刷新记录能否和爬虫日志对上时间。
- 确认缓存规则没有误伤静态资源的版本更新。
把这些检查放进固定的运维节奏，比如每次改版或调整缓存策略后跑一遍，比等到流量波动再回头排查要省事得多。