Google Tag Gateway 導致 WordPress 後臺瀏覽被追蹤問題

1. 問題背景

Google Tag Gateway（又稱「Google 代碼閘道」）是 Google 與 Cloudflare 聯合推出的功能，讓網站可以透過自己的域名作為第一方代理，轉發 GTM 和 GA4 的追蹤請求，繞過瀏覽器的廣告攔截器，提升數據準確性。

設定方式很簡單：在 Google Tag Manager 後臺的 Admin → Google tag gateway 裏，授權連接 Cloudflare 帳號，選擇域名，設定一個測量路徑（例如 /metrics/），幾分鐘就完成了。

但啓用之後Y Cheung 發現：登入 WordPress 後臺操作時，所有頁面瀏覽也被 GA4 收集了。

2. 問題根源

這個功能在 Cloudflare 的 Zone 層級運作，意思是：

啓用後，整個域名下的所有頁面都會被注入 GTM 腳本
包括 /wp-admin/、/wp-login.php 等後臺路徑
無法透過 Cloudflare 的 Configuration Rules 排除特定路徑

這是目前官方確認的限制，Cloudflare 文件明確寫道：

Configuration Rules cannot be used to control or disable the tag injection on specific subdomains.

3. 嘗試一：GTM 例外觸發器

思路：在 GTM 裏針對後臺路徑加例外觸發條件，讓 Tag 在 /wp-admin 不執行。

操作：

GTM → 觸發條件 → 新增，條件設為 Page Path 包含 /wp-admin
在每個 Tag 的例外狀況裏加入這個觸發條件
發布容器

結果：無效。

原因：Cloudflare 在 HTML 送達瀏覽器之前就已注入腳本，GTM 的觸發器邏輯根本沒有機會介入，腳本照樣加載、數據照樣送出。

4. 嘗試二：GA4 內部流量過濾

思路：把管理員 IP 標記為內部流量，在 GA4 報告層面過濾掉。

操作：GA4 → 管理 → 定義內部流量 → 輸入辦公室 IP

結果：部分有效，但不治本。

只要換個網絡環境（例如在外面用手機熱點登入後臺），IP 變了，數據還是會被收集進去。

5. 嘗試三：Cloudflare Worker 攔截 HTML

思路：建立一個 Worker，攔截 /wp-admin 的 HTML 響應，用正則表達式移除注入的腳本標籤，再返回給瀏覽器。

Worker 路由設定：

1yourdomain.com/wp-admin*
2yourdomain.com/wp-login*

第一版正則（針對外部 script src）：

1html = html.replace(
2  /<script[^>]*src="[^"]*\/metrics[^"]*"[^>]*><\/script>/gi, ''
3);

結果：無效。

查看頁面原始碼後發現，Cloudflare 注入的是內聯腳本，直接塞在 <html> 開頭，沒有換行，格式如下：

1<html><head><script>(function(w,i,g)...
2'google_tags_first_party'...</script><script>...src='/metrics/'...</script>

第二版正則（針對內聯腳本）：

1html = html.replace(
2  /<script[^>]*>[\s\S]*?google_tags_first_party[\s\S]*?<\/script>/gi, ''
3);

結果：還是無效。

透過 Worker log 診斷發現，響應是 gzip 壓縮格式，response.text() 讀到的是亂碼，正則完全匹配不到任何內容。

第三版（加入 Accept-Encoding: identity 強制不壓縮）：

1const newRequest = new Request(request, {
2  headers: new Headers({
3    ...Object.fromEntries(request.headers),
4    'Accept-Encoding': 'identity',
5  }),
6});

結果：依然無效。

最終透過 log 時序分析，發現了根本原因：Worker 的處理順序在 Google Tag Gateway 注入之前。也就是說：

Worker 移除腳本 → Cloudflare GTG 再次注入腳本 → HTML 送達瀏覽器

Worker 永遠追不上，因為注入發生在 Worker 執行完之後。

6. 理論上可行的方案（未完整驗證）

6.1. 方案 A：在 WordPress 後臺注入攔截腳本

透過 functions.php 的 admin_head hook，在後臺頁面注入一段 JavaScript，在瀏覽器層面攔截所有發往 /metrics/ 的請求：

 1add_action('admin_head', function() {
 2    ?>
 3    <script>
 4    const _fetch = window.fetch;
 5    window.fetch = function(url, ...args) {
 6        if (typeof url === 'string' && url.includes('/metrics/')) {
 7            return Promise.resolve(new Response('', {status: 200}));
 8        }
 9        return _fetch(url, ...args);
10    };
11
12    const observer = new MutationObserver(mutations => {
13        mutations.forEach(mutation => {
14            mutation.addedNodes.forEach(node => {
15                if (node.tagName === 'SCRIPT' && node.src &&
16                    node.src.includes('/metrics/')) {
17                    node.remove();
18                }
19            });
20        });
21    });
22    observer.observe(document.documentElement, {childList: true, subtree: true});
23    </script>
24    <?php
25});

這個方法繞開了 Cloudflare 的注入時序問題，直接在瀏覽器執行層面攔截。

6.2. 方案 B：接受現狀，搭配 GA4 過濾

如果後臺操作量不大，最務實的選擇是：

GA4 設定內部流量過濾（固定 IP 情境下有效）
在 GA4 建立自訂報告時排除 /wp-admin 路徑的流量

7. 結論

Google Tag Gateway 的 Cloudflare 整合目前存在一個設計上的盲點：它在 Zone 層級注入腳本，沒有提供路徑層級的排除機制，導致後臺管理頁面也被追蹤。

這個問題已有不少用戶在 Cloudflare Community 論壇反映，但截至目前官方尚未提供原生解法。

如果你對後臺數據隔離有嚴格要求，在官方修復之前，建議評估是否暫時關閉 Google Tag Gateway（GTM → Admin → Google tag gateway → Delete），改用傳統的前端 GTM 部署方式，等功能支援路徑排除後再重新啓用。

8. 相關資訊

本文記錄於 2026 年 4 月。Cloudflare 與 Google 可能在後續版本中提供官方解法，建議持續關注兩方的更新日誌。