做站点运营时，常见的困惑是：页面明明已经更新，蜘蛛再来抓的时候拿到的却还是旧内容。这种情况往往不是蜘蛛没来，而是它来了，却从缓存里拿到了一份过期版本。理解缓存这一层，能让 URL 发现和后续抓取少走很多弯路。
蜘蛛请求的那个页面，是谁返回的
当蜘蛛请求一个 URL，响应可能来自三处：源站服务器、CDN 边缘节点，以及中间的缓存层。蜘蛛最终拿到的 HTML，取决于这次请求命中了哪一层。对蜘蛛来说，这几层的差别它并不关心，它只看最终返回的状态码和正文。日志里显示抓取成功，并不代表抓到的就是最新版本。
缓存命中对抓取的两面影响
- 正面：缓存命中时响应更快，蜘蛛在同样的时间窗口里能处理更多 URL，抓取过程也更稳定，源站不容易因为压力出现 5xx。
- 负面：如果缓存时间设置过长，或者更新后没有主动刷新，蜘蛛会反复拿到旧页面，新链接、新内容迟迟进不了下一轮抓取。
换句话说，缓存既影响抓取速度，也影响内容的新鲜度，这两件事需要分开来看。
几处容易被忽略的缓存细节
Vary 与 User-Agent
有些站点会按 User-Agent 返回不同内容，并在响应头里声明 Vary。一旦缓存层按这个规则拆分副本，蜘蛛拿到的版本可能和普通访客不同。更麻烦的是，同一台边缘节点上可能混存了多个版本，蜘蛛几次抓取拿到的正文不一致，页面内容的判断就变得不稳定。
缓存过期时间与更新节奏
缓存时间设得越长，源站压力越小，但内容变更被蜘蛛发现的延迟也越长。首页、列表页这类更新频繁的页面，通常不适合和详情页用同一套缓存策略。详情页可以放长一些，聚合页和入口页则应该更短。
多级缓存下的刷新
更新内容后，只刷新了 CDN 而没有处理源站缓存，或者只刷新首页而漏掉了列表页，都会让蜘蛛在新的抓取轮次里仍然读到旧链接。刷新动作最好和发布流程绑定，而不是靠人工想起来再操作。
更新后，让蜘蛛更快读到新版
- 发布完成后按页面类型逐层刷新：详情页、列表页、首页依次处理。
- 先确认源站返回的是新内容，再检查边缘节点返回的版本，避免只刷新了一层。
- 核对缓存时间配置，对更新频繁的 URL 单独设置较短的过期时间。
- 对照服务器日志与回源日志，确认蜘蛛的请求到达了哪一层。
- 如果内容确实变了，不要长期依赖缓存自动过期来推动更新。
缓存问题的一个典型表现是：站内检查看起来一切正常，但从抓取日志看，某些 URL 返回的正文始终是同一段旧文本。这时先查缓存，往往比反复改内容更有效。
日常自查的几件小事
- 上线新页面后，用不同来源分别请求一次，对比正文是否一致。
- 确认重要页面的缓存时间，和它们的更新频率是否匹配。
- 记录每次刷新缓存的时间点，与抓取日志对照，看新版内容多久被读到。
- 如果站点用了多级缓存，注意是否存在只在某一层刷新的情况。
缓存并不是抓取之外的话题，它决定了蜘蛛每一次请求究竟读到了什么。把这一层理顺，URL 发现和内容更新才会按预期推进。