蜘蛛抓取站点时，请求通常不会直接打到源站，而是先落到 CDN 或反向代理的边缘节点。这意味着蜘蛛拿到的 HTML，有可能是缓存副本，也可能是回源后的最新版本。两者不一致时，就会出现“自己打开是新的、蜘蛛抓到还是旧的”这类情况，URL 发现和内容判断都会跟着受影响。
抓取请求在链路里的位置
一次抓取大致经过：DNS 解析、边缘节点接入、缓存查找、命中则直接返回、未命中则回源、源站生成 HTML、再按缓存策略写回节点。蜘蛛只看到最后返回的那份内容，中间是命中还是回源、来自哪个节点，它都感知不到。
所以排查抓取问题时，先把“蜘蛛看到的是哪一版”确认清楚，往往比反复修改正文更有效。
缓存键决定了蜘蛛拿到哪一版
边缘节点用缓存键判断两个请求算不算同一个页面。缓存键通常包含 URL 路径和查询字符串，但有些配置还会把请求头纳入进来，比如 Accept-Encoding、User-Agent 或 Cookie。
- 按 UA 区分缓存：如果站点给蜘蛛和普通访客返回不同内容，缓存键里最好带上对应标识，否则两边会互相覆盖。
- Cookie 参与缓存：带会话 Cookie 的请求绕过缓存，回源生成的内容可能夹带个性化模块，蜘蛛抓到的版本和匿名访客并不相同。
- 查询参数被忽略：忽略参数的配置会把带参数的地址和无参数地址归为一份缓存，蜘蛛遍历参数变体时可能反复拿到同一份 HTML。
常见的不一致场景
- 发布新页面后只刷新了首页缓存，新链接所在的栏目页仍是旧副本，蜘蛛顺着旧列表走，找不到新 URL。
- 缓存里存着旧的状态码，某个 URL 已经从 404 变成 200，边缘仍在返回旧响应。
- 多节点部署、回源到不同后端，各边缘节点上的版本不一致，蜘蛛不同轮次抓到不同结果。
- 移动版与桌面版共用缓存键，两边 HTML 混在一起返回。
- Vary 头缺失，同一 URL 因 Accept-Encoding 不同而出现压缩与未压缩两份缓存。
排查顺序
- 用蜘蛛的 User-Agent 向目标 URL 发起请求，保存返回的 HTML。
- 看响应头里的缓存标识字段，确认是命中还是回源，以及缓存写入时间。
- 同一 URL 从不同网络出口、不同节点各请求一次，比对内容是否一致。
- 若不一致，先检查缓存键配置、Vary 设置和回源规则，而不是先怀疑正文质量。
- 调整缓存策略后，再观察服务器日志里蜘蛛的抓取时间与请求结果是否同步变化。
缓存问题往往表现为“抓取不稳定”：同一页面时好时坏。先把内容版本固定住，再谈抓取频率和收录，顺序才对。
发布与刷新的配合
新页面或改版页面发布时，比较稳妥的做法是：内容先上线，主动刷新相关 URL 的缓存（含列表页和详情页），再提交 Sitemap 或补充站内入口链接。顺序反了，蜘蛛很可能在缓存还是旧版本时就来访，抓到的列表里没有新链接。
对更新频繁的列表页，可以设置较短的缓存时间；对变动少、体积大的静态资源，缓存时间可以长一些。关键是让蜘蛛在合理的抓取间隔内，能稳定读到当前有效的版本。
最后一点：缓存配置本身不会让页面被抓取，也不承诺带来排名，它的作用是保证蜘蛛每次来访拿到的内容是一致的、可判断的。版本一致之后，URL 发现、抓取路径和后续的内容评估才有稳定的基础。