WooCommerce 用 Cloudflare 免費版該避開的 5 個常見錯誤(2026)

Cloudflare 免費版幫 WooCommerce 加速容易踩的五個地雷:Cache Everything 壞掉購物流程、WAF 擋金流 callback、Rocket Loader 干擾頁面互動、Zaraz 重複送事件、以及誤判免費版功能邊界。附 Cache Rules 設定方針與驗證方式,跟上次教的快取排除原則不一樣。

WooCommerce 用 Cloudflare 免費版該避開的 5 個常見錯誤(2026)

你幫 WooCommerce 商店設了 Cloudflare,網站確實變快了,但訂單開始出問題。客人說刷卡成功,後台訂單狀態卻沒更新。購物車內容有時跳到別人身上。加購物車按了沒反應,Elementor 的互動區塊有時正常有時沒反應。你到 Cloudflare 後台翻了一遍,不確定哪個設定才是元凶。

如果你已經看過 WooCommerce 快取的基本排除原則,這篇專門講 Cloudflare 免費版的五個常見錯誤。這些問題跟快取外掛或主機層不同,必須從 Cloudflare 的 Cache Rules、WAF 與腳本載入方式排查。

先說結論

Cloudflare 免費版對 WooCommerce 的定位應該是靜態資源加速器與安全閘道,不是全能快取層。五個最常見的錯誤分別是:

  1. 整站開 Cache Everything,把購物車與結帳流程塞進邊緣快取。
  2. WAF 或 JS Challenge 擋住金流 callback,訂單有付款但沒更新。
  3. 開啟 Rocket Loader 讓 WooCommerce 與 Elementor 的互動功能間歇性失效。
  4. 用 Zaraz 管理追蹤碼卻沒移除 WordPress 端的重複外掛。
  5. 誤判 Cloudflare 免費版的功能邊界,以為 Page Rules 夠用。

下面逐一拆解錯誤的原因、驗證方法與比較保守的設定方式。

錯誤一:整站開 Cache Everything,卻沒排除個人化內容

Cloudflare 的 Cache Everything 模式會把所有請求對應的頁面 HTML 快取到邊緣節點。對純內容網站可能沒問題,對 WooCommerce 卻是災難。

Cloudflare 目前可在 Cache Rules 裡用 Cookie 作為比對條件,將含有 WooCommerce 購物車或 WordPress 登入 Cookie 的請求設為 Bypass。要注意的是,這和「把 Cookie 放進自訂 cache key」不同,後者仍有較高方案限制。若沒有完整測試 Cookie、路徑與查詢參數,整站快取 HTML 仍可能讓購物車、登入狀態或會員內容互相污染。

小型 WooCommerce 最保守的做法,是先不要用 Cache Everything 處理 HTML。CSS、JavaScript、字型與圖片維持 Cloudflare 預設靜態快取,購物車、結帳、會員與金流相關路徑明確設為 Bypass:

路徑Cache Rules 動作Edge TTL
/wp-content/uploads/*依副檔名快取,尊重來源標頭依網站更新頻率
/wp-content/themes/*依副檔名快取,尊重來源標頭依版本化策略
/wp-content/plugins/*依副檔名快取,尊重來源標頭依版本化策略
/wp-includes/*依副檔名快取,尊重來源標頭依版本化策略
/cart/*Bypass Cache不適用
/checkout/*Bypass Cache不適用
/my-account/*Bypass Cache不適用
/?wc-api=*Bypass Cache不適用
/?wc-ajax=*Bypass Cache不適用

Cache Rules 可以同時比對路徑、查詢字串與 Cookie,比舊版 Page Rules 更適合 WooCommerce。依 Cloudflare 2026 年文件,免費方案可建立 10 條 Cache Rules。不要把每個路徑拆成一條;可把同類型購物流程合併成一條邏輯清楚的排除規則。

Cloudflare 官方說明:Cache Rules 設定參考

如果你對 WooCommerce 快取的排除範圍還不熟悉,可以先看這篇:WooCommerce 快取怎麼設?購物車、結帳頁、登入狀態哪些不能快取。那篇講基礎排除原則,這篇補 Cloudflare 特有的陷阱。

錯誤二:WAF 或 Security Level 擋住金流 callback

金流 callback 是 Cloudflare 規則可能影響 WooCommerce 的環節之一,但不能看到訂單沒更新就先怪 Cloudflare。

當客人刷卡完成,金流服務商(綠界、LINE Pay、PayPal)會從伺服器端發送 HTTP POST 到你的 WooCommerce 網站,通知訂單狀態。這是 server-to-server 通訊,不是真人用瀏覽器操作。

問題出在 Cloudflare 的 WAF Custom Rules 或 Security Level 設了 JS Challenge、Managed Challenge 或 I'm Under Attack 模式。Server-to-server 請求不會執行 JavaScript,Challenge 永遠不會通過,金流通知被擋在邊緣,你的 WooCommerce 後台收不到訂單更新。

路徑建議做法
外掛實際 callback 路徑先查 Security Events,再處理命中的規則
WooCommerce REST API保留驗證,只避免互動式 Challenge
第三方 webhook 路徑驗證簽章;來源 IP 穩定時再加 allow 條件

先在 Cloudflare 的 Security Events 檢查付款時間附近是否有 Challenge 或 Block。只有找到明確誤判,才對實際 callback 路徑與必要的安全產品建立最小 Skip。不要把整個 /wp-json/、所有 POST 或整站 WAF 一起放行。

若免費方案的 Bot Fight Mode 誤判合法 callback,要注意它目前不能用 Skip 規則排除。這時應先確認是否真由 Bot Fight Mode 造成,再評估關閉該功能,或改用可以精準控制的 WAF 規則。不要在沒有日誌證據時直接降低全站安全性。

錯誤三:Rocket Loader 讓 WooCommerce 與 Elementor 互動功能壞掉

Rocket Loader 是 Cloudflare Speed 頁面下的最佳化功能。它延遲載入頁面上的 JavaScript,把所有 script 包進統一的非同步載入流程,讓 HTML 解析不被阻塞。

問題在於 Rocket Loader 不保證 JavaScript 的執行順序。WooCommerce 與 Elementor 的大量互動功能依賴特定載入順序:先載入 jQuery、再載入外掛腳本、最後載入頁面初始化程式碼。Rocket Loader 打亂這個順序後會出現:

  • 加購物車按鈕有時有反應有時沒反應。
  • Elementor 的導航選單、分頁、彈出視窗不正常。
  • Mini Cart 顯示數量不更新。
  • 商品篩選與 AJAX 載入不穩定。

這些問題有個共同特徵:重新整理頁面後恢復正常,但下次進來又壞了。問題是間歇性的,很難第一時間聯想到 Rocket Loader。

正確做法是先在 Cloudflare Speed Optimization 關閉 Rocket Loader,再用無痕視窗重測加購物車、篩選與結帳。Brotli 與 HTTP/3 可以保留;Auto Minify 仍要依主題與建構器測試,不能假設所有網站都相容。

錯誤四:用 Zaraz 管理追蹤碼卻沒移除 WordPress 端的重複外掛

Cloudflare Zaraz 是第三方追蹤碼管理層,可以在 Cloudflare 邊緣管理 GA4、Meta Pixel、TikTok Pixel、Google Ads 等追蹤腳本。

Zaraz 的正確用法是:WordPress 只送一套乾淨的電商事件到瀏覽器的 zaraz.ecommerce() API,Cloudflare Zaraz 負責把事件轉發到各廣告平台。

但實際很多 WooCommerce 商店的做法是:Zaraz 設了 GA4 與 Meta Pixel,WordPress 端還裝著 WooCommerce Google Analytics 整合外掛、Facebook for WooCommerce、TikTok 外掛,佈景又手寫了一段 GTM 嵌入碼。

結果是同一筆訂單被 GA4 記了兩次、Meta Pixel 送了兩次轉換事件,廣告報表的轉換數膨脹,ROI 計算失真。

正確做法:

  1. 在 Cloudflare Zaraz 設定 GA4、Meta Pixel、TikTok Pixel 所需工具。
  2. 移除 WordPress 端對應的追蹤碼外掛與手寫嵌入碼。
  3. 在一個功能單純的自訂外掛中加入 zaraz.ecommerce() 事件觸發,不要把追蹤邏輯散在主題的 functions.php
  4. 上線後用 GA4 DebugView、Meta Events Manager 與 TikTok Events 確認事件有正確送達且沒有重複。

Zaraz 的核心價值是集中管理,不是多送一套。WordPress 端的追蹤外掛跟 Zaraz 同時存在,只會增加維護成本與事件重複風險。

如果你需要完整的 WooCommerce 電商追蹤架構指南,可以參考:WooCommerce GA4 電商追蹤設定指南

錯誤五:誤判免費版的功能邊界

這是五個錯誤中最根本的問題。很多人以為 Cloudflare 免費版跟付費版的差別只在流量額度,但對 WooCommerce 營運來說,有幾項關鍵功能差異直接影響你怎麼設定快取與安全規則:

判斷項目2026 年文件顯示對 WooCommerce 的影響
Cache RulesFree 10、Pro 25、Business 50免費版足以做基本路徑與 Cookie bypass
Cookie 條件 bypass可用可排除登入與購物車 Cookie
Cookie 自訂 cache keyEnterprise不要把它和 bypass 規則混為一談
Cache AnalyticsFree 無、付費方案有免費版排查時較依賴 Trace 與回應標頭
WAF Skip可跳過指定產品或規則只處理誤判項目,不要全部跳過

若還在使用舊 Page Rules,可以遷移到 Cache Rules。Cloudflare Trace 能協助確認特定網址到底命中了哪一條規則,會比只看 cf-cache-status 更容易找出衝突。

付費方案與價格會調整,本文不寫死金額。升級前先確認問題是不是規則數量、分析工具或特定安全功能的限制。若瓶頸來自圖片、外掛或主機資源,升級 Cloudflare 方案不會直接解決根因。

現在該做什麼

  1. 關閉 Cache Everything,改用 Cache Rules 只快取靜態資源。
  2. 檢查 Cloudflare WAF Events,確認金流 callback 沒有被 Challenge 擋住。
  3. 到 Cloudflare Speed Optimization 關閉 Rocket Loader。
  4. 如果已經啟用 Zaraz,一併清理 WordPress 端的重複追蹤外掛。
  5. 回頭確認 Cloudflare 免費版的功能邊界,Page Rules 不夠用就轉到 Cache Rules。

如果你不確定目前的 Cloudflare 設定對 WooCommerce 有沒有踩到這些雷,可以使用免費網站健檢工具快速檢查,或加 LINE 與 MO Studio 討論你的商店設定。

如果你還在盤整 WooCommerce 整體的速度策略,可以先看:主機升級 vs CDN vs 快取外掛:WordPress 加速怎麼選。完整的開店流程則可以參考:WooCommerce 教學 2026

常見問題

Cache Everything 已經開了半年沒出過問題,需要改嗎?

A: 目前沒問題不代表未來不會發生。Cache Everything 在訪客量低時不容易觸發快取污染,但隨著商店流量成長,購物車內容錯亂的機率會顯著增加。建議盡快調整成只快取靜態資源的做法。

Cloudflare Cache Rules 免費版有數量限制嗎?

A: 有。Cloudflare 2026 年文件列出的免費方案上限是 10 條。只要把購物流程條件合理合併,通常足以完成基礎排除。方案上限可能調整,上線前仍要查看最新方案表

Rocket Loader 關掉後網站速度會變慢嗎?

A: 對 WooCommerce 來說影響不大。真正影響載入速度的關鍵是圖片壓縮、Brotli 壓縮與靜態資源快取,這三項才是加速主力。Rocket Loader 改善的是 JavaScript 載入的感知時間,代價是互動功能的穩定性。

用 Zaraz 還有必要裝 Google Tag Manager 嗎?

A: 視既有標籤與團隊流程決定。兩者有重疊,但 Zaraz 不一定支援你在 GTM 使用的所有範本與自訂邏輯。遷移前先列出事件與目的地,逐項驗證後再移除舊工具。

金流 callback 被擋會留下記錄嗎?

A: 被 Cloudflare 規則 Challenge 或 Block 時,通常能在 Security Events 找到記錄,但仍受方案保留時間與記錄設定影響。找到命中的規則後,只跳過造成誤判的項目,再用金流測試環境驗證。

官方參考資料


WooCommerce 系列

想把 WooCommerce 開成有品牌感的電商?

從金物流、商品頁到結帳優化 —— 不只是能買,是讓客人想買。

MO DESIGN STUDIO

我們專注品牌網站設計、行銷著陸頁與整合式 CMS 流程,協助團隊打造有感的線上體驗。

← 返回部落格