缓存是站点运营里最不顯眼、也最容易出岔子的一环。它能让頁面變快，也能让蜘蛛在几天里反复拿到同一份舊内容：标题改了、價格換了、商品下架了，用戶看到的是新版，搜尋引擎拿到的却還是缓存层里的副本。這類問题不报错、不报警，只在抓取结果里慢慢顯形。
為什么缓存問题容易被漏掉
因為從浏览器里看不出来。运营人員在自己电脑上刷新，看到的是本地缓存或者已经刷過的 CDN 节点，很容易得出“已经更新了”的结论。而蜘蛛從另一個地区、另一個节点回源，得到的可能是几小时前甚至几天前的頁面。
更麻烦的是，缓存出問题时頁面往往仍然正常返回 200。狀態碼没错，内容却對不上，這種安静的错誤最难排查，也最容易被归因到別的地方去。
常见的几類缓存坑
- 發布新内容後缓存未刷新：正文已经更新，缓存里還是舊版，蜘蛛抓到的标题和頁面實际内容不一致。
- 缓存键包含了動態參數：同一篇文章按不同參數被缓存成多份，命中率下降，回源压力反而更大。
- 把错誤頁也缓存了：短暂的 404 或 500 被缓存住，蜘蛛连續几天只能看到错誤頁。
- 缓存了重定向規則：A 頁跳 B 頁的配置改過了，缓存里還留着舊跳轉，蜘蛛一直在绕路。
- 回源失敗直接吐错誤碼：源站抖動时 CDN 未做兜底，蜘蛛會把這段異常记在抓取记錄里。
可以按顺序做的自查
- 先理清缓存层級：本地浏览器缓存、CDN 节点缓存、源站或應用层缓存各自管什么，谁负责刷新，出問题时先看哪一层。
- 检查 HTML 的缓存头設定。max-age 是否给得過長，是否把 HTML 和图片、CSS、JS 這類静態资源用了同一套策略。
- 確認缓存键的组成。带查询參數的頁面、带地区或设备区分的頁面，是否會各自生成一份缓存副本。
- 检查错誤頁是否被缓存。建议 404、500 這類响應設定較短的缓存時間或不缓存，避免異常狀態被固化。
- 用不同地区、不同 UA 的實际請求驗證，而不是只看自己浏览器里的刷新结果。有條件时對比响應头里的缓存命中标识。
- 检查回源失敗时的表現。源站短暂不可用时，返回的是缓存舊頁還是 5xx，這决定了蜘蛛看到的是内容還是故障。
- 把刷新動作寫進發布流程。内容更新、栏目調整、模板改版之後，明确由谁触發刷新、多久之内完成。
改版期間要格外留心
模板更換、URL 調整、站点迁移這些動作，常常同时改動缓存規則和跳轉規則。两者叠加，最容易出現“用戶看到新版、蜘蛛看到舊版加舊跳轉”的情况。改版上线後，建议挑几個代表性頁面，分別用浏览器和抓取工具實际請求一次，對比内容是否一致。
缓存不是设一次就完事的開關，而是需要跟着内容节奏一起维護的环节。發布越快、更新越频繁的站点，越需要把刷新当成流程的一部分。
小结
缓存本身没有對错，關键在是否與内容更新节奏對齐。把层級理清、把错誤頁排除在外、把刷新動作寫進發布流程，就能减少大量“明明改了却抓不到”的困惑。這類自查不需要复杂工具，需要的是一次次實际的請求驗證，以及不依赖本地浏览器刷新的习惯。