很多站点把内容放在 CDN 后面，搜索蜘蛛拿到的其实是边缘节点返回的副本。理解这一层，能解释不少「明明更新了，抓的却是旧内容」或者「源站日志里根本没有蜘蛛记录」的现象。
蜘蛛的请求先落在哪一层
搜索蜘蛛的请求和普通用户一样走 DNS 解析，命中离它较近的边缘节点。如果该节点有可用缓存，就直接返回，源站不会留下访问日志。所以只看源站日志时，很容易误判蜘蛛没来过。要完整观察，需要把边缘节点的访问日志也纳入统计，或者至少在 CDN 侧按 UA 做抽样记录。
缓存头会间接影响重抓节奏
缓存策略本身不是排名因素，但它决定了蜘蛛每次来访能拿到什么版本。
- Cache-Control 的 max-age 过长：边缘持续返回旧副本，蜘蛛即使按时重抓也看不到新内容，长期看会压低重抓意愿。
- s-maxage 与 stale-while-revalidate：能减轻回源压力，但过期后的第一批请求可能仍然是旧版本。
- Vary 头设置不当：按 UA 或 Cookie 分缓存时，缓存颗粒度变细，命中率下降，回源次数上升。
robots.txt、Sitemap 与状态码的特殊处理
这几类资源通常不适合长期缓存。robots.txt 一旦在边缘滞留数小时，规则变更后蜘蛛仍按旧规则抓取；Sitemap 被缓存过久，新 URL 的发现会被拖慢；而源站短暂故障时，如果边缘把 5xx 也缓存下来并持续返回，蜘蛛可能连续多次收到错误响应，对后续抓取安排并不有利。
建议对 robots.txt、Sitemap 和主要栏目页设置较短的缓存时间，并明确禁止缓存 5xx 响应。
边缘与源站不一致时的排查顺序
- 用蜘蛛 UA 直接请求目标 URL，看响应头里的 X-Cache、Age、CF-Cache-Status 一类字段，判断是命中还是回源。
- 对比边缘返回的 HTML 与源站输出，重点看首屏内容、正文和关键链接是否一致。
- 检查是否把蜘蛛 UA 误拦在缓存或风控规则之外，导致 403、429 频繁出现。
- 刷新缓存后再次请求，确认版本已更新，再去抓取日志里核对蜘蛛的再次访问时间。
缓存和抓取是两条线：缓存解决的是「谁来拿、拿得多快」，抓取解决的是「蜘蛛愿不愿意再来」。两者都理顺，效果才会叠加。
内链与 URL 发现不依赖缓存层
无论请求走哪一层节点，页面里的链接始终是蜘蛛发现新 URL 的主要路径。边缘缓存只影响内容版本和响应速度，不会替站点补上缺失的内链。因此改版、上新栏目时，仍然要把入口链接、Sitemap 和分页路径一起检查一遍，不要指望缓存层能替代结构梳理。
把边缘日志、响应头和内链结构放在一起看，比单独盯任何一项都更容易定位问题。