很多站点更新内容後，自己在浏览器里刷新看到了新版本，就預設搜尋引擎也會看到同一份。實际上，中間可能隔着 CDN、反向代理、對象缓存、頁面缓存等多层缓存，蜘蛛拿到的可能是几小时甚至几天前的舊頁面。缓存本身不是問题，問题在于“你看到的”和“蜘蛛看到的”不一致，而且没人定期核對。
先搞清楚缓存鏈路有哪几层
自查之前，先把頁面從源站到訪問者之間经過的缓存层列出来，常见的有：
- 浏览器缓存：由 Cache-Control、Expires 控制，對搜尋引擎影响相對小。
- CDN 邊缘节点缓存：按缓存键存放副本，TTL 到期才回源。
- 反向代理 / 網關缓存：Nginx、Varnish 一類，規則寫错容易長期缓存 HTML。
- 應用层頁面缓存：框架或插件生成的静態化文件、對象缓存。
- 資料库與查询缓存：一般不影响最终 HTML，但會拖慢回源速度。
任何一层把 HTML 缓存住，都可能造成蜘蛛與真實内容脱节。
三個最常见的坑
1. HTML 被当成静態资源長期缓存
把 .html 或動態路径設定成 TTL 7 天、30 天，上线初期看不出問题，内容一改就出問题。首頁、栏目頁、列表頁這類更新频繁的頁面，TTL 應该短一些，或者配合主動刷新机制。
2. 缓存键里带了不该带的维度
有些配置會把 User-Agent、Cookie、Referer 一起作為缓存键。结果就是同一個 URL 在不同 UA 下生成多份副本，蜘蛛拿到的那份可能恰好是舊版本，或者是一個被裁剪過的頁面。要確認缓存键只包含必要维度，並检查 Vary 头有没有把爬虫引向错誤的副本。
3. 回源失敗後繼續返回舊副本
源站短暂 5xx 时，CDN 若配置了“過期後繼續提供舊内容”，訪問者看不到报错，但蜘蛛可能長時間拿到過期頁面。這類策略要寫清開啟條件和最長保留時間，別让它無声無息地拖上几周。
自查怎么做
- 選 5–10 個代表性 URL：首頁、最新栏目頁、刚更新的詳情頁、一個長期不變的頁面。
- 用带蜘蛛 UA 的請求抓取响應头，记錄 Age、X-Cache、Cache-Control、Last-Modified、ETag 等字段。
- 和源站直连的响應做對比，重点看内容長度、正文關键句、時間戳是否一致。
- 更新一篇内容，观察各层缓存多久後同步，记錄實际延迟。
- 確認主動刷新通道可用：CDN 刷新入口、應用层缓存清理方式，是否有人會用、有没有權限。
判断标准很朴素：把蜘蛛拿到的 HTML 存下来，和你预期的最新版本逐段比一次。不一致，就是缓存没管好。
日常运营里的几條习惯
- 重要更新走“先刷新缓存、再观察”的流程，別發完就等自然過期。
- 给缓存 TTL 做一張表，按頁面類型分层：首頁和列表頁短 TTL，詳情頁可稍長。
- 回源異常时的兜底策略寫清楚，最長保留時間要有上限。
- 把缓存核對放進每周巡检，和日誌抽样一起做。
- 改版或迁移前，先確認缓存清理顺序：應用缓存 → 源站 → CDN 邊缘。
缓存優化的目标不是让命中率越高越好，而是让“命中”和“正确”同时成立。對站点运营来说，蜘蛛看到的版本是否等于你正在维護的版本，比省下多少回源流量更重要。