编辑器里已经换了标题，预览也正确，退出登录却还是旧内容。这时“预览正常”只能说明当前账号在这次预览请求里看到了新版本，不能证明匿名访客访问的正式页面已经更新。
编辑者可能看到尚未发布的修改，也可能因登录 Cookie 绕过整页缓存；访客请求则可能命中缓存插件、服务器反向代理或 CDN 保存的 HTML。排查需要先确认公开版本，再比较同一正式 URL 的两种访问结果。
本文面向自行维护 WordPress 网站的管理员，重点处理正文、标题和页面区块没有更新的问题。以下命令为示例，未对读者站点做实际测试；涉及缓存策略变更时，应在测试环境验证并记录原配置。
预览链接与正式地址不是同一个验收对象
先在编辑页确认保存操作已经完成，检查文章当前状态、可见性和发布时间。草稿、待审核、定时发布、私密文章以及受密码保护的内容，都有各自的公开访问边界。
对于已经发布的文章，也要确认本次修改已经更新到正式版本。自动保存、修订和预览不能一概视为已向访客发布；具体操作还可能受到编辑器、工作流插件与权限的影响。
预览 URL 往往带有预览相关参数，可能依赖当前登录状态和校验信息。它不适合用作访客验收地址，也不应通过放宽缓存规则让所有人都能访问。
从编辑页取得正式固定链接，在无登录 Cookie 的独立浏览器环境打开。对照域名、协议、路径和重定向后的最终地址，确认没有访问另一个语言版本、旧域名或带参数的页面。
如果文章正文已经更新，首页摘要仍然没变，还应单独检查摘要字段、区块模板和查询来源。有些主题不会直接用最新正文生成卡片。此时清缓存可能不会改变显示结果。
记录一个具体差异，再检查响应
选择一段已经确认发布的独特短句，记录它在编辑器、正式文章页和首页列表中的结果。不要只凭页面整体“看起来像旧的”判断。
Linux 或 macOS 的终端中，可以对公开页面做一次不携带登录凭据的 GET 请求：
# example.com 是占位域名，请替换为目标公开页面。
curl -sS -L --max-time 30 \
-D public-headers.txt \
-o public-body.html \
'https://example.com/sample-post/'
该请求默认不会读取浏览器的登录 Cookie；也不会执行页面 JavaScript。保存的 HTML 可以用于判断服务器返回的正文是否已更新。如果 HTML 正确，而浏览器渲染后又变旧，需要继续检查前端脚本、接口响应或本地缓存。
响应头文件可能包含多次重定向的记录，应看最终页面对应的一组头信息。Age、Cache-Control、ETag、Last-Modified 和服务商提供的缓存状态字段能提供线索，但不能单独指认是哪层出了问题。
Age表示缓存响应的年龄信息，不能直接推算文章最近一次编辑时间。ETag和Last-Modified用于验证内容是否变化，值存在不等于内容一定新鲜。X-Cache等字段没有跨平台统一含义，应按实际服务文档解释。- 没有缓存状态字段，也不代表请求没有经过缓存。
不要把登录 Cookie、授权头或带令牌的预览链接复制到公开工单。公开页面的诊断文件也应检查是否意外包含个人信息。
强制刷新为什么有时无效
浏览器、整页缓存插件、服务器缓存与 CDN 可以同时存在。浏览器里的强制刷新主要改变本地使用缓存的方式，远端节点仍可能提供已经缓存的响应。
在开发者工具中禁用缓存后重载，可辅助检查浏览器本地缓存。该功能通常受工具开启状态影响，不能据此宣称 CDN 已经绕过。无痕窗口也主要隔离登录态和本地存储，不会自动清空服务器缓存。
追加随机查询参数同样不是可靠的绕过方法。CDN 可能忽略参数，也可能把它作为新的缓存键。后者会产生一个全新的条目，但不能证明原地址已恢复。验收最终仍应回到访客实际使用的标准 URL。
如果站点安装了 Service Worker，还需检查它是否拦截页面或接口请求。可以先用独立测试浏览器核实，避免要求所有访客手动清理站点数据来掩盖服务端问题。
按从内容源到外层的顺序核对缓存
内容更新后，一个常见失效链是：WordPress 已保存新版本，源站整页缓存仍旧；只刷新 CDN，节点又从源站取回旧 HTML。随后 CDN 的缓存时间看起来很新，页面内容却没有变。
处理时先确认内容源正确，再处理源站缓存，最后刷新 CDN：
- 确认正式文章已经更新，模板读取的字段和对象没有选错。
- 检查缓存插件的页面缓存，以及主机面板、Nginx 或其他代理层的整页缓存。
- 确认源站能够提供新内容后，针对受影响 URL 刷新 CDN。
- 使用无登录态请求重新检查原 URL，并观察后续缓存命中的内容。
如果只有文章页被清理，首页、分类页、标签页和相关内容区块仍可能保留旧片段。清理范围应覆盖实际引用位置，也要控制成本：大站全站清空可能造成短时回源压力。
不要为了排查直接删除服务器缓存目录、停用所有插件或重启数据库。优先使用正在管理该缓存层的插件或平台提供的定向清理功能，逐层观察结果。
如果需要比较源站响应，应通过主机平台允许的诊断方式，保留正确的 Host 和 HTTPS 校验；不要临时公开仅供 CDN 回源的服务，也不要关闭访问保护。
登录用户和访客为什么会走不同路径
许多整页缓存方案会识别 WordPress 登录 Cookie，对登录用户采用绕过策略。具体行为取决于插件和代理规则，不能假设所有安装都如此。
这解释了一个容易误判的现象：管理员反复查看正式页面都正确，访客仍拿到旧缓存。管理员的请求可能从未命中那个旧条目。
应分别检查插件、服务器与 CDN 是否正确识别登录态，是否尊重上游的隐私和缓存控制。单靠 Set-Cookie 的存在，不能假定所有中间层都会禁止共享缓存。
Cache-Control: private 用于约束共享缓存；no-cache 允许存储，但要求在再次使用前验证；no-store 则要求不要存储响应。这几个值不能互换，实际行为还需要结合代理是否覆盖响应头判断。
购物车、账户页、订单信息和个人化页面尤其需要隔离。发现访客能看到其他人的信息时，应立即按隐私事件处理，停止相关共享缓存路径并评估影响，不能只把旧页面刷新掉就结束。
修复登录态绕过规则时，避免把整个网站永久设为不缓存。公开文章与个人页面可以采用不同策略，具体语法应依据实际缓存产品，不能把另一款插件的 Cookie 规则直接照搬。
对象缓存与页面缓存要分开判断
WordPress 对象缓存用于减少重复数据读取，持久化对象缓存可以跨请求保存对象。页面缓存则直接保存渲染结果。两者可能同时参与一次访问，但清理对象缓存并不等于清理所有 HTML。
因此，wp cache flush 不适合作为“刷新全站前台”的通用按钮。它主要针对对象缓存；在多站点或共享后端环境中，影响范围还可能超出单个站点，执行前应查明实现和权限。
如果匿名页面旧、登录页面新，先检查整页缓存路径通常更有针对性。只有在证据显示模板或插件读取的对象仍旧时，再核查对象缓存失效逻辑。
对于自定义代码，还需要检查数据更新方式。直接改数据库可能绕过正常的清理钩子；主题或插件另存的 Transient、文件片段和接口结果，也可能有独立的有效期。修改这类逻辑前，应保留代码版本和相关配置，准备回滚。
验收要覆盖第二次命中
定向清理后，第一次匿名访问可能重新生成缓存。只看这一次正确，仍不足以判断后续访客是否正常。
对同一标准 URL 再请求一次，检查内容是否保持新版本；如缓存产品提供可解释的命中字段，再结合它判断缓存是否已经保存了正确结果。不同节点可能有独立条目，需要按业务覆盖范围做有限验证，不必持续高频刷新制造额外压力。
同时检查文章页、首页引用位置和移动端相关页面。不要要求所有设备渲染完全相同，但应确保各自应展示的公开内容一致。登录页、账户页等隐私页面仍应保持正确访问边界。
把这次故障整理成明确记录：修改是否已发布，哪个 URL 被缓存，旧内容由哪层返回，如何触发失效，后续命中是否正确。若每次编辑都需要手工全站刷新，应修复内容发布与缓存失效的联动，减少长期依赖人工清理。
参考资料
核验日期：2026-11-02。以下为 WordPress 官方资料和 MDN HTTP 文档；具体缓存行为以站点使用的插件、主机与 CDN 配置为准。