做抓取分析时，一个常见的误区是把源站日志当成蜘蛛来过与否的唯一证据。实际上，只要站点前面挂了 CDN 或反向代理，蜘蛛的大部分请求可能根本没有落到源站，而是被边缘节点用缓存副本直接返回了。理解这一层，对判断抓取情况很关键。
蜘蛛的请求先落到哪一层
一次普通的 HTML 抓取，路径大致是：DNS 解析 → 边缘节点 → 命中则直接返回、未命中则回源 → 源站生成响应 → 边缘缓存并返回给蜘蛛。也就是说，源站日志里缺失的那部分抓取，未必是蜘蛛没来，可能只是被缓存接住了。
这带来两个直接影响：一是你看到的抓取量会被低估，二是源站统计的响应时间并不等于蜘蛛实际等待的时间。分析抓取节奏时，最好把边缘日志和源站日志放在一起看。
缓存命中率如何影响抓取节奏
边缘命中的响应通常在几十毫秒内完成，蜘蛛拿到页面后可以很快发起下一个请求。命中率低时，每个请求都要回源，源站要重新渲染、查询、拼装，单次抓取占用的连接时间被拉长，蜘蛛在同一时间窗口里能走完的 URL 自然减少。
- 命中率高：抓取更顺畅，单页耗时短，蜘蛛更愿意往目录深处走。
- 命中率低：回源压力集中，容易出现排队和超时，抓取速度被压下来。
- 缓存频繁失效（短 TTL 叠加大量不同参数）：效果接近没有缓存。
需要提醒的是，抓取量上升并不等于缓存配置就变好了，也可能只是内容更新的正常波动。做前后对比时尽量控制变量。
几种常见的“缓存挡路”情况
对搜索引擎 UA 做了验证挑战
部分 CDN 或安全产品的默认策略，会对疑似自动化的请求弹出 JS 挑战或验证页。如果搜索引擎的 UA 没有进入白名单，蜘蛛拿到的就是一段挑战脚本，而不是页面内容。
错误页被缓存
源站短暂故障返回 5xx，如果边缘把 5xx 也缓存下来，蜘蛛和用户都会在故障恢复后继续拿到错误页。建议明确配置：5xx 不缓存，或只缓存极短时间。
Vary 头写得过宽
Vary: Cookie、Vary: User-Agent 这类设置会让缓存按维度拆分成大量副本，命中率骤降。面向公开页面的缓存，通常不需要按 Cookie 区分。
不同节点拿到不同版本
多节点、多线路回源时，可能出现 A 节点是旧版、B 节点是新版的情况。蜘蛛从不同 IP 抓取，看到的版本可能不一致，进而影响它对内容更新时间的判断。
内容更新与缓存 TTL 的错位
页面更新后如果没有及时刷新缓存，蜘蛛抓到的仍是旧版本，它可能据此认为页面没有变化，降低后续的回访频率。更麻烦的是，如果这时 Last-Modified 或 ETag 与缓存副本对不上，304 的判断也会变得混乱。
发布关键页面时顺手做一次主动刷新，比事后排查“为什么蜘蛛没看到新内容”要省事得多。
几条可以落地的检查动作
- 用同一台机器，分别带搜索引擎 UA 与普通浏览器 UA 请求同一 URL，对比返回内容是否一致。
- 确认 CDN 的爬虫策略中，已知搜索引擎 UA 处于放行状态，没有被挑战或限速。
- 检查缓存规则，确保 5xx 与错误页不会长期驻留。
- 对比边缘日志与源站日志中的抓取记录，估算实际被缓存接住的抓取占比。
- 对更新频繁的栏目页设置较短 TTL，或纳入主动刷新清单。
把缓存层纳入抓取分析的视野，很多“蜘蛛没来”“内容不更新”的疑问会更容易解释。它不改变蜘蛛的行为规则，但会改变你能看到什么。