2018 年歐盟《一般資料保護規則》（GDPR）正式生效後，Cookie 同意聲明一夕間從「加分項目」變成「必要基礎建設」。台灣《個人資料保護法》雖然起步較晚，但隨著主管機關陸續公告細則，以及瀏覽器廠商逐步收緊第三方 Cookie 的存取限制，本地站長已無法再以「台灣法規寬鬆」為由拖延處理。

問題在於，市面上標榜合規的外掛超過十款，設定介面各有一套邏輯，同一個「封鎖模式」在不同外掛裡代表的行為可能截然不同。選錯外掛或設錯模式，輕則 Google Analytics 資料出現缺口、廣告追蹤失效，重則在歐盟監管機構的掃描工具下現出原形。

這篇文章聚焦兩款主流的 WordPress cookie 同意外掛——CookieYes 與 Complianz，分別說明封鎖模式的差異、同意紀錄的保存機制，以及多語系版本的設定方式，協助站長以最小幅度的改動達到可辯護的合規狀態。

封鎖模式決定 Cookie 何時執行

多數站長第一次安裝同意外掛時，都傾向選「寬鬆模式」，讓訪客先看到橫幅通知，但不阻擋任何追蹤指令碼的執行。這種做法在 2020 年前或許勉強符合部分解釋，但 GDPR 第 7 條已明確要求「積極、明確的同意行為先於資料蒐集」，寬鬆模式在法律上站不住腳。

封鎖模式的邏輯恰好相反，所有需要同意的 Cookie 類別（分析、行銷、個人化）預設一律封鎖，待訪客在橫幅上主動選擇後，才觸發對應的指令碼。對站長而言，這個模式的代價是：Google Analytics 初次載入會有延遲，加上少數訪客永遠拒絕所有非必要 Cookie，導致資料樣本略微縮減。這是法規要求的必然取捨，而非外掛的設計缺陷。

CookieYes 的封鎖模式設定

CookieYes 將封鎖模式稱為「Cookie 封鎖」，設定路徑在後台左選單「CookieYes」→「封鎖」→「自動封鎖」。預設狀態下，外掛會掃描頁面上的 <script> 標籤，並對照自帶的指令碼資料庫，自動將已知的追蹤指令碼（如 Google Tag Manager、Meta Pixel）標記為「受管制」。

需要留意兩個細節。自訂指令碼（例如自行嵌入的 HotJar 代碼）必須在「自訂指令碼」分頁手動新增並指定分類；若略過這個步驟，該指令碼會在取得同意前就執行，形成實際上的合規缺口。另外，「指令碼管理員」模式與「自動封鎖」模式不能同時啟用——前者讓站長逐條控制，後者全自動掃描，混用會造成部分指令碼雙重封鎖或完全略過。

Complianz 的封鎖模式設定

Complianz 的設定入口在「Complianz」→「設定」→「Cookie 掃描」，封鎖模式稱為「指令碼中心（Script Center）」。與 CookieYes 不同，Complianz 要求站長先跑一次完整的 Cookie 掃描，系統才會根據掃描結果自動產生每個指令碼的分類建議，再由站長逐一確認。

這種「掃描先行」的設計有一個實際好處。掃描完成後，Complianz 會輸出一份 Cookie 政策文件，內含所有偵測到的 Cookie 名稱、存活時間與目的描述，可直接嵌入隱私政策頁面。代價是每次新增外掛或修改頁面結構後，都需要重新執行掃描；若未更新，政策文件與實際執行的指令碼之間會出現落差，反而成為稽核時的把柄。

同意紀錄是合規的核心憑證

GDPR 要求資料控管者能舉證「已取得同意」，這份舉證責任在 Cookie 管理上落到了同意日誌（Consent Log）。同意日誌記錄的不只是「訪客點了接受」，還包括時間戳記、同意版本（對應當時的 Cookie 政策版本）、選擇的同意類別，以及用來識別裝置的匿名識別碼。

台灣個資法第 7 條同樣要求「特定同意」，雖然主管機關對 Cookie 同意的稽查強度目前低於歐盟，但法條文字已具備追責基礎。對於有歐盟訪客流量的台灣站台，或計畫拓展海外市場的中小企業，同意日誌是唯一能在爭議發生時自清的文件。

CookieYes 的同意紀錄保存

CookieYes 在後台「分析」頁面提供同意日誌下載，格式為 CSV，欄位包含訪客 ID（雜湊值，非個人資料）、時間戳記、同意狀態（接受全部／拒絕全部／部分接受）、政策版本號。免費方案保留 30 天記錄；付費方案的保留期間可延長至 12 個月，符合 GDPR 對「三年內可提供舉證」的建議最低紀錄期。

一個常見的疏漏，是在更新 Cookie 政策後忘記遞增版本號。CookieYes 的日誌以政策版本為索引，若版本號未更新，新舊政策下取得的同意會混入同一個版本底下，稽查時便無法區分哪份同意是在更新後取得的。正確做法是每次修改 Cookie 分類或政策文字後，至「設定」→「橫幅」的版本號欄位手動遞增。

Complianz 的同意紀錄保存

Complianz 的同意日誌路徑在「統計」→「同意日誌」，同樣可匯出 CSV。與 CookieYes 最大的差異在於，Complianz 預設將同意日誌儲存在 WordPress 資料庫的獨立資料表（wp_cmplz_consents），資料本身不離開伺服器，對於資料主權有顧慮的站台而言是一項優勢。

版本管理機制方面，Complianz 相對自動化。每次透過後台介面修改 Cookie 政策文字並儲存，系統會自動產生新的版本快照，無需手動遞增。但須特別留意「靜默更新」的情況，若站長直接修改 Cookie 政策頁面的 WordPress 文章內容（繞過 Complianz 的介面），版本快照不會更新，等同於讓文件與日誌脫鉤。

多語系版本是跨境流量的必要配置

單一語系橫幅對跨境流量的站台而言是法規缺口。GDPR 第 12 條要求同意聲明以「清楚易懂的語言」呈現，實務上被解釋為以訪客的慣用語言顯示。台灣個資法雖無明文語言要求，但若站台同時有繁體中文與英語兩個語系版本，橫幅卻只有中文，在資訊揭露上屬於不一致。

實際影響不只在法規層面。橫幅語言與頁面語言不一致，會讓訪客對「這個通知是不是搞錯了」產生疑惑，拒絕率明顯高於同語系呈現的情境。提高同意接受率，也直接影響分析資料的完整性。

CookieYes 的多語系設定

CookieYes 的多語系橫幅設定在「橫幅」→「翻譯」頁籤。外掛內建超過 30 種語言的預設譯文，站長可逐欄位覆寫。若站台使用 WPML 或 Polylang 這類多語系外掛，CookieYes 能偵測當前頁面語系並自動切換對應橫幅文字，無需為每個語系建立獨立橫幅設定。

需要確認的是「法律依據」欄位的翻譯。CookieYes 的 GDPR 模式下，橫幅底部預設會顯示一段法律依據說明文字，這段文字在各語系版本必須語意一致。不只是機器翻譯，還要確認法律術語的慣用表達（例如英文「legitimate interest」在德文合規語境中有對應的標準詞彙）。對於流量以英文與中文為主的台灣站台，這兩個語系仔細核對一遍，通常就已足夠。

Complianz 的多語系設定

Complianz 的多語系支援需要搭配 WPML 或 Polylang，不支援單純依瀏覽器語言偵測自動切換。設定路徑在「設定」→「整合」，啟用對應的多語系外掛整合後，Complianz 會在 Cookie 政策頁面與橫幅文字都套用對應語系。

Complianz 有一個設計特點，Cookie 政策頁面本身就是一個 WordPress 頁面，多語系翻譯走 WPML／Polylang 的標準頁面翻譯流程，站長可用熟悉的編輯器處理，不需要學習另一套介面。代價是頁面翻譯版本需要手動維護。若原始語系的 Cookie 政策更新，翻譯版本不會自動同步，站長必須自行建立更新檢查流程。

CookieYes 與 Complianz 的選型對照

兩款外掛在核心合規功能上旗鼓相當，差異主要在操作邏輯與適用場景。

選型的判斷邏輯相當直接。若資料主權是優先考量（自架主機、資料不出境），Complianz 是合理的預設選擇；若站台需要快速部署合規且願意接受外部日誌儲存，CookieYes 的設定流程更短。兩者在 GDPR 與台灣個資法的核心要求上都能達標，差異在維運習慣而非合規能力本身。

實作前的三項準備工作

不論選用哪款外掛，有三項基礎工作若未完成，外掛再怎麼設定都會留下缺口。

既有指令碼清單：安裝外掛前，先列出頁面上所有嵌入的第三方指令碼，包括 Google Analytics、廣告追蹤像素、熱圖工具、線上客服元件。這份清單是外掛封鎖設定的輸入來源，遺漏一個就等於少封鎖一個。

隱私政策頁面：外掛提供的 Cookie 政策需要一個對應的 WordPress 頁面，且該頁面需要列在橫幅的說明連結中。台灣個資法第 18 條要求告知蒐集目的，若隱私政策頁面不存在或連結失效，橫幅本身的告知義務就不完整。

定期更新排程：Cookie 政策並非設定一次便永久有效，每次引入新的第三方服務、更換廣告平台、升級分析工具，都需要重新掃描並更新政策版本。建立每季度一次的例行檢查，比等到外掛發出「偵測到新 Cookie」通知才應對，在法規舉證上更站得住腳。