蜘蛛来抓页面时，拿到的未必是你刚发布的那一版。中间可能隔着浏览器缓存、CDN 边缘节点、反向代理、对象存储，任何一层多留了一份旧副本，蜘蛛就会按旧内容做判断。缓存本身不是问题，问题在于“缓存了多久、缓存了什么、怎么失效”这三件事没管清楚。
缓存最容易引发的四类抓取问题
- 旧 HTML 里留着旧链接：页面改版后，缓存副本仍指向已删除的 URL，蜘蛛顺着爬过去，撞上一串 404。
- canonical 指向过期地址：缓存的是上一版的 head，正本指向已经 301 的旧地址，信号自相矛盾。
- 状态码被缓存：某个节点在源站维护期间缓存了 503 或 404，源站恢复后边缘还在返回旧状态。
- 节点之间内容不一致：A 节点是新的，B 节点是旧的，蜘蛛抓到哪一版基本靠运气。
自查：先看响应头，再比源站和边缘
1. 用命令行看缓存痕迹
对目标 URL 发一次 HEAD 请求，重点看这几个字段：
- Age：大于 0 说明这份内容来自中间层，数字越大越旧。
- Cache-Control：确认 max-age 是给 HTML 的还是给静态资源的，两者不该用同一套策略。
- X-Cache、CF-Cache-Status 之类的厂商头：直接告诉你 HIT 还是 MISS。
- Last-Modified 与 ETag：用来判断边缘手里的副本是不是当前版本。
2. 源站与边缘各取一份做对比
直连源站 IP 并带上正确的 Host 头取一份，再通过域名走 CDN 取一份，对比标题、canonical、正文首段是否一致。连续请求几次，观察 Age 是否在增长，判断是否命中缓存。这一步能快速暴露“源站已更新、边缘还没动”的情况。
3. 多节点抽查
用不同地区的探测节点请求同一个 URL，记录状态码和内容指纹。如果各地差异明显，多半是刷新没推全，或者某些节点回源失败后返回了旧副本。站点规模不大时，抽查十个左右节点就够用。
哪些该长缓存，哪些不该
- 静态资源（JS、CSS、图片、字体）：可以长缓存，但要配文件名指纹。改版靠换文件名，而不是靠刷新缓存。
- HTML 文档：不建议长缓存。可以用较短的 max-age 搭配协商缓存，保持内容新鲜度。
- robots.txt、sitemap、RSS：这类文件更新后需要立刻生效，不宜设置长缓存。
- 301、302 跳转：跳转规则调整后要清理边缘缓存，否则旧跳转还会被执行一段时间。
要固定进发布流程的动作
- 发布完成后，主动刷新首页、相关栏目页、本次更新的详情页，以及 sitemap 文件。
- 涉及换域名、换路径、改 canonical 的改版，做一次全量清理，而不是等缓存自然过期。
- 把“刷新缓存”写进发布清单，和内容上线放在同一批操作里执行。
- 源站维护或临时下线期间，避免让边缘把 5xx 当成正常响应长期保存；维护结束后再复查一遍状态码。
- 记录缓存策略和节点配置的变更时间，出问题时能和抓取日志对上。
蜘蛛看到的是哪个版本，取决于它落到哪个节点、那个节点手里是哪一份副本。缓存策略的目标不是“最快”，而是让用户和蜘蛛拿到同一个当前版本。
最后提醒一句：如果 HTML 响应头里写着 max-age 很大的 public 缓存，等于告诉所有中间层“很久别来问我”。按资源类型区分缓存时长，比事后一条条清理要省事得多。定期花十分钟看看响应头，往往比事后追查抓取异常轻松。