很多站点更新完文章或调整了栏目后，自己打开页面却还是旧内容，隔一段时间又正常了。这通常不是发布失败，而是缓存层在起作用。缓存本身是好事，它能降低服务器压力、加快访问速度，但如果刷新策略不清楚，就会出现“后台已改、前台未变”的情况。对访客来说，看到旧信息可能错过活动或价格；对搜索蜘蛛来说，抓到的也可能是上一版页面。下面按几个常见环节做一次自查。
先分清有几层缓存
排查之前，先确认请求从浏览器到源站之间经过了哪些缓存。常见的有：
- 浏览器缓存：由 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 时，重新复核缓存规则。
缓存配置没有一劳永逸的标准答案，但可以做到有记录、可验证、能回退。这样既保留缓存带来的速度优势，也减少更新不生效带来的沟通成本和抓取偏差。