蜘蛛访问的是 CDN，而不是源站
蜘蛛发起抓取时，请求先经过域名解析，再落到 CDN 的某个节点。节点有缓存就直接返回，没有才回源站取。也就是说，蜘蛛看到的内容很多时候不是源站的最新版本，而是某个节点上的缓存副本。这个中间层处理得好，抓取会更稳定；处理得不好，蜘蛛可能拿到错误页、旧内容，甚至在同一时间收到两种答案。
缓存版本不一致带来的抓取问题
多节点 CDN 下，各节点缓存的过期时间并不完全同步。内容更新后，一部分节点已经回源拿到新版，另一部分还在返回旧版。如果蜘蛛在不同时间、不同节点抓取同一个 URL，就可能形成两种页面内容。搜索引擎通常按 URL 归一处理，但多次不一致会影响它对页面主题和更新时间的判断。
更麻烦的是缓存了不该缓存的东西：
- 301、302 被长时间缓存，之后修改跳转目标，蜘蛛仍按旧跳转走；
- 带参数的页面被忽略参数缓存，不同参数返回同一份内容；
- 404 或错误页被缓存，源站已经恢复，蜘蛛还在拿旧状态码。
回源失败与“看起来正常”的错误
节点到源站的回源过程中，超时、连接被拒、源站 5xx 都可能发生。有些配置会在回源失败时返回一个自定义错误页，状态码却是 200。蜘蛛拿到的是 200 和无意义内容，会把它当成正常页面收录，或者反复重抓。
反过来，回源失败时如实返回 5xx，蜘蛛会视为临时问题，稍后重试，不会把错误页当成内容留下。区别在于状态码有没有真实反映结果。
缓存层不应该替源站“美化”状态码。200 就意味着有内容，5xx 才代表失败，混在一起会让抓取判断失真。
节点差异怎么排查
不用等蜘蛛反馈，自己也能看到差异：
- 用 curl --resolve 把域名指向不同节点 IP，对比返回内容、Last-Modified 和 Age；
- 看响应头里的 X-Cache、Age、Via，判断这次是命中还是回源；
- 在服务器或 CDN 日志里统计回源比例、5xx 比例和缓存命中率；
- 对关键页面手动刷新缓存，观察蜘蛛后续抓取的变化。
配置上可以做的事
HTML 这类更新频繁的页面，缓存时间不宜过长，可以用较短的 TTL 或 s-maxage；静态资源可以长缓存，但要让文件名随内容变化。错误状态、跳转、带会话信息的响应，一般不要缓存。搜索引擎的抓取请求是否绕过缓存，要看源站能不能承受，完全绕过缓存会把压力直接压到源站，反而增加超时和 5xx 的概率。
另外要确认回源地址稳定，源站返回的状态码、内容长度、编码都正常。CDN 只是通道，抓取是否顺畅，最终还是取决于源站能不能及时给出正确响应。
小结
蜘蛛抓取经过 CDN 时，多了一层缓存判断。命中率高、回源正常、状态码如实，抓取路径就稳；缓存版本混乱、错误页被缓存、回源频繁失败，蜘蛛就会在同一个地址上遇到不同结果。把缓存规则和回源行为对齐，比单纯追求命中率更有意义。