内容改完了，自己刷新浏览器看到的是新版，但蜘蛛抓回去的仍然是几天前的舊頁面——這種情况在啟用 CDN 或頁面缓存的站点上並不少见。缓存本身是站点运营里必要的一环，問题往往出在缓存策略没有跟着内容更新的节奏走。
為什么蜘蛛更容易拿到舊缓存
普通訪客多數带着浏览器缓存訪問，按一次刷新可能就绕過了缓存；而蜘蛛請求通常是一個全新的、干净的請求，它會正常命中 CDN 邊缘节点或服務端頁面缓存。如果這些缓存没有及时失效，蜘蛛拿到舊版本反而比訪客更稳定。另一個常见原因是缓存键設定不当，比如只按 URL 缓存，却忽略移動端 UA、Cookie 或語言參數，導致不同版本的内容互相覆盖。
先分清站点上到底有几层缓存
- 浏览器缓存：由 Cache-Control、Expires、ETag 控制，影响重复訪問的用戶，也影响部分抓取工具的重复請求。
- CDN 邊缘缓存：节点就近返回内容，更新後需要主動刷新或等待 TTL 到期。
- 服務端頁面缓存與對象缓存：常见于 CMS 插件、反向代理（如 Nginx fastcgi_cache、Varnish）。
- 静態化與資料库查询缓存：静態文件不重新生成，前台就會一直停留在生成前的版本。
自查清單
- 检查 HTML 文档的缓存头。頁面 HTML 一般不适合設定過長的强缓存，用較短的 max-age 配合 ETag 或 Last-Modified，让蜘蛛能拿到較新的版本；图片、CSS、JS 等带指纹的静態资源可以设長缓存。
- 確認 CDN 缓存键包含必要维度。至少区分 HTTP 與 HTTPS、移動端與桌面端（如果返回不同 HTML）、多語言或地区版本。
- 排查是否有頁面在 CDN 上被设為永久缓存，或自定义 TTL 過長（例如 30 天）。内容型頁面通常不适合這種設定。
- 检查缓存插件是否把登入態、表單结果、個性化推荐等私有内容缓存成了公共版本。
- 確認發布内容後是否有自動刷新（purge）動作。不少 CMS 插件只在儲存时刷新目前 URL，首頁、栏目頁、列表頁不會跟着更新。
- 检查 CDN 的“忽略查询字符串”設定，避免把带參數與不带參數的頁面混成同一份缓存。
- 確認回源失敗时节点的行為。部分 CDN 在源站異常时會繼續返回過期缓存，排查問题时容易被誤導。
更新後怎么驗證蜘蛛看到的是哪一版
不要只看自己的浏览器。可以用命令行請求並带上明确的缓存绕過头，观察响應头里的 Age、X-Cache、CF-Cache-Status 等字段，判断這次返回是命中缓存還是回源。再與 CDN 控制台的刷新记錄對照，確認刷新确實生效。修改重要頁面後，間隔一段時間再抓一次，確認内容已经稳定為新版。
如果站点有日誌，可以留意蜘蛛訪問目标頁面时的响應大小與狀態碼，並與源站日誌比對，判断它命中的是节点缓存還是源站。這比單纯看“蜘蛛来過没有”更有參考價值。
两個常见誤区
- 以為清空浏览器缓存就等于全網更新。浏览器只是最外层，节点缓存和服務端缓存還在。
- 把缓存 TTL 设得越長越好。對内容频繁更新的站点，長 TTL 省下的那点回源压力，遠不如内容不一致带来的麻烦。
缓存策略的目标不是让内容永遠缓存，而是让该缓存的缓存、该更新的更新。發布流程里最好把刷新與驗證寫成固定步骤，而不是靠临时想起。
落到流程上
把缓存刷新與内容發布绑定：發布後自動刷新相關 URL（含首頁、栏目頁、列表頁），再抽检一两個頁面確認生效。大改版或批量更新前，提前和负责 CDN 的同事確認刷新方式與生效時間。日常监控方面，可以定期抽查核心頁面的响應头，確認缓存没有長期停留在舊版本上。