最近我准备继续测试 Adsterra。
此前，我已经在中文站和英文站的文章内容末尾加入 Native Banner。由于目前 Adsterra 的数据量还非常小，我并不打算立刻大规模增加广告，而是准备新增一个相对克制的位置：
在分类、标签等归档页面的文章列表末尾，再增加一个 Native Banner。
原本这应该只是一个很简单的 WordPress 模板修改。
但实际处理过程中，我先后怀疑了 WPCode、PHP Snippet、Shortcode、Twenty Twenty-Five Block Template、Language Visibility、EdgeOne、W3 Total Cache Page Cache，最终才确认：
真正的问题仍然来自多域名架构下的 W3 Total Cache Object Cache。
更准确地说，是同一个 WordPress Block Template 已经在数据库中更新，但 www 和 en 不同 Host 的前台请求仍然能够从 Redis Object Cache 中取得旧模板。
这也让我重新意识到：7 月中旬已经解决过一次的多域名缓存问题，并没有真正覆盖 WordPress 中所有可编辑对象。
一、当前 WordPress 多域名架构
目前网站主要存在三个域名：
admin.shuijingwanwq.com
www.shuijingwanwq.com
en.shuijingwanwq.com
其中：
admin.shuijingwanwq.com 用于 WordPress 后台管理，绕过前台 CDN。
www.shuijingwanwq.com 是中文站，目前使用 EdgeOne。
en.shuijingwanwq.com 是英文站，目前使用 Cloudflare。
三者并不是三套 WordPress。
它们共用同一套 WordPress 程序、同一个数据库，同时 W3 Total Cache 的 Object Cache 使用 Redis。
之所以单独增加 admin.shuijingwanwq.com，也并不是为了单纯拆分域名。
此前 WordPress 后台操作经过前台 CDN 时，曾经出现过核心升级等长请求超时的问题，因此后来专门建立独立后台域名。
这部分过程此前已经整理过：
因此，目前我并没有因为这次问题就准备取消 admin 域名。
真正需要继续解决的，是多个 Host 共用 WordPress 时的缓存一致性问题。
二、这次原本只是想增加第二个 Adsterra 广告位
此前文章页尾部的 Adsterra 已经通过 WPCode 实现。
中文和英文使用不同的 Native Banner 广告代码：
中文站使用一套广告单元，英文站使用另一套广告单元。
这次计划增加的是：
所有归档页面文章列表底部广告。
也就是说，包括标签页、分类页等使用“所有归档”模板的页面。
最开始，我仍然准备通过一个 PHP Snippet，根据当前 Host 判断应该输出中文广告还是英文广告。
大致逻辑是：
if ( 'www.shuijingwanwq.com' === $host ) {
// 输出中文 Adsterra。
}
if ( 'en.shuijingwanwq.com' === $host ) {
// 输出英文 Adsterra。
}
从现在回头看，这个 PHP 逻辑其实很可能并没有问题。
但是当时前台始终看不到预期广告。
继续分析下去以后，影响因素越来越多：
WPCode 自动插入位置、Block Theme 渲染顺序、Shortcode、归档模板、缓存以及多语言判断全部混在一起。
考虑到投入时间已经越来越不可控，我决定先停止继续验证 PHP 方案。
三、改用已经长期验证过的 Language Visibility
我的 WordPress 中原本就已经在使用 Language Visibility。
例如博客首页的个人品牌信息：
中文页面输出：
👨💻 个人品牌
王世强｜PHP / Go 技术顾问
英文页面则输出：
👨💻 Personal Brand
Wang Shiqiang | PHP & Go Technical Consultant
实际抓取页面 HTML 后可以确认：
中文站只有中文内容：
个人品牌：1
Personal Brand：0
英文站只有英文内容：
个人品牌：0
Personal Brand：1
也就是说，它并不是把两种语言都输出以后再通过 CSS 隐藏，而是会根据当前语言决定是否真正渲染区块。
既然现有方案已经验证稳定，我决定不再在一个 PHP Snippet 中自行判断 Host，而是拆成两个独立的 HTML Snippet。
中文：
[Adsterra] Native Banner - 所有归档页尾部广告 - 中文
英文：
[Adsterra] Native Banner - 所有归档页尾部广告 - 英文
然后在 Twenty Twenty-Five 的“所有归档”模板中：
Query Loop
分页
Language Visibility：中文
└── 中文 Adsterra Shortcode
Language Visibility：English
└── 英文 Adsterra Shortcode
这样每个组件只承担一个职责：
WordPress 模板负责广告位置。
Language Visibility 负责语言。
WPCode HTML Snippet 负责保存广告代码。
这个结构明显比一个 PHP Snippet 同时负责域名识别和广告输出更容易理解。
四、但是修改模板以后，前台仍然没有广告
问题也正是在这里开始变得奇怪。
数据库中的“所有归档”模板 ID 为：
17457
检查数据库以后，可以明确看到两个新的 Shortcode：
21010：中文
21013：英文
get_block_template() 得到的模板也是最新版：
source: custom
wp_id: 17457
21010: YES
21013: YES
两个 WPCode Snippet 本身也没有问题。
直接执行 Shortcode 时：
21010
shortcode_container: FOUND
21013
shortcode_container: FOUND
因此可以排除：
WPCode HTML Snippet 本身错误。
Shortcode 无法执行。
广告代码没有保存成功。
接下来又检查了 Language Visibility。
归档模板的结构是：
wp:tepll/pll-language-visibility {"lang":"zh"}wp:tepll/pll-language-visibility {“lang”:”en”}
而博客首页已经正常运行的个人品牌区块，同样使用：
wp:tepll/pll-language-visibility {"lang":"zh"}
和：
wp:tepll/pll-language-visibility {"lang":"en"}
因此 Language Visibility 的模板结构也没有发现问题。
五、真正的异常：数据库和真实 HTTP 请求看见了两份模板
为了进一步确认问题，我在“所有归档”模板中临时增加了几个测试 Marker。
例如：
SWQ_ARCHIVE_TEMPLATE_TEST
SWQ_ARCHIVE_ZH_TEST
SWQ_ARCHIVE_EN_TEST
随后又删除并保存。
数据库检查已经确认：
RAW DATABASE:
SWQ_ARCHIVE_TEMPLATE_TEST: NO
SWQ_ARCHIVE_ZH_TEST: NO
SWQ_ARCHIVE_EN_TEST: NO
WordPress 的 get_block_template() 同样显示：
RESOLVED TEMPLATE:
SWQ_ARCHIVE_TEMPLATE_TEST: NO
SWQ_ARCHIVE_ZH_TEST: NO
SWQ_ARCHIVE_EN_TEST: NO
21010: YES
21013: YES
也就是说，数据库和 WP-CLI 都已经看见最新版模板。
但是前台 HTTP 请求竟然仍然可以看到：
SWQ_ARCHIVE_TEMPLATE_TEST
SWQ_ARCHIVE_ZH_TEST
这意味着问题已经不可能只是：
“模板忘记保存”。
“Language Visibility 设置错误”。
“Shortcode 没有执行”。
此时缓存成为了最大的嫌疑。
六、首先排除了 CDN
中文站目前使用 EdgeOne。
如果普通请求：
https://www.shuijingwanwq.com/tag/git/
得到旧页面，那么当然有可能只是 EdgeOne 缓存。
因此测试时使用：
curl \
--resolve www.shuijingwanwq.com:443:127.0.0.1 \
https://www.shuijingwanwq.com/tag/git/
这样 HTTPS Host 仍然是 www.shuijingwanwq.com，但实际连接服务器本机 127.0.0.1。
因此可以绕过 EdgeOne。
然而，旧页面仍然存在。
所以问题并不只在 CDN。
七、W3TC Page Cache 确实存在，但还不是最终根因
继续检查响应，可以看到：
Performance optimized by W3 Total Cache
Served from: www.shuijingwanwq.com ... by W3 Total Cache
进一步找到：
wp-content/cache/page_enhanced/www.shuijingwanwq.com/tag/git/
对应缓存目录。
这个目录只有约 900 KB，其中主要是：
_index_slash_ssl.html
_index_slash_ssl.html_gzip
将 curl 得到的 HTML 与 _index_slash_ssl.html 直接比较：
SHA256 完全一致
RESULT: EXACTLY SAME
因此可以确认：
即使通过 127.0.0.1 绕过 EdgeOne，仍然可能直接命中 W3TC Disk Enhanced Page Cache。
这也是以后排查时非常值得记住的一点：
--resolve ...:127.0.0.1只能绕过 CDN，不能绕过 WordPress 服务器本机的 Page Cache。
但是，仅仅清理 /tag/git/ 的 Page Cache 后，问题仍然能够再次出现。
所以 Page Cache 并不是最底层的根因。
八、真正的突破：清理 W3TC Object Cache
当前 W3 Total Cache 配置确认：
objectcache.enabled: true
objectcache.engine: redis
objectcache.enabled_for_wp_admin: false
Database Cache 则是：
dbcache.enabled: false
因此 Database Cache 可以排除。
随后执行：
wp --allow-root \
--url="https://www.shuijingwanwq.com" \
w3-total-cache flush object
W3TC 返回：
Success: 对象缓存已被成功清空.
再次通过真实 HTTP 请求检查 Block Template：
原本旧版本：
SWQ_ARCHIVE_TEMPLATE_TEST: YES
SWQ_ARCHIVE_ZH_TEST: YES
SWQ_ARCHIVE_EN_TEST: YES
变成：
SWQ_ARCHIVE_TEMPLATE_TEST: NO
SWQ_ARCHIVE_ZH_TEST: NO
SWQ_ARCHIVE_EN_TEST: NO
21010: YES
21013: YES
至此，问题基本锁定：
www 前台使用的 W3TC Redis Object Cache 中保留了旧版 Block Template。
随后重新清理 /tag/git/ 的 Page Cache，让它根据新版 Object Cache 重新生成页面。
中文站最终结果：
TEST MARKERS: 0
ZH ad: 1
EN ad: 0
中文归档广告终于正常。
九、但是英文站仍然没有广告
原以为问题到这里已经结束。
然而英文站：
https://en.shuijingwanwq.com/tag/git/
仍然得到：
ZH ad: 0
EN ad: 0
页面本身没有问题：
HTTP/2 200
<title>Git Tag Archives - Yongye</title>
canonical: https://en.shuijingwanwq.com/tag/git/
Language Visibility 也正确识别成英文：
Personal Brand: 1
个人品牌: 0
继续检查英文真实 HTTP 请求取得的 Block Template：
id: twentytwentyfive//archive
wp_id: 17457
length: 6832
21010: NO
21013: NO
这时出现了一个非常熟悉的数字：
6832
它正是此前多次出现的旧版 archive 模板。
也就是说：
中文已经使用新版模板，但英文仍然持有旧版模板。
十、www 清 Object Cache，并不会自动解决 en
随后改为在英文 Host 上下文执行：
wp --allow-root \
--url="https://en.shuijingwanwq.com" \
w3-total-cache flush object
再次检查英文 HTTP 模板：
length: 7096
21010: YES
21013: YES
变化非常明显。
清理 Object Cache 之前：
length: 6832
21010: NO
21013: NO
清理之后：
length: 7096
21010: YES
21013: YES
这进一步证明：
中文和英文 Host 下的 Object Cache 实际上存在独立的缓存状态。
最后再清英文 /tag/git/ Page Cache：
wp --allow-root \
--url="https://en.shuijingwanwq.com" \
w3-total-cache flush post \
--permalink="https://en.shuijingwanwq.com/tag/git/"
最终：
TEST MARKERS: 0
ZH ad: 0
EN ad: 1
至此，中英文归档广告全部正常。
十一、最终保留的广告实现其实很简单
经过一大圈排查，最终的广告方案反而非常简单。
中文归档：
Language Visibility：zh
└── [wpcode id="21010"]
英文归档：
Language Visibility：en
└── [wpcode id="21013"]
两个 WPCode 都只是 HTML Snippet。
不再自行编写 PHP 判断域名。
但是需要强调：
这并不能说明之前的 PHP 方案有问题。
恰恰相反，从后续发现的缓存现象来看，之前 PHP 方案很可能同样能够正常工作。
当时之所以换成 Language Visibility，并不是因为已经证明 PHP 实现错误，而是因为继续排查 PHP 自动插入方案会引入越来越多变量。
为了及时止损，我选择使用已经在网站中验证过的 Language Visibility 方案。
而最后发现，无论 PHP 方案还是 Language Visibility 方案，都可能受到了同一个底层问题影响：
旧的 W3TC Object Cache 让前台根本没有取得最新的 Block Template。
如果模板本身都是旧的，那么上层使用 PHP 还是 Shortcode，其实已经不是关键。
十二、这次问题与此前多域名 Object Cache 问题非常相似
其实这并不是第一次遇到类似问题。
此前建立 admin.shuijingwanwq.com，以及完成英文子域迁移以后，就已经分析过：
admin
www
en
虽然使用同一个 WordPress、同一个数据库和 Redis，但 W3 Total Cache 的 Object Cache 会受到 Host 影响。
当时也已经为普通文章等场景设计过缓存同步处理，并实现了对应 MU 插件。
目前印象中，这个插件是：
swq-w3tc-polylang-purge.php
此前的处理重点主要是普通文章、Polylang 多语言关系以及相关缓存失效。
而这次暴露了一个新的缺口：
post_type = wp_template
也就是 WordPress Block Template。
数据库已经更新，但 www、en 的前台 Object Cache 并没有同步失效。
这意味着现有 MU 插件很可能还需要继续扩展。
十三、比 Adsterra 更严重的现象：首页仍然停留在 7 月 28 日
实际上，目前还有一个更值得优先解决的问题。
截至 2026 年 7 月 31 日，我发现网站首页展示的最新文章仍然停留在：
7 月 28 日。
也就是说，这次归档广告只是把问题再次暴露出来了。
如果首页最新文章都不能及时更新，那么受影响的已经不只是：
“新广告为什么没有出现”。
还可能包括：
最新文章列表。
分类和标签页面。
Block Template。
多语言页面。
其他依赖 WordPress 查询结果的动态内容。
这已经足够说明：
缓存一致性问题应该提升到当前网站维护的最高优先级之一。
十四、下一步：不再继续增加补丁，而是完善现有 MU 插件
这次广告已经能够正常显示，所以我暂时不会继续研究之前的 PHP 方案。
现在更重要的是回头检查现有：
swq-w3tc-polylang-purge.php
重新梳理它目前到底处理了哪些事件：
普通文章保存以后清什么。
中文和英文 Host 如何同步。
posts:last_changed 如何更新。
Object Cache 如何失效。
Page Cache 如何失效。
然后重点补充此前没有覆盖的对象，例如：
wp_template
wp_template_part
以及其他真正需要跨 Host 同步失效的 WordPress 数据。
目标不是以后每发现一种缓存问题，就再加一个：
flush object
而是让：
admin 保存内容
↓
识别这次修改影响什么
↓
同步使 www / en 对应缓存失效
↓
前台下一次请求自然生成新版
形成稳定的自动闭环。
十五、这次排查最值得记住的几个结论
第一，curl --resolve host:443:127.0.0.1 可以绕过 CDN，但不能因此认为已经绕过 W3TC Page Cache。
第二，清 Page Cache 不一定能够解决问题。
如果 Page Cache 被删除以后，上游 Object Cache 仍然是旧数据，那么重新生成出来的仍然可能是旧页面。
第三，在当前多域名架构下，不能简单认为清一次 Object Cache 就能覆盖所有 Host。
这次实际验证就是：
清 www Object Cache
→ www 恢复
→ en 仍旧
再执行：
清 en Object Cache
→ en 恢复
第四，当：
数据库 = 新
WP-CLI = 新
HTTP = 旧
时，不要再反复修改页面本身。
应该尽早转向检查：
Object Cache
Page Cache
Host
第五，不能因为最终换了一套实现，就认定原来的实现一定错误。
这次从 PHP 改成 Language Visibility，只是为了减少变量、及时止损。
现在来看，两套方案很可能都没有真正的问题。
十六、写在最后
这次原本只是准备在归档页增加一个 Adsterra Native Banner。
最后却花了大量时间排查 WordPress 模板、WPCode、Shortcode、Language Visibility、EdgeOne、W3 Total Cache Page Cache 和 Redis Object Cache。
从技术上看，这次终于定位出了问题。
但从时间投入来看，这并不值得高兴。
因为网站基础设施的目的，本来应该是帮助我更稳定地：
写博客、翻译文章、提升英文内容、测试广告和联盟营销。
如果每一个很小的模板修改，都要花几个小时确认：
admin 是什么状态？
www 是什么状态？
en 是什么状态？
Object Cache 清了吗？
Page Cache 清了吗？
CDN 更新了吗？
那么缓存系统本身已经开始挤占真正应该投入内容生产的时间。
所以接下来，我暂时不会继续增加新的缓存逻辑或新的广告实现。
下一步应该先把现有多域名缓存同步机制重新梳理清楚，并完善已经存在的 MU 插件。
尤其是现在首页最新文章仍然停留在 7 月 28 日，这比归档广告不显示更值得优先解决。
等这个问题真正解决以后，再继续后面的广告和内容工作，应该会轻松很多。
WordPress 网站维护、性能优化与博客运营咨询
本站已持续运营超过 10 年，累计发布 1000+ 篇原创技术文章，长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。
如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题，可以联系我做一次远程技术排查。
适合以下用户：
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点
服务内容：
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询
如需了解方案或交流相关问题，请直接联系我，并注明：WordPress 维护咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复