站点接入 CDN 或反向代理之后，蜘蛛的请求链路就多了一层。它拿到的可能是一份缓存的 HTML，也可能是回源后实时生成的页面，两者在首字节时间、状态码和内容新鲜度上都可能不同。抓取量下滑或页面迟迟不被更新时，先分清页面是哪一层给出的，通常比反复调整内链更快找到原因。
缓存命中与未命中，蜘蛛看到的是两种响应
同一个 URL，缓存命中时可能几十毫秒返回；未命中时要等源站生成、查询数据库、拼接模板，几百毫秒甚至几秒。对蜘蛛来说，这两种响应的意义完全不同：前者能被快速消费，后者会占用抓取队列里的等待时间。抓取调度会参考历史响应速度，长期偏慢的路径，回访频率容易往下走。
所以缓存命中率低的页面，即使内容质量不错，也可能在抓取节奏上吃亏。文章详情页、栏目列表页是重点；带登录态、带随机参数的 URL 不适合缓存，也没必要强求。
回源压力决定了蜘蛛能走多快
缓存失效的瞬间，多个请求可能同时回源。如果源站没有做并发限制或请求合并，就会出现数据库连接被占满、响应时间拉长，甚至 5xx。这时候蜘蛛看到的是服务器不稳，通常会降低抓取速率，把队列往后排。
- 给回源设置合理的并发上限，避免缓存同时失效造成尖峰；
- 对同一 URL 的并发回源做合并，减少重复生成；
- 错开缓存过期时间，避免整站同一时刻回源。
别在 CDN 或 WAF 层把蜘蛛挡掉
有些站点为了防爬，在边缘节点配置了 UA 规则、频率限制或人机验证。这些规则如果写得粗糙，正常的搜索引擎蜘蛛可能拿到 403、429，或者被跳转到验证码页面。日志里看到大量非 200 的状态码，又找不到源站异常，就要往这一层查。
核对方式比较直接：用官方给出的验证方法确认来访者身份，再检查边缘规则里是否有针对该 UA 的拦截或限速；同时确认返回的是真实内容，而不是一段包装过的挑战页面。
缓存副本过期，蜘蛛可能长期抓到旧版本
页面更新后，如果边缘节点仍按旧 TTL 返回缓存内容，蜘蛛多次来访看到的都是同一份 HTML，自然不会认为有更新。更麻烦的是 Sitemap 里的 lastmod 写着新时间，实际返回的却是旧内容，两边对不上。
常见做法是内容更新后主动刷新对应 URL 的缓存，或者对更新频繁的栏目使用较短的 TTL，同时保证 Sitemap 的 lastmod 与实际内容变更一致。
预渲染与动态渲染缓存的边界
部分站点用预渲染或动态渲染服务，给蜘蛛返回一份渲染好的 HTML。这类缓存如果更新不及时，蜘蛛拿到的同样是旧版本；如果只对特定 UA 返回渲染结果，还要确认普通用户看到的内容与蜘蛛版本没有实质差异，避免同一 URL 出现两套内容。
一条自查路径
- 在日志里按响应码和缓存状态分组，看蜘蛛请求中命中与回源的比例；
- 用相同 UA 请求几个关键 URL，观察首字节时间和响应头里的缓存信息；
- 检查边缘规则、限速策略里是否有针对蜘蛛的拦截；
- 确认更新后的页面是否立刻返回新内容，lastmod 是否同步；
- 回源出现 5xx 时，先看源站并发和数据库，再看网络层。
蜘蛛没有绕过缓存层的能力，它看到的就是边缘节点返回的那一份响应。把这一层的响应时间、状态码和内容新鲜度理顺，抓取路径上的很多问题会自己变得清楚。