站点接入 CDN 或反向代理之后，源站日志里的抓取记录往往会明显变少。这不一定意味着搜索蜘蛛来得少了，更常见的情况是：请求停在了缓存层，没有回源。随之而来的问题是，缓存里保存的是某个时间点的 HTML 副本，里面的链接、状态码、更新时间都可能与源站当前版本不一致。搜索蜘蛛沿着这份副本走，就可能继续发现已经下线的 URL，或者迟迟看不到新上线的入口。
缓存副本与源站版本常见的差异
差异通常不会以报错的形式出现，而是藏在细节里。以下几类比较典型：
- 旧链接仍在副本中。栏目改版、列表页调整之后，缓存里的 HTML 还带着上一版的内链结构，搜索蜘蛛按这些链接继续发现旧地址。
- 已下线的 URL 仍被指向。页面合并或删除后，若入口列表的缓存没有刷新，旧 URL 会持续被带进抓取队列。
- 状态码被缓存。某个 URL 短暂返回 404 或 503 时被缓存下来，页面恢复正常后，缓存层仍返回原来的状态码。
- 软 404 页被缓存成 200。内容已清空但模板仍返回正常状态码，缓存和搜索蜘蛛都会把它当成有效页面。
- 更新时间与 sitemap 脱节。页面内容已更新，但缓存副本和 sitemap 里的标记各说各话。
这些差异如果长期存在，URL 发现的方向就会和实际站点结构偏离，抓取路径也会越走越散。
用日志核对差异是否存在
判断缓存层到底返回了什么，最直接的办法是对照两边的日志。
源站日志与 CDN 日志对照
源站只记录回源请求，CDN 日志记录全部请求。把同一时间段的抓取记录放在一起看，如果 CDN 侧的访问量远大于源站，说明大部分抓取被缓存接住了。此时要重点关注缓存侧返回的响应体版本，而不是只看回源那几次。
带缓存标识做一次取回
用与搜索蜘蛛相近的请求头访问目标 URL，查看返回头中的缓存命中标识和缓存时间。命中时间很早、内容却是旧版，就说明副本该刷新了。
抽样检查入口页
首页、主导航、栏目列表页是 URL 发现的主要来源，优先检查这几类页面的缓存副本中，链接是否与当前版本一致。这几处一旦落后，影响面最大。
处理顺序建议
发现问题后，不建议一次性清空全部缓存，那样容易在短时间给源站带来集中回源压力。可以按下面的顺序处理：
- 先刷新承担 URL 发现职责的页面：首页、导航、栏目列表、HTML 站点地图页。
- 再刷新近期改版或下线过页面的目录，清理副本中的旧链接。
- 修正状态码缓存策略，明确哪些状态码可以缓存、缓存多久。404、410、503 这类状态码通常不宜长时间缓存。
- 把 sitemap 的更新与页面缓存刷新放在同一批操作里完成，避免两边时间不一致。
- 最后检查内容更新频繁的详情页，为其设置较短的缓存时间或主动刷新机制。
缓存命中不等于抓取变少
有站长看到源站日志里抓取次数下降，就以为搜索蜘蛛来得少了，于是加大推送或调整 robots 规则。实际上，缓存命中只是让源站不再处理这部分请求，抓取行为本身可能并没有减少。判断抓取量应以缓存侧日志为准，源站日志更适用来观察回源压力与回源内容是否正确。
另一个容易被忽略的点是缓存键。如果缓存键包含完整查询串，同一个页面的多种参数组合会各自生成副本，副本越多，被搜索蜘蛛读到的版本就越难统一。参数类 URL 的收敛工作，最好和缓存策略一起梳理。
缓存负责让页面更快返回，但它不负责判断内容是否还是最新。抓取路径的正确性，最终要靠刷新机制和状态码策略来保证。
把缓存层当成抓取路径上的一个中间环节来管理，定期核对副本内容与源站版本，URL 发现和后续抓取才不会因为一份过期的 HTML 而跑偏。