如何移除網址中的 Facebook、Google 追蹤參數 fbclid 與 gclid

多數人可能沒注意到，但 Facebook 從 2018 年就開始在貼文分享的連結上加入 fbclid 參數，而 Google (adwords) 則是針對來自廣告流量的連結直接加上了 gclid 參數，雖然最終訪客都可以順利到達我們的網站，但實際上這些追蹤參數卻會對網站造成影響。

在這篇文章中，我們會與大家分享：

• 這類追蹤參數對網站所造成的影響有哪些？
• 有什麼方法可以移除網址中多餘的追蹤參數？

額外追蹤參數的影響

網站數據分析不直觀

首先，如果有使用 Google Analytics (GA) 統計分析網站流量，在 GA 的儀表板上查看頁面瀏覽數據時，可以注意到即使是同一篇文章/頁面的瀏覽量，表格中卻出現了大量紀錄，而網址後方則帶著包含 ?fbclid=、?gclid= 看似亂碼的編碼所構成的追蹤參數。

這讓使用 GA 的站長們在查看統計數據時相當困擾，無法直觀的看出每一個網址的「統計」數據，必須後製加工處理才能取得直觀、能夠用來分析的數據。

在 GA4 問世之前，尚可透過管理設定中的 Exclude URL Query Parameter 功能將 fbclid、gclid 等參數排除；然而，GA4 並不具備這樣的功能，曾經可以運用 GTM 中的 Trim Query 移除查詢參數功能進行設定，現在只能自訂 JavaScript 函數才能達成。

這對一般架站者而言，使用 GA 進行網站分析成為更加遙不可及的目標了。

請參閱 Google Analytics 4 中排除網址查詢參數、How To Exclude URL Query Parameters in Google Analytics。

所幸，還是有其他網站分析工具在展示統計數據時會事先對這些追蹤參數進行處理，不僅能正確反映文章、頁面的統計數據，也同時保留了參照來源讓我們能夠清楚知道這些頁面流量來自何處。

網站分析最重要的是直觀，能夠為管理者帶來洞見，進而知道該如何微調頁面上的設計來達成行銷推廣的目標。

網站分析工具 – Quants Note

影響頁面載入效能

即使我們解決了 GA4 統計數據的問題，這些看似亂數的追蹤參數依然會造成網站頁面載入的效能問題。

雖然與網站效能有關，但這並不是因為網站設定、調校的問題所造成的，而是當訪客透過這些帶有額外追蹤參數訪問網站時，無法觸及主機或 CDN 上已經準備好的快取資源，使得每一次訪問都需要從主機直接存取頁面資源，因而影響頁面載入速度。

尷尬的是，會產生這類追蹤參數的 Google，在其 Google Search Console 服務中也會將「網站使用體驗核心指標」表現不加的相關數據納入考量，進而影響網站的搜尋排名。

移除追蹤參數 fbclid、gclid

為了解決上面提到的問題，我們可以透過轉址，或是使用 Cloudflare 快取等級 (Caching Levels) 來避免追蹤參數所造成的問題。

• 轉址 – 設定轉向規則，在轉址過程中將相關參數移除
• Cloudflare 快取等級 – 忽略查詢字串，對所有訪客傳遞原始網頁的快取資源

轉址 – .htaccess 轉向規則

如果網頁伺服器是 Apache 或 Lite Speed (OLS)：

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{QUERY_STRING} "^(.*)&?fbclid=[^&]+&?(.*)$" [NC]
  RewriteRule ^(.*)$ /$1?%1%2 [R=301,L]
</IfModule>

將這段轉址規則放在 .htaccess 設定檔的最開頭，可單純移除網址中的 fbclid 參數部分，不會影響其他查詢/追蹤參數。

如果想要考慮更複雜的應用情景，可以參考這篇文章中的說明。

轉址 – WordPress 外掛

由於直接修改主機上的設定檔需要更進階的知識，建議一般管理者可以使用 Redirection 外掛，或是 SEO 外掛，例如 RankMath SEO、Yoast 提供的轉址功能。

這樣就不需要自行維護主機上的規則設定檔，也不需要具備撰寫 .htaccess 或 nginx.conf 轉向規則的知識了。

如果是有提供進階的轉址規則功能的外掛，使用 Regex 正規表達式就能將帶有 fbclid、gclid 參數的網址轉址到原始網址而毋須按單一網址一一設定。

• 來源 URL：^(.*?)(&?fbclid=[a-zA-Z0-9_-]+)$
• 目標 URL：$1

此外，也可以參考 Remove Social ID for WP 外掛，這是開發者專門為了移除 fbclid、gclid 參數而寫的外掛。

Cloudflare 快取設定

如果有使用 Cloudflare 託管網域的 DNS 並使用其 Proxy 功能，可以將 Cloudflare 的快取等級設定為「忽略查詢字串 Ignore Query String」，這樣一來，在 CDN 的快取層級不管訪客使用的網址帶有什麼查詢字串，都會向訪客傳遞快取/最佳化資源。

除此之外，我們依然可以保留訪客完整的訪問網址資料。

結語

透過上述說明，我們知道 Facebook 與 Google 在連結上加入的 fbclid、gclid 追蹤參數對網站分析、網站效能的負面影響。

為了解決這類追蹤參數所造成的問題，我們可以使用轉向、轉址規則移除追蹤參數，這樣一來就能讓訪客存取到網頁的快取/最佳化版本。

我們因為後來使用網站分析工具進行網站瀏覽數據的統計分析，能夠保留完整的訪客瀏覽路徑紀錄，進行完整的目標歸因分析，了解頁面上目標達成的源頭是來自於臉書廣告、Google 廣告或社群分享，所以沒有一般 GA 使用者面臨的困擾。

網站效能的部分，過去確實也曾遭遇來自 Facebook 流量所造成的「網站使用者體驗不佳」問題，但在使用 Cloudflare 的快取功能，將快取等級設定為忽略查詢字串之後，訪客就能確實的觸及到頁面的快取版本，大幅提升使用體驗。

如果您也有遭遇到這方面的問題，不妨可以試試上述建議的方法，有任何問題，也歡迎填寫聯絡表單與我直接討論，或是加入我們的臉書社團、Discord 社團一起討論唷！

後記

這篇文章在社團分享之後，勇哥也分享了他的經驗，「有下大量廣告和活動的高流量網站的站長，要把這一篇收藏好」、「可能 90% 的網站設計公司、行銷公司、工作室或網站代管工程師，都不知道這個問題。被 Facebook 虐過都不知道原因」，如果沒有事先做好準備，不管網站快取外掛有多厲害，很容易就把主機、資料庫給打掛了。

勇哥也分享了常見的參數有：

• Facebook：/?fbclid=
• Google：/?gclid=
• 美安：/?RID=&Click_ID=
• UTM：/?utm_source=
• LINE：/?openExternalBrowser=1

當然，如果你有下 Google 廣告，可能還會看到 gad_source、gbraid，其他平台的廣告也會有相關的追蹤參數，所以對於商業使用的網站來說，有個能夠應對「所有追蹤參數」的解決方案會是最好的。

此外，阿力獅也很快地完成了 Remove Social ID for WP 外掛的繁體中文本地化，台灣的 WordPress 自架站者們可以更輕鬆自在的使用這個外掛了！

謝謝勇哥與阿力獅 ^_____^