很多站长把服务器稳定性理解成“源站别挂”，但蜘蛛实际连上的往往不是源站，而是 CDN 的边缘节点。蜘蛛拿到的是一份缓存副本，副本新不新、对不对，直接决定它对站点的判断。抓取异常时，先确认蜘蛛站在哪一层，比急着改内链更有意义。
蜘蛛的请求落在哪一层
用户和蜘蛛访问同一个 URL，请求都会先到最近的 CDN 节点。命中缓存就直接返回，没命中才回源。对抓取来说，这条链路上有两个关键变量：拿到的是不是最新版本，以及返回的状态码是不是站点真正想表达的那个。两者只要有一个不对，后续关于 URL 发现、内链权重的分析都会建立在错误前提上。
缓存副本常见的两个坑
页面已经更新，蜘蛛仍读到旧内容
HTML 缓存时间设得太长，源站改版、改标题、改正文之后，边缘节点还在吐旧文件。蜘蛛按自己的节奏来访，看到的还是上一版；站长在浏览器里刷新（可能绕过缓存或已过期）觉得一切正常，两边看到的东西并不一致，排查时很容易互相“扯皮”。
错误页被缓存下来
更麻烦的是 404、5xx 或维护页被当成正常响应缓存。源站短暂抖动一次，CDN 把错误页存了几个小时，这期间所有来访者（包括蜘蛛）拿到的都是错误内容。抓取日志里会出现一批莫名其妙的失败，而源站监控却是绿的。
缓存头里需要关注的字段
- Cache-Control 与 s-maxage：决定边缘节点存多久。HTML 建议短一些，给内容更新留出余地；带指纹的图片、CSS、JS 可以放长。
- stale-while-revalidate：允许先返回旧副本再后台更新，能降低回源压力，但旧副本仍然会被蜘蛛读到。
- Vary：如果按 User-Agent 或 Cookie 分版本，缓存会被切成多份，蜘蛛可能拿到与你预期不同的那一份。
- Set-Cookie：每次请求都下发 Cookie，容易拉低缓存命中率，回源次数随之上升。
给蜘蛛单独放行要谨慎
有些站点会在 CDN 上按 User-Agent 判断，让蜘蛛绕过缓存直接回源。这样能保证看到最新内容，但有两个风险：一是回源压力集中在蜘蛛身上，源站不稳时它更容易拿到 5xx；二是 UA 规则写错，把正常流量或蜘蛛本身误拦成 403，抓取会直接断掉。真要做，先确认判断规则和回源容量，再小范围验证。
命中率也影响等待时间
缓存命中高，TTFB 低，蜘蛛等待时间短，同样的抓取额度能覆盖更多 URL；反过来，每次都回源且源站响应慢，超时和重试的比例就会上升，抓取队列被无效请求占满。缓存配置不只影响用户体验，也影响抓取效率。
一份自查清单
- 用服务器日志和 CDN 日志对照，看蜘蛛请求的命中状态、返回码和缓存年龄。
- 在 CDN 控制台确认错误状态码不被缓存，或设置很短的 TTL。
- 改版后主动刷新相关 URL 的缓存，再观察蜘蛛下一次抓取拿到什么。
- 确认没有对蜘蛛 UA 返回验证页、JS 挑战页或空白页。
抓取问题不总是出在 HTML 里。先确认蜘蛛站在哪一层、拿到了哪一份文件，再谈内链和 Sitemap 才有效。
把缓存策略和抓取节奏对齐，让蜘蛛看到的版本与用户看到的一致，后续 URL 发现、抓取路径和 Sitemap 的判断才不会跑偏。