很多站点更新完文章或調整了栏目後，自己打開頁面却還是舊内容，隔一段時間又正常了。這通常不是發布失敗，而是缓存层在起作用。缓存本身是好事，它能降低服務器压力、加快訪問速度，但如果刷新策略不清楚，就會出現“後台已改、前台未變”的情况。對訪客来说，看到舊信息可能错過活動或價格；對搜尋蜘蛛来说，抓到的也可能是上一版頁面。下面按几個常见环节做一次自查。
先分清有几层缓存
排查之前，先確認請求從浏览器到源站之間经過了哪些缓存。常见的有：
- 浏览器缓存：由 Cache-Control、Expires 等响應头控制，影响單個訪客再次訪問时的本地讀取。
- 頁面缓存：如 WordPress 插件、Nginx fastcgi_cache、應用层缓存，把動態頁面生成静態副本。
- CDN 缓存：邊缘节点缓存静態资源甚至 HTML，命中後不回源。
- 對象存储或反向代理缓存：部分站点把图片、附件放在對象存储，也可能带缓存規則。
先定位是哪一层没刷新，再决定操作，比反复清空所有缓存更有效。
缓存键與規則是否合理
缓存键决定“什么請求算同一個頁面”。如果缓存键包含不必要的參數，可能導致同一内容生成多份缓存；如果缓存键太简單，又可能把不同版本混在一起。
- 检查是否把 URL 參數（如 utm、session、排序參數）带入缓存键，造成缓存碎片。
- 检查移動端與桌面端、登入與未登入狀態是否被错誤地缓存成同一份。
- 检查 Vary 响應头是否按 User-Agent、Cookie 等维度区分，避免给蜘蛛和訪客返回错版本。
- 對 HTML 設定較短的缓存時間，對图片、CSS、JS 等静態资源可設定較長缓存，並配合文件名哈希。
更新後如何刷新
刷新不是越猛越好。按内容影响范围選擇方式：
- 單頁刷新：更新一篇文章後，只刷新该 URL 及其列表頁、首頁。
- 目錄刷新：栏目模板調整时，刷新该栏目下所有頁面。
- 全站刷新：僅在大改版、模板全局變更时使用，避免瞬間回源压力過大。
- 等待自然過期：如果缓存時間很短，也可以观察是否自動更新，不必每次都手動清。
使用 CDN 时，優先用 API 或控制台的刷新功能，並记錄刷新時間、URL 范围、操作人，方便後續核對。
驗證是否真的生效
刷新完成後，不能只看自己浏览器。可以這样驗證：
- 用無痕窗口或另一台设备訪問，排除浏览器本地缓存干扰。
- 查看响應头中的 Age、X-Cache、CF-Cache-Status 等字段，判断是否命中缓存、命中了哪一层。
- 用命令行工具請求时带上随机參數，對比返回内容是否與源站一致。
- 检查蜘蛛常用的抓取路径，確認重要頁面没有長期停在舊版本。
缓存問题往往不是“有没有缓存”，而是“更新後是否可控”。把刷新流程寫進日常操作清單，比临时救火更省心。
把這些习惯固定下来
- 發布前確認缓存策略：哪些頁面短缓存，哪些资源長缓存。
- 發布後按范围刷新，不盲目全站清空。
- 记錄刷新日誌，尤其是批量操作。
- 定期抽查關键頁面的响應头，發現異常及时調整。
- 網站改版、迁移或更換 CDN 时，重新复核缓存規則。
缓存配置没有一劳永逸的标准答案，但可以做到有记錄、可驗證、能回退。這样既保留缓存带来的速度優势，也减少更新不生效带来的沟通成本和抓取偏差。