缓存問题往往先在抓取上暴露
CDN 和反向代理缓存的初衷是减少回源、加快訪問。但對搜尋引擎蜘蛛来说，它拿到的响應並不一定来自你的源站。如果缓存键设計得過于宽松、過期時間設定得過長，或者發布新内容後没有及时刷新，蜘蛛就可能反复拿到同一份舊副本，誤以為頁面一直没有變化。這類問题在日常訪問中很难被察觉，因為普通用戶看到的也是缓存副本，打開速度還很快，没有人會去追問内容是不是最新的。
自查可以從這几個方向入手
1. 缓存键是否把不该合並的請求合並了
缓存键决定了哪些請求共享同一份缓存。合並得太多，就會把本该区分的頁面混在一起：
- 是否忽略了移動端與桌面端的区分，把两套模板缓存成一份；
- 是否忽略 Cookie 或登入態，把個性化頁面缓存成公共副本；
- 是否把查询參數一律忽略，導致分頁、篩選頁共用同一份缓存；
- 是否把不同語言、不同地区的版本合並到同一個键上。
2. 缓存时長與刷新机制
HTML 通常适合較短的缓存時間，带指纹的静態资源可以長缓存。重点检查：
- 首頁、列表頁等更新频繁的頁面，缓存時間是否偏長；
- 發布、更新、刪除内容後，是否有主動刷新或按目錄批量刷新的流程；
- 刷新只覆盖 CDN 邊缘，還是同时覆盖源站前面的代理缓存；
- 有没有可自助操作的刷新入口，還是只能等技術手動處理。
3. 回源請求與狀態碼
缓存节点回源时的行為，會直接影响蜘蛛對站点的判断。留意回源是否带上了正确的 Host、协议與路径；更要注意回源返回的 5xx、404 是否被缓存下来。被缓存的错誤响應會在一段時間内持續返回给蜘蛛，影响比源站短暂故障更大。
4. 多节点生效不一致
多节点、多机房的环境下，同一時間不同节点可能返回不同版本。如果規范化标簽、canonical、hreflang 恰好落在版本不一致的頁面上，蜘蛛拿到的信号就會互相矛盾，难以判断哪個才是主版本。
一個简單的检查方法
用命令行工具直接看响應头最省事：观察 Age、X-Cache、Cache-Control、Via 等字段，多次請求同一個 URL，確認命中情况與過期時間是否符合预期。發布新内容後隔几分钟再請求一次，看看返回的是不是新版。带查询參數、带移動端 UA、带不同語言头的請求各测一次，能較快發現缓存键的問题。
缓存不是一次性配置，而是一條需要跟着内容节奏持續维護的鏈路。
日常维護的几條建议
- 把刷新動作寫進發布流程，而不是等出現問题再补救；
- 不同類型的頁面使用不同缓存策略，不要全站一套參數；
- 错誤响應設定較短缓存或不缓存，避免错誤狀態被放大；
- 记錄每次策略調整的時間與原因，方便後續回溯；
- 改動後观察日誌中的狀態碼分布與来源 IP，確認回源比例回到合理区間。
缓存的收益很明确，代價是鏈路變長、變量變多。定期做一遍這類自查，能减少用戶看到新版、蜘蛛看到舊版這種不對称情况，出問题时也少走一些弯路。