不少站长把精力放在内容和结构上，却忽略了两者之间的一个中间层：CDN 与服务器缓存。蜘蛛来抓页面时，拿到的不一定是你刚刚更新的那一版。缓存配得好，响应更快、源站更轻松；配得不好，蜘蛛可能长期看到旧内容、错误版本，甚至拿到一个和 URL 对不上的页面。
先分清缓存的三个层级
排查之前先明确：一次抓取可能经过几层缓存。分不清层级，问题就容易在团队之间来回推。
- 浏览器与本地缓存：主要影响真实用户，对蜘蛛影响有限，但错误的 Cache-Control 值会被沿用到下游。
- CDN 边缘节点缓存：最常见的问题来源，缓存键决定了什么样的请求算“同一个页面”。
- 源站缓存与对象存储：页面生成层或反向代理缓存，如果更新后没有联动失效，蜘蛛取到的仍然是旧 HTML。
常见问题与自查方向
1. 缓存键把不同页面混成一个
如果缓存键只包含路径，忽略了查询参数、语言、设备类型或登录状态，就可能出现 A 页面的内容被返回给 B 请求。对蜘蛛尤其明显：它按 URL 抓取，却拿到另一套内容，URL 与页面的对应关系就乱了。
- 检查带参数的 URL 是否被统一缓存成同一份结果。
- 检查多语言、多地区版本是否用 Vary 或缓存键做了区分。
- 检查移动端与桌面端是否共用了同一份缓存。
2. 过期时间设置过长
把 HTML 文档的缓存时间设成几天甚至更久，更新就很难被及时看到。静态资源（图片、CSS、JS）适合长缓存配合文件名哈希，但 HTML 通常更适合较短的 TTL，或者配合发布时主动刷新。
3. 清缓存只清了一层
发布新内容后只刷新了首页，栏目页、标签页、详情页可能仍是旧版本。蜘蛛恰好先抓到这些页面，就会把过期内容带走。建议把“发布后需要刷新的 URL 清单”固化下来，明确包含列表页和聚合页。
4. 错误页被缓存下来
源站短暂故障时返回的 5xx，如果被 CDN 缓存，可能在故障恢复后继续对外提供一段时间。这类响应本不该被缓存，需要在配置里明确排除。
一份可执行的自查流程
- 用命令行工具分别请求 CDN 地址和源站地址，对比响应头中的缓存标识与内容摘要。
- 记录关键页面的 Age、Cache-Control、X-Cache 等字段，确认命中在哪一层。
- 更新一篇文章，立即重新请求该 URL，观察返回的是否为新版本。
- 再用带参数的 URL、移动端 UA、多语言路径各请求一次，确认没有串页。
- 检查 5xx、404 等异常响应是否带上了可缓存的头部。
和蜘蛛的抓取记录对照着看
缓存造成的影响，往往会体现在抓取记录里：同一 URL 连续多次拿到相同内容、发布后长时间不变、不同 URL 返回高度相似的内容。把 CDN 访问日志与源站日志对照，能较快判断是缓存没刷新，还是页面本身就没有更新。
还需要提醒一点：缓存只是加速手段，不会改变页面本身的质量和结构。如果标题、正文、内链长期没有实质变化，刷新缓存也不会带来什么不同。
把缓存配置当作站点结构的一部分来维护，比出了问题再临时清一次要省事得多。