很多站点把蜘蛛抓取理解为蜘蛛直接访问源站，但真实链路里往往还有 CDN、反向代理、页面缓存插件和对象存储。蜘蛛拿到的是缓存层返回的那份响应，而不是你刚改完的源站内容。当抓取表现和后台修改对不上时，先别急着怀疑蜘蛛，先核对缓存层。
为什么缓存层要纳入抓取核对
抓取一致性指的是不同时间、不同节点、不同 UA 拿到同一 URL 时，响应主体与状态码基本一致。缓存层一旦让响应出现分叉，就会出现几种典型现象：蜘蛛抓到旧版页面、抓到的页面缺少内链、同一 URL 在不同边缘节点返回不同状态码。这些都会影响 URL 发现和后续的抓取判断。
常见的缓存分叉场景
1. 缓存过期时间过长，抓取到旧版
发布新内容后源站已经更新，但边缘节点还在返回几小时前的 HTML。蜘蛛这次抓取拿到的仍是旧内容，内链里没有新 URL，新页面就少了一条发现入口。
2. 按 UA 或 Cookie 分流
有些配置对搜索引擎 UA 走不同缓存规则或不同回源路径。核对时要注意：同一 URL 用普通 UA 与蜘蛛 UA 请求，返回的状态码、正文长度、是否含脚本注入内容是否一致。分叉本身不一定是错，但需要确认它没有屏蔽关键链接。
3. 缓存把错误响应也缓存下来
源站短暂 5xx 或超时被缓存后，蜘蛛可能在缓存有效期内反复拿到 5xx，看起来像服务器持续不稳定，实际是缓存放大了单次故障。
4. robots.txt 与 Sitemap 的缓存
这两类文件也常被缓存。规则更新或 Sitemap 分片调整后，如果缓存未刷新，蜘蛛读到的仍是旧版本，URL 发现范围会与预期不符。
核对顺序建议
- 确认目标 URL，分别记录源站直连与经过 CDN 的响应状态码、Content-Length 和响应头。
- 对比两者的正文关键片段，例如标题、正文首段、导航里的链接集合。
- 查看响应头中的缓存命中标记与 Age，判断是命中缓存还是回源。
- 抽查多个边缘节点或多次请求，确认是否只有部分节点内容滞后。
- 对 robots.txt、Sitemap、关键入口页单独做一次刷新与复核。
- 核对完成后再看日志中的抓取记录，避免把缓存问题误判为抓取异常。
日志与响应头的观察点
- 状态码分布：缓存层返回的 200 与源站日志里的 200 数量是否对得上。
- 回源比例：如果回源次数远低于抓取次数，说明大量请求被缓存拦截。
- UA 与路径组合：同一路径下不同 UA 的响应差异。
- 时间戳：缓存刷新时间与内容发布时间是否接近。
抓取问题里，缓存层造成的假象很常见。先分清蜘蛛没来和蜘蛛来了但看到的是旧的，再决定要不要动站点结构。
稳定性与刷新节奏
缓存刷新策略不必追求最短，但要与内容更新节奏匹配。入口页、栏目页、Sitemap 这类承担 URL 发现职责的页面，可以设置得更及时；内容页则按实际更新频率设置。核对的目标是让蜘蛛在不同时间点看到的链接集合与状态码保持稳定，而不是把缓存整体关掉。
如果缓存层配置合理，服务器压力会下降，蜘蛛抓取时的响应也更稳定。把缓存层加入抓取核对清单，能减少很多改了但没生效的排查时间。