蜘蛛抓取页面时，拿到的往往不是源站直接吐出的内容，而是 CDN 或反向代理缓存下来的副本。这对站点本来是好事：响应更快、源站压力更小。但如果缓存策略没配好，蜘蛛看到的可能是过期页、错误页，甚至把同一个 URL 的内容分裂成好几份，抓取效率反而下降。
一、命中与回源：蜘蛛拿到的到底是谁的内容
缓存命中时，蜘蛛几毫秒就拿到了完整 HTML，抓取自然顺畅；一旦未命中或者缓存被绕过，请求就会回源，源站要重新渲染、查库、拼装页面，响应时间可能从几十毫秒涨到几百毫秒甚至更久。
这里常见的隐患是：缓存只对普通访客生效，对蜘蛛的 UA 走了绕过缓存的规则。有些站点为了让蜘蛛看到最新内容，专门给搜索蜘蛛配置了不缓存或强制回源，结果是抓取请求全部砸在源站上，响应变慢、超时增多，抓取节奏也跟着收缩。除非页面必须实时，否则没必要做这种区分。
二、缓存键：参数一多，同一个页面会被缓存很多次
缓存键决定了“什么算同一个页面”。默认情况下，完整 URL 会被当作缓存键的一部分，于是带追踪参数、排序参数、会话参数的链接，会在缓存里各存一份。对蜘蛛来说，这些 URL 可能被当成不同页面分别抓取，内容却几乎一样。
- 把无关请求参数从缓存键中剔除，统一按路径缓存；
- 确认剔除参数后不会串内容，例如分页、筛选这类会改变正文的参数必须保留；
- 对确实需要区分的参数，考虑用规范化后的 URL 对外暴露，而不是让多种写法同时存在。
缓存键收敛之后，同一份内容只需要缓存一次，回源次数减少，蜘蛛拿到的响应也更快。
三、TTL 与内容更新：新内容多快能被看到
页面更新后，如果缓存 TTL 设置得很长，访客和蜘蛛在 TTL 到期前拿到的还是旧版本。这本身不算错误，但会带来一个判断偏差：你以为新内容已经上线，蜘蛛看到的却是旧页面。如果正文变化较大，可以对新发布或修改过的 URL 主动刷新缓存，让后续抓取拿到新版。
需要注意的是频率控制。每次改动都全站刷新，等于把回源压力集中释放，反而让响应变慢。按栏目、按更新频率分层次设置 TTL 更稳妥。
四、被缓存下来的状态码：404、301、5xx 最难处理
比内容过期更麻烦的是状态码被缓存：
- 临时故障返回的 5xx 被缓存，蜘蛛之后再来还是同一个错误；
- 临时跳转的 301、302 被长期缓存，后续抓取一直沿着旧路径走；
- 迁移期间误返回的 404 被缓存，本来有效的 URL 被判定为无效。
处理思路是：错误状态尽量短缓存或不缓存，正常内容可以长缓存。同时确认迁移、改版期间缓存被正确清理，避免旧状态继续影响抓取判断。
五、一份可落地的检查清单
- 比较“缓存命中”和“回源”两种情况下页面的响应时间，差距是否过大；
- 确认搜索蜘蛛的请求同样走缓存，而不是被特殊规则强制回源；
- 检查缓存键是否包含无效参数，能否按路径统一；
- 确认 5xx、404、301 的状态码不会被长时间缓存；
- 梳理新内容的缓存刷新方式，别让更新停留在旧副本上；
- 从服务器日志里筛出回源请求，看是否集中在少数 URL 上。
缓存和抓取的关系很直接：蜘蛛拿到的响应越快越稳定，能走到的 URL 就越多。把缓存键、TTL 和状态码这三件事理顺，往往比反复提交 URL 更有用。