WordPress 斗篷：三种实现路径、一个缓存陷阱与平台政策红线（2026）

搜「cloaking WordPress」，你会同时撞进两场几乎不相干的讨论。

一场是搜索引擎的问题：WordPress 站能不能给 Googlebot 一个页面、给真人另一个页面？这就是教科书定义的搜索引擎斗篷，违反 Google 的垃圾内容政策，答案很短——别做。

另一场是投放的问题：广告主把流量打到一个 WordPress 落地页，希望这个页面对审核、对机器人、对地域不符的访客，表现和对真正目标受众不一样。同一个词，机制完全不同，规则也完全不同。

本文讲第二件事——请求级分流在 WordPress 上到底怎么落地、有哪一个坑是 WordPress 独有的、以及广告平台的红线画在哪。

同一个词，两件不同的事

搜索引擎斗篷指的是：在同一个 URL 上，给搜索爬虫的内容与给真人的内容有实质差异，目的是影响排名。Google 在垃圾内容政策里点名了它。处罚不是一条警告横幅，是从索引里拿掉。本文没有一段是在教怎么"安全地"做这件事，因为不存在这种做法。

投放侧分流指的是：落地页根据请求信号渲染不同内容——点击来自哪里、什么设备发起、请求形态是否像自动化程序。广告平台并不禁止分流本身，它们禁止的是失实呈现：让审核看到的页面，与真实用户在同一条广告下看到的页面有实质差异。

真正决定性质的不是技术手段，而是审核或爬虫看到的那一版，是不是对这个报价的诚实呈现。两套实现可以用一模一样的代码，却落在这条线的两侧。

WordPress 上的三种实现路径

WordPress 给了你三个切入点，行为差别很大。

PHP 路径（服务端）

挂在 template_redirect 上、或在请求早期过滤模板，检查请求后返回不同的标记。所有判断都在字节送达浏览器之前完成。

这是三种里最可靠、也最容易出事的一种。可靠在于判断发生在你完全掌控的位置，不会出现内容闪烁。危险在于它对每一个请求都生效——包括某位审核人员在你没考虑过的国家、用手机点开你广告的那一次。

JavaScript 路径（客户端）

页面只发一份 HTML 文档，加载后由脚本按浏览器侧探测到的信息改写它。

好处是容易加装到现成主题上，而且能绕过大多数缓存设置——因为被缓存的 HTML 对所有人都一样。代价是：改写前的那份文档，正是爬虫读到的、"查看源代码"看到的、任何无头抓取拿到的东西。如果发出的 HTML 与渲染后的页面讲的是实质不同的两个故事，这个落差本身就是把柄，而且极易被发现。

边缘路径（反向代理）

判断完全发生在 WordPress 之前——一个 worker、一个边缘函数，或者在请求到达 PHP 之前就完成路由的代理层。

这让 WordPress 保持简单，也把逻辑从插件这个会自行更新的面上挪走了。相应地，你的分流逻辑和 CMS 变成两套可能各自漂移的系统，而且 WordPress 迁站时它不会跟着走。把这件事做成产品的平台——DeepClick 的绿盾是其中之一——正是出于这个原因待在这一层。

只有 WordPress 会踩的那个坑

下面这段是大多数教程会跳过的，而它恰恰是真正让部署失效的原因。

WordPress 站几乎一定在跑整页缓存。WP Rocket、W3 Total Cache、LiteSpeed Cache、主机层的 Varnish、Cloudflare APO——总有一种在开着，常常不止一种，有时站长自己都不知道。

整页缓存与服务端分流是直接冲突的。 缓存的全部职责，是把一个页面算一次，然后把同样的字节发给所有请求同一 URL 的人；而你 PHP 分流逻辑的全部职责，是给每个请求算出不同的页面。谁先跑，谁说了算。

实际后果是：缓存清空后的第一个访客，决定了在缓存过期之前所有后续访客看到什么。如果第一个请求来自爬虫，所有人都拿到爬虫那一版；如果它来自目标受众，下一个审核就拿到目标受众那一版。两种结果都不是你配置的意图——而且你每次登录着测都会觉得一切正常，因为登录用户绕过缓存。

如果这篇只带走一句话：在你调试分流逻辑之前，先确认缓存在做什么。 退出登录测、用干净会话测、测不止一次，并检查响应里有没有缓存命中头。一套从没在热缓存下被验证过的分流配置，等于没验证过。

可行的解法有三个：把落地路径整个排除出整页缓存；让缓存键随你分流依据的信号变化；或者把判断挪到缓存之前的边缘层。不可行的做法是假设插件和缓存会自己商量好。

广告平台的红线到底在哪

各家措辞不同，实质是收敛的：

Meta 归入"规避系统"（circumventing systems）——多数广告主第一次遇到的处罚通知就是它，触发条件是审核所见与用户所得之间的落差，而不是某种具体技术。
Google Ads 放在目标网址要求里：目标页必须与广告承诺、与被审核的内容一致。
TikTok 写在落地页政策里，失实呈现的逻辑完全相同。

没有任何一家说"不许分流"。把商店按地域路由到区域目录是分流；按 Accept-Language 给对应语言是分流；按设备给不同版式是分流；A/B 测试是分流，而且每家主流广告平台都自带 A/B 工具。

一致的触发条件是：被审核的体验和被交付的体验，描述的是两个不同的报价。当各个分支只是同一个诚实报价的变体时，没有平台会有意见；当一个分支的存在是为了被审核、另一个分支的存在是为了成交，那就是违规——无论它是用 PHP、JavaScript 还是边缘层写的。

常见问题

在 WordPress 上做斗篷违反 Google 规则吗？

在同一 URL 上给爬虫与用户实质不同的内容、目的是影响排名，违反 Google 垃圾内容政策。同一内容的地域、语言、设备变体不算斗篷，明确是允许的。

用插件做安全吗？

插件能实现请求分流，但它无法让分流变得诚实，而且同样受上面那个缓存冲突的影响。插件层也是最容易在 WordPress 核心更新后失效的一层。

客户端分流能对审核隐藏什么吗？

不能。服务器发出的那份文档，任何不执行脚本就抓取该 URL 的一方都读得到，包括自动化审核工具。客户端实现是最容易被检查的，不是最难的。

为什么我自己测好好的，真实流量就不对？

几乎总是整页缓存，加上你测的时候是登录状态。登录请求绕过大多数 WordPress 缓存。请用干净会话、退出登录再测。

上线前的五项自检

先说清哪一版是诚实的那版。 哪个分支你愿意直接拿给审核看？如果答案是"都不愿意"，到此为止——没有任何实现细节能补救这一点。
确认缓存行为。 退出登录、反复测，验证响应不是从热缓存里发出来的。
不执行 JavaScript 抓一次自己的 URL。 拿回来的东西就是爬虫和审核工具看到的东西，按他们的视角读一遍。
检查兜底分支。 当信号缺失或含混时渲染的是哪一版？那个默认值，就是大多数未被识别流量拿到的东西。
写下留存策略。 如果你无法还原"哪个访客看到了哪一版"，你就没法应对申诉。

一句话总结

「WordPress 斗篷」是两个问题共用一个名字。搜索引擎那个问题，答案只有一个词；投放那个问题是真实的工程问题——三个实现层、一个 WordPress 独有的陷阱（整页缓存悄悄让服务端分流失效），以及一条关于诚实呈现而非技术手段的政策线。

先把缓存这件事搞清楚，再去把分流逻辑写得聪明。大多数失败的部署，问题从来不在代码里。