企业官网建设流程全解析

前天有个站点改了首页标语，后台一看已经是新文案，无痕窗口刷新十几次还是旧的。客服以为「没保存成功」，运营以为「被回滚了」，最后发现是页面缓存和 CDN 各留了一份旧 HTML。WordPress 改内容前台不更新，多半不是数据库写失败，而是某一层缓存还在喂旧页。

先分清：到底是哪一层还在吐旧内容

不要一上来就「清全站缓存」或重启服务器。用无痕窗口打开出问题的 URL，F12 → Network，点开文档请求（通常是第一个 HTML），看响应头里有没有这些字段：

• x-cache/cf-cache-status/age：边缘或反向代理是否 HIT
• cache-control：是public, max-age=…还是no-store/private
• set-cookie：登录态或会话 Cookie 有没有被错误地跟可缓存 HTML 绑在一起

把「浏览器本地」「CDN 边缘」「源站页面缓存」「对象缓存」四层分开想。每一层的清法不一样，混着清既慢又容易把整站打冷。

第 1 层：浏览器——先排除「你自己的缓存」

同事反馈「我这边已经新了，你那边还旧」，优先怀疑本机缓存或扩展。

1. 用无痕/隐私窗口打开同一 URL，或换一台没开过该站的设备。
2. 硬刷新（Ctrl/Cmd + Shift + R）。若硬刷新变新、普通刷新仍旧，多半是浏览器或中间代理在缓存 HTML。
3. 若站点挂了 Service Worker / PWA，在 Application 面板看是否还在拦截导航请求。

可对前台 URL 做一次只读头探测（不要带管理后台 Cookie 去乱刷生产接口）：

curl-sI'https://example.com/'|egrep-i'HTTP/|cache-control|x-cache|cf-cache|age|vary|set-cookie'

期望心里有数：营销首页若故意边缘缓存，HIT 是正常的；但你刚改完且清过 CDN 后仍长期 HIT、且age很大，说明清理没落到这个 URL。

第 2 层：CDN / 边缘——按 URL 定点 purge，别迷信「一键全清」

很多外贸站前面挂了 Cloudflare 或其它 CDN。改标题、改首页模块之后，若边缘仍 HIT，访客看到的就是生成时间戳更早的那份 HTML。

建议顺序：

1. 只 purge 变更相关的 URL（首页、该文章 permalink、相关归档），先验证这几个变新。
2. 再查规则：是否把带utm_的 URL 当成不同缓存键导致「有的链接新、有的旧」；是否忽略查询串不当，把预览参数缓存进去了。
3. 登录态、预览链接、/wp-admin/、购物车/结账路径应旁路，不要和匿名首页共用同一份全页缓存。

全站 purge 可以救急，但高峰期会把回源打满，表现为「清完反而全体变慢五分钟」。能定点就定点。缓存与 CDN 分层怎么对齐，可以对照 WordPress CDN 与缓存加速要点。

第 3 层：源站页面缓存插件——发布钩子有没有接到

CDN 清干净了，源站页面缓存插件仍可能继续吐旧 HTML。常见表现：直连源站 IP 也是旧文案，或curl --resolve到源站仍旧。

核对这几项：

• 发布/更新文章后，插件是否自动失效对应 URL；手动点「更新」后是否要再点插件里的「清除此页」。
• 多语言、自定义文章类型、页面构建器（把内容存在 post meta）是否被插件的「仅清文章 permalink」漏掉。
• 是否同时开了两套页面缓存，规则互相覆盖，你清了 A，B 还在。

生产环境慎用「清空全部对象 + 全部页面」的大按钮，除非你明确知道流量和预热策略。优先清问题 URL，再抽查列表页、分类页是否也引用了旧摘要。

第 4 层：对象缓存与「半新半旧」

有时 HTML 壳子新了，侧栏、菜单、相关文章模块还是旧的——这更像object cache / transient里缓存了查询结果或小部件输出。

处理思路：

1. 若用了 Redis/Memcached，在低峰对对象缓存做一次有针对性的 flush（先确认插件/主机面板提供的是对象缓存而不是整站文件缓存）。
2. 查是否有自建 transient 把首页模块锁了很久的过期时间；改内容后没有删除对应 key。
3. 菜单、小工具、页面构建器全局模块常被单独缓存——清页面不等于清这些片段。

# 有 WP-CLI 时，确认对象缓存后端（只读探活，按你环境调整）wp cachetype

对象缓存异常时，也会出现「后台已新、接口偶发旧数据」；和纯 HTML 边缘 HIT 要分开看。

快速验收（改完再收工）

按这个勾一遍，比反复「感觉刷新一下」可靠：

1. 无痕窗口打开变更 URL：文案/标题已是新版；再换一个带utm_source=test的链接，避免只测了一种缓存键。
2. curl -sI看问题 URL：清过后应出现 MISS/BYPASS 或更小的age；确认不是登录 Cookie 下的特例。
3. 直连源站与走 CDN 各看一次，避免「边缘新了、源站还旧」或反过来。
4. 相关列表页、首页模块、菜单若引用了该内容，也抽查，防止片段缓存漏清。

前台还是旧版，很少是「WordPress 没保存」，多数是某一层还在提供旧响应。按浏览器 → CDN 定点 → 源站页面缓存 → 对象缓存往下压，通常比重启整机更快，也少误伤高峰流量。