- 首頁
- 知識庫
- Sharing AI 架站平台教學
- 網站表單被灌垃圾訊息怎麼辦？Cloudflare Turnstile 設定與防護做法
Sharing AI 架站平台教學
網站表單被灌垃圾訊息怎麼辦？Cloudflare Turnstile 設定與防護做法
作者：JamXu更新日期：2026-10-15
表單被灌垃圾訊息，先分辨是自動程式還是真人手動發送。自動程式要靠人機驗證擋下：Sharing AI 架站平台在「設定 → 基本 → 安全性」的「表單送出驗證」支援 Cloudflare Turnstile，到 Cloudflare 免費建立小工具，把網站金鑰與私密金鑰填進後台即可啟用（後台沒有 reCAPTCHA 欄位）。真人發的廣告則要靠欄位設計、留言板篩選與定期清理；設定完成後，一定要用手機和電腦各送出一筆測試。
表單為什麼會被灌垃圾訊息？先分清楚三種來源
只要網站上有一張公開的表單，遲早會收到不是客戶寫的內容：推銷 SEO 服務的廣告、整段外文、看不懂的亂碼，或是附上一串陌生網址的留言。很多人第一個反應是「網站是不是被駭了」，其實多數情況只是表單被自動程式找到了。這些程式會在網路上四處尋找表單，自動填入預先準備好的內容後送出，而且可以在短時間內反覆送出。
在動手設定之前，先分清楚垃圾訊息從哪裡來，因為不同來源要用不同的方法處理。人機驗證擋的是自動程式，擋不住真人手動填寫的廣告，如果一開始就搞錯對象，設定再多也不會改善。
| 來源 | 常見特徵 | 人機驗證擋得住嗎 | 主要對策 |
|---|---|---|---|
| 自動程式（機器人） | 短時間大量送出、內容重複、姓名欄是亂碼、電話欄填英文或網址 | 擋得住大部分 | 啟用 Cloudflare Turnstile，再搭配欄位格式限制 |
| 真人手動推銷 | 內容通順、針對你的產業推銷服務、偶爾出現、留下真的聯絡方式 | 擋不住 | 在留言板標記處理狀態、不回覆、必要時調整表單位置與說明 |
| 惡意或詐騙內容 | 附上縮網址或陌生網址、假冒銀行或平台通知、催促你點連結登入 | 能減少自動大量發送的部分 | 不點連結、不回覆、直接刪除，並提醒負責收信的同事 |
第一種最常見，也是這篇文章的重點。第二種是真人填表推銷，技術上很難和真正的客戶分開。第三種數量不一定多，但風險最高：通知信寄到信箱後，看起來就像一封正式的詢問，負責收信的人只要點錯一個連結，就可能把帳號密碼交出去。
先確認：你的表單真的被灌了嗎？
偶爾收到一兩封推銷信，不一定需要大動作。建議先花十分鐘看清楚現況，再決定要做到什麼程度。Sharing AI 後台右上角的留言圖示會進入留言板，「表單留言」分頁列出所有送出的內容，欄位包含姓名、電話、表單名稱、狀態、從何發送、備註與建立時間，也可以依狀態、從何發送與建立時間篩選。
- 看時間：把留言依建立時間排列，看看是否有同一段時間內密集送出、間隔只有幾秒到幾分鐘的情況。真人填表很少會在凌晨連續送出十幾筆。
- 看內容：比對留言是否大量重複同一段文字、只換了姓名或信箱，或是需求描述欄塞滿網址與關鍵字。
- 看欄位：電話欄填的是英文、姓名欄是一串隨機字母、核取方塊全部被勾選，都是自動程式常見的痕跡。
- 看來源頁：用「從何發送」篩選，確認垃圾訊息集中在哪一個頁面的表單。如果都來自同一頁，代表那張表單已經被找到並鎖定。
- 估算比例：算一下最近兩週真詢問與垃圾訊息各有幾筆。這個數字可以當作設定後的比較基準。
特徵偏向自動程式、而且多到會淹沒真正的詢問，就照後面的步驟啟用人機驗證；若大部分是內容通順的真人推銷，驗證仍值得開，但後面「已經收到的垃圾留言怎麼處理」一節的做法會更有用。
Google 搜尋中心〈避免您的網站和平台使用者產生的垃圾內容〉這份文件列出幾個可以用來辨識濫用的信號，例如表單完成所需的時間、同一個 IP 位址範圍送出的要求數量，以及送出的內容是否有固定模式。一般企業網站不必做到逐筆分析，但這些信號說明了同一件事：垃圾訊息通常有規律，先找出規律，處理起來才有方向。也要分清楚，表單垃圾訊息只會進到後台留言板，不會公開在網站上，和Google 垃圾內容政策所處理的、網站上被植入垃圾內容的情況不同。
Sharing AI 後台能做哪些表單防護？
在介紹設定步驟之前，先把後台實際提供的功能整理清楚。以下依 2026 年 10 月後台的實際畫面整理，功能名稱以後台顯示的文字為準：
| 功能 | 後台位置 | 可以做什麼 | 限制 |
|---|---|---|---|
| 表單送出驗證 | 設定 → 基本 → 安全性 | 填入 Cloudflare Turnstile 的網站金鑰（Site Key）與私密金鑰（Secret Key），為網站表單加上人機驗證 | 只支援 Cloudflare Turnstile，沒有 reCAPTCHA 或其他驗證服務的欄位 |
| 預設欄位 | 表單管理 → 編輯 → 預設欄位 | 姓名、Email、手機可設定顯示或隱藏、選填或必填 | 只決定欄位是否出現與是否必填 |
| 自訂欄位 | 表單管理 → 編輯 → 自訂欄位 | 建立新欄位並選擇欄位類型，例如只能數字、限填英數、單選按鈕、下拉式選單、核取方塊 | 欄位格式能減少亂填，但擋不住真人 |
| 送出後動作 | 表單管理 → 編輯 → 送出後動作 | 送出成功後顯示感謝訊息，或跳轉至指定網址 | 與防護無直接關係，但測試時要確認仍正常 |
| 留言板：表單留言 | 後台右上角留言圖示 | 依狀態、從何發送、建立時間篩選，批量刪除、匯出 Excel、填寫備註 | 沒有自動過濾或封鎖特定來源的功能 |
| 留言板：收件信箱 | 後台右上角留言圖示 | 設定哪些信箱接收哪些表單的通知 | 通過送出的垃圾訊息同樣會寄出通知 |
從這張表可以看出兩件事。第一，人機驗證是網站層級的設定：金鑰填在「網站設定」的安全性分頁，而不是每一張表單各自設定，表單編輯畫面的五個分頁裡也沒有驗證相關的選項。第二，後台目前沒有封鎖 IP 位址、關鍵字過濾或自動判斷垃圾留言的功能，所以人機驗證之外的防護，要靠欄位設計與人工整理。
依平台的官方更新記錄，Cloudflare Turnstile 驗證設定是在 2026 年 4 月加入，用途是加強表單防護。網路上不少教學是以 WordPress 外掛或自行開發的網站為例，說明怎麼安裝 Google reCAPTCHA；在 Sharing AI 架站平台上，請不要照著那些教學把 reCAPTCHA 程式碼貼進網站，原因在後面「Turnstile 和 reCAPTCHA 有什麼不同」一節說明。
Cloudflare Turnstile 是什麼？運作方式與三種模式
一句話說明：Cloudflare Turnstile 是 Cloudflare 提供的人機驗證服務，在訪客的瀏覽器裡執行一連串檢查，判斷對方是不是真人，大多數情況下訪客不需要解謎題、也不必辨認圖片。它的定位是取代傳統要訪客輸入扭曲文字或挑選紅綠燈圖片的驗證碼（CAPTCHA）。
根據 Cloudflare Turnstile 官方說明文件，Turnstile 會先在背景執行一系列不需要互動的 JavaScript 檢查，收集瀏覽器環境與行為的信號，再依每個訪客的情況調整挑戰難度。文件同時說明，Turnstile 只處理提供安全功能所必要的資料，不會存取、儲存或傳送訪客輸入的表單內容。對企業網站來說，這代表訪客填寫的姓名、電話與需求，不會因為加上驗證而交給 Cloudflare。
整個驗證分成兩段：訪客開啟表單時，瀏覽器裡的驗證元件完成檢查並產生一組通行碼（token）；訪客按下送出時，網站伺服器拿這組通行碼向 Cloudflare 確認是否有效，通過才接受這筆留言。在 Sharing AI 架站平台上，依後台的設計，你只需要提供這兩把金鑰，不必自己撰寫程式。
三種驗證模式怎麼選
建立小工具時要選擇驗證模式，差別在訪客看得到什麼、需不需要操作；多數公司網站選 Managed 就好：
| 模式 | 訪客看到什麼 | 需要操作嗎 | 適合情況 |
|---|---|---|---|
| Managed（受管理，官方建議） | 一個小型驗證元件，多數時候自動通過 | 只有在判斷風險較高時，才請訪客勾選一個方塊 | 大多數企業網站的詢問表單 |
| Non-Interactive（非互動） | 驗證元件顯示讀取中的動畫 | 永遠不需要 | 希望完全不打擾訪客，但仍讓訪客知道正在驗證 |
| Invisible（隱形） | 完全看不到驗證元件 | 永遠不需要 | 版面要求極簡，且已在隱私權政策加註 Cloudflare 的說明 |
要特別注意隱形模式的附帶條件：Cloudflare 的文件寫明，啟用隱形模式的網站，必須在自己的隱私權政策中提及 Cloudflare 的 Turnstile 隱私權附錄。如果你選擇隱形模式，記得同步更新網站的隱私權政策，你可以在本站的Cookie 使用政策與隱私權告知設定掌握隱私權政策與頁尾告知的寫法。
費用與限制
Turnstile 有免費方案。依 Cloudflare 的方案說明，免費方案每個帳號最多可以建立 20 個小工具（widget），驗證次數不限，每個小工具最多設定 10 個主機名稱，分析報表可以回看 7 天。一般企業網站只有一個網域、幾張表單，免費方案通常就夠用。
另外一個常見的疑問是：網站一定要把網域交給 Cloudflare 管理嗎？答案是不用。Cloudflare 的入門文件說明，Turnstile 可以用在任何網站，不論網站流量是否經過 Cloudflare 網路。你只需要一個 Cloudflare 帳號來建立小工具與取得金鑰，網域的 DNS 設定完全不必更動。如果你的網域本來就放在 Cloudflare，DNS 記錄的代理狀態也和 Turnstile 無關；代理開啟或關閉的差別，在自有網域綁定與 DNS 設定有專節說明。
設定步驟一：在 Cloudflare 建立 Turnstile 小工具
整個設定分成兩邊：先在 Cloudflare 建立小工具、取得兩把金鑰，再把金鑰填進 Sharing AI 後台。下面是第一步的流程，以 Cloudflare 後台的英文介面名稱說明；如果你的 Cloudflare 介面切換成中文，按鈕名稱可能略有不同，但順序相同。
- 準備公司的 Cloudflare 帳號：用公司共用的信箱註冊或登入 Cloudflare，不要用某位同事或外包廠商的私人帳號，日後人員異動時才不會失去管理權。
- 進入 Turnstile 頁面：登入後進入 Cloudflare 後台的 Turnstile 頁面，選擇「Add widget」新增小工具。
- 填寫小工具名稱：取一個看得出用途的名稱，例如「公司官網－詢問表單」。Cloudflare 建議依用途命名，日後有多個網站或多個小工具時比較好管理。
- 設定主機名稱：在 Hostname Management 加入網站使用的網域，例如 example.com。填法與注意事項請看下一個小節。
- 選擇驗證模式：一般選 Managed。若選 Invisible，記得同步更新隱私權政策。
- 建立並複製金鑰：按下 Create 後，畫面會顯示網站金鑰（Sitekey）與私密金鑰（Secret key）。先把網站金鑰複製下來，私密金鑰則在下一步直接貼進後台，不要另外存在聊天群組或一般文件裡。
私密金鑰等同於驗證服務的密碼，外洩後別人可以拿你的設定去驗證其他網站的請求，或讓你的設定失效。只有負責設定的人需要看到它，建立完成後若要交接，請直接在 Cloudflare 後台把對方加入帳號或重新產生金鑰，而不是把金鑰文字傳來傳去。
主機名稱怎麼填
主機名稱決定這個小工具可以在哪些網站上運作，填錯是設定後驗證失敗最常見的原因。依 Cloudflare 的主機名稱管理說明，每個小工具至少要設定一個主機名稱；主機名稱只能填完整網域，不能加上 https://、連接埠或路徑，也不支援星號萬用字元。好消息是，加入一個網域會自動涵蓋它底下所有子網域。
| 填入的主機名稱 | 可以運作的網址 | 不能運作的網址 | 說明 |
|---|---|---|---|
| example.com | example.com、www.example.com、shop.example.com | 其他網域 | 最常用的填法，主網域與所有子網域都涵蓋 |
| www.example.com | www.example.com 與它底下的子網域 | example.com（沒有 www）、其他子網域 | 範圍較窄，網站兩種網址都會用時容易出錯 |
| https://example.com | 無法儲存 | — | 不能包含 https:// 等通訊協定 |
| example.com/contact | 無法儲存 | — | 不能包含路徑，驗證範圍是整個網域 |
實務上，填入網站的主網域（不含 www）最省事。如果網站有多個網域都會開啟同一張表單，例如品牌網域和舊網域並存，要把每個網域都加進去；免費方案每個小工具最多 10 個主機名稱。網站還在測試網址、尚未綁定正式網域時，也要確認測試網址是否在清單內，否則測試時就會看到驗證失敗。日後如果要換網域，記得把「更新 Turnstile 主機名稱」加進網站搬家的檢查清單。
設定步驟二：把金鑰填進 Sharing AI 後台
拿到兩把金鑰後，回到 Sharing AI 後台完成啟用。這一步只需要網站管理權限，不需要修改任何程式碼。
- 開啟網站設定：在後台左側選單點選「設定」底下的「基本」，進入「網站設定」頁面，上方有基本設定、進階設定、安全性、網域四個分頁。
- 切換到安全性分頁：點選「安全性」，會看到「表單送出驗證」區塊，裡面有「Cloudflare Turnstile 網站金鑰 (Site Key)」與「Cloudflare Turnstile 私密金鑰 (Secret Key)」兩個欄位。
- 貼上網站金鑰：把 Cloudflare 的 Sitekey 貼到網站金鑰欄位。前後不要多出空白或換行。
- 貼上私密金鑰：把 Secret key 貼到私密金鑰欄位。這個欄位會以遮蔽的方式顯示，貼上後看不到內容是正常的。
- 儲存：按下「儲存」，等畫面顯示儲存完成後，再進行下一節的測試。
這裡有兩個容易出錯的地方。第一，網站金鑰和私密金鑰不要貼反：網站金鑰是公開的，會出現在網站前台；私密金鑰只給伺服器使用。兩者都是一長串英數字，貼反了驗證一定失敗。第二，兩把金鑰必須來自同一個 Cloudflare 小工具，如果你建立過不只一個小工具，複製時要確認名稱相同。
因為這項設定位於網站層級，而不是個別表單，儲存之後請把網站上每一張表單都測一次。如果網站上有好幾張表單，例如公司網站首頁底部的「立即填表」、聯絡頁的詢問表單，以及活動頁上的報名表，測試時要每一張都送一次，不要只測其中一張。
設定完一定要測：上線前後的驗證清單
人機驗證最怕的不是擋不住機器人，而是「把真正的客戶擋在門外，自己卻不知道」。訪客遇到驗證失敗，多半不會打電話來告訴你，而是直接離開。所以設定完成後，一定要用真實的手機與電腦各送出一次表單，確認整條流程走得通；網站還沒上線的話，這份清單可以併入網站上線前檢查清單一起執行。
- 用電腦瀏覽器開啟每一張有表單的頁面，確認表單仍正常顯示，送出後出現感謝訊息或跳轉到感謝頁
- 用手機的行動網路（不要連公司 Wi-Fi）再送一次，確認手機版沒有版面跑掉或按鈕無法按的情況
- 到後台留言板確認兩筆測試留言都有出現，「從何發送」顯示的頁面正確
- 確認收件信箱設定的負責人有收到通知信，並且沒有落到垃圾郵件分類
- 測試完成後，把測試留言的狀態改為已處理或刪除，避免日後統計時混在一起
- 一兩天後再看一次留言板，比較垃圾訊息的數量是否下降
測試時如果出現錯誤，可以對照下表找原因。這些錯誤情況整理自 Cloudflare 對小工具狀態與通行碼的說明：通行碼產生後 300 秒（5 分鐘）內有效，而且每組只能使用一次，所以訪客打開表單後隔太久才送出，驗證可能已經過期，需要重新整理頁面。
| 狀況 | 可能原因 | 處理方式 |
|---|---|---|
| 驗證元件顯示錯誤，所有人都無法送出 | 主機名稱沒有包含目前的網域，或兩把金鑰不是同一個小工具 | 到 Cloudflare 檢查主機名稱清單，重新複製兩把金鑰貼上後儲存 |
| 送出後顯示失敗，但驗證元件看起來正常 | 私密金鑰貼錯、多了空白，或與網站金鑰貼反 | 重新貼上私密金鑰；仍失敗就在 Cloudflare 重新產生後再設定 |
| 少數訪客反映無法送出 | 開啟頁面太久才送出、通行碼過期，或使用過舊、不支援的瀏覽器 | 請訪客重新整理頁面再送出，或建議更新瀏覽器；同時在頁面上保留電話或 Email 等其他聯絡方式 |
| 垃圾訊息沒有減少 | 垃圾訊息主要來自真人手動填寫，或驗證尚未生效 | 回到留言板確認特徵；若是真人推銷，改用後面幾節的欄位設計與清理方法 |
| 電腦正常，手機版看不到驗證元件 | 使用隱形模式（本來就看不到），或頁面還在讀取 | 確認選用的模式；隱形模式看不到元件是正常的，以能否送出為準 |
不論哪一種狀況，都建議在聯絡頁同時保留電話、Email 或 LINE 等其他聯絡管道，萬一驗證暫時出問題，客戶還有別的方法找到你。這些聯絡按鈕要放在哪裡、文案怎麼寫，網站 CTA 按鈕設計整理了完整的擺放原則。
Turnstile 和 reCAPTCHA 有什麼不同？
很多人聽過的是 Google reCAPTCHA，網路上的表單防護教學也大多以它為例，所以常有人問：「可以改用 reCAPTCHA 嗎？」先說結論：在 Sharing AI 架站平台上，表單送出驗證只支援 Cloudflare Turnstile，後台沒有填寫 reCAPTCHA 金鑰的地方。兩者的目的相同，都是區分真人與自動程式，以下是主要差異：
| 比較項目 | Cloudflare Turnstile | Google reCAPTCHA |
|---|---|---|
| 提供者 | Cloudflare | Google（現已整合進 Google Cloud Fraud Defense） |
| 訪客體驗 | 多數情況自動通過；受管理模式在風險較高時請訪客勾選方塊，不出現辨認圖片或文字的題目 | v3 不需互動、以分數判斷；v2 為「我不是機器人」勾選框，或在按下按鈕時觸發的隱形驗證，可疑時可能出現驗證題目 |
| 費用 | 免費方案驗證次數不限 | reCAPTCHA Essentials 每月前 10,000 次評估免費，需要在 Google Cloud 設定有效的付款方式，超過後依用量計費 |
| 帳號需求 | Cloudflare 帳號，不必把網站流量經過 Cloudflare | Google Cloud 專案 |
| 在 Sharing AI 後台設定 | 可以：設定 → 基本 → 安全性 | 後台沒有對應欄位 |
表格中 reCAPTCHA 的類型整理自 Google 的 reCAPTCHA 說明文件，費用則依 Google Cloud 的方案說明；要注意的是，每月 10,000 次的免費額度以整個機構計算，會合併所有帳號與網站的用量。
為什麼不要自己貼 reCAPTCHA 程式碼
有些人會想：後台的行銷代碼或自由設計區塊可以放程式碼，那把 reCAPTCHA 的程式貼進去不就好了？問題在於人機驗證一定要有「伺服器端確認」這一步。不論是 Turnstile 還是 reCAPTCHA，前台的驗證元件只負責產生通行碼，真正決定要不要接受這筆留言的，是網站伺服器拿通行碼回去確認的那一步。Cloudflare 的文件把話說得很直接：沒有在伺服器端確認通行碼，整個設定就不算完成，會留下重大漏洞。
後台沒有地方填寫 reCAPTCHA 的私密金鑰，平台處理表單送出時也就無從向 Google 確認結果，自己貼進頁面的 reCAPTCHA 只會在畫面上多一個勾選框，自動程式仍然可以直接把資料送進表單，等於沒有防護，還可能讓真正的訪客多一道麻煩。行銷代碼欄位應該用來安裝 GA4、GTM 等追蹤工具，網站行銷代碼安裝教學逐項說明了這些代碼該填在哪裡。
驗證之外：用表單設計減少垃圾訊息
人機驗證能擋下大部分自動程式，但對真人推銷沒有作用，對設計比較進階的自動程式也不保證百分之百有效。比較穩健的做法是多加幾層小防線，讓亂填的內容更容易被看出來，也讓真正的客戶填得更順。欄位取捨的完整原則在網站表單設計教學已經說明，這裡只整理和垃圾訊息有關的部分。
- 電話欄位改用「只能數字」類型：自動程式常在電話欄塞英文或網址，限制格式後這類內容就送不出去。
- 能用選項就不要用文字框：「想了解的服務」用核取方塊或下拉式選單，比開放文字框更不容易被塞進廣告文字，也方便你分類詢問。
- 只保留一個開放文字欄：需求描述留一個欄位就好，開放文字欄越多，被塞廣告的空間越大。
- 必填欄位不要太多：必填只留回覆所必需的資訊。為了擋垃圾訊息而把每一欄都設成必填，最先被擋下的往往是真正的客戶。
- 表單標題與說明寫清楚用途：例如「服務詢問，我們會在一個工作天內回覆」，讓推銷者知道這裡不是收廣告的地方，也讓客戶知道送出後會發生什麼事。
還有一個常被忽略的入口：網站上公開的 Email 地址。把信箱直接寫在頁尾或聯絡頁，同樣會被程式蒐集去寄垃圾信，而且這部分人機驗證完全管不到。建議對外公開專用的服務信箱，而不是負責人的個人信箱；公司網域信箱的寄信驗證與避免進垃圾信的設定，在公司網域信箱設定中有逐步說明。
已經收到的垃圾留言怎麼處理？
啟用驗證之前已經收到的垃圾留言，不會因為設定而自動消失；即使設定之後，也可能偶爾有漏網之魚。原則是：不點、不回、不轉寄，並把真正的詢問留下來。
- 先篩選：在留言板用建立時間與「從何發送」篩選出垃圾訊息集中的區段，逐筆確認。
- 保留真詢問：把看起來像真正客戶的留言先處理或改為已處理狀態，必要時在備註寫下判斷，避免誤刪。
- 批量刪除：確認是垃圾訊息後，用「批量刪除」一次清除，不必一筆一筆刪。
- 需要留存時再匯出：如果想保留一段時間的紀錄作為比較，可以先「匯出 Excel」，但匯出的檔案也包含真實客戶的聯絡資料，要存放在有權限控管的地方，用完即刪。
- 記錄數量：每週記一次垃圾訊息與真詢問的筆數，觀察設定前後的變化。
處理時最重要的安全原則：不要點擊垃圾留言裡的任何連結，也不要用留言中的聯絡方式回覆。回覆只會確認這個信箱或表單有人在看，引來更多垃圾訊息；連結則可能導向假冒的登入頁面或惡意網站。這個提醒也要讓負責收通知信的同事知道，因為通知信看起來和一般客戶來信幾乎一樣。
留言板之外，還能從 Cloudflare 看到什麼
啟用 Turnstile 之後，Cloudflare 後台會提供這個小工具的分析報表，包括驗證的通過率、驗證次數，以及依主機名稱、國家、瀏覽器、作業系統與來源 IP 位址等維度的統計；免費方案可以回看 7 天。平台的留言板不會顯示訪客的 IP 位址，所以想知道垃圾流量是否集中在特定來源，Cloudflare 的報表是比較直接的觀察管道。至於真人訪客填表時卡在哪一欄，則可以用Microsoft Clarity 的熱圖與工作階段錄製觀察。
長期維護：金鑰管理與每月檢查
| 頻率 | 檢查項目 | 發現問題時 |
|---|---|---|
| 每週 | 留言板中垃圾訊息與真詢問的比例 | 垃圾訊息明顯增加時，看 Cloudflare 報表並檢查驗證是否仍有效 |
| 每月 | 用手機與電腦各送出一筆測試表單，確認留言與通知都正常 | 依前面的狀況表排查 |
| 每月 | 確認收件信箱的負責人仍在職、信箱仍有人看 | 更新留言板的收件信箱設定 |
| 人員異動時 | 確認 Cloudflare 帳號、Sharing AI 後台的管理權限都在公司手上 | 移除離職人員權限，必要時重新產生私密金鑰 |
| 網域變更時 | 新網域是否已加入 Turnstile 的主機名稱清單 | 先加入主機名稱，再切換網域，避免表單驗證中斷 |
金鑰管理有一個實用的知識：Cloudflare 提供更換私密金鑰的功能，在小工具的設定中選擇重新產生私密金鑰（Rotate Secret Key）後，新舊兩把私密金鑰會在兩個小時內同時有效，讓你有時間把後台的私密金鑰換成新的，而不會中斷表單驗證。換好之後記得再送出一筆測試。
另一個常見的風險是帳號歸屬：Cloudflare 帳號若是外包廠商或某位同事的私人信箱，合作結束或人員離職後就沒人能修改主機名稱或更換金鑰。建議設定當天就確認帳號使用公司共用信箱、至少兩位內部人員能登入，並把「哪個小工具用在哪個網站」記在網站管理文件中。
常見錯誤與正確做法
| 常見錯誤 | 會造成的問題 | 比較好的做法 |
|---|---|---|
| 只在前台貼上驗證程式碼 | 沒有伺服器端確認，自動程式照樣能送出 | 使用後台安全性分頁的 Cloudflare Turnstile 設定 |
| 主機名稱填成 https://網址或加上路徑 | 無法儲存，或驗證在正式網址失敗 | 只填網域，例如 example.com |
| 網站金鑰與私密金鑰貼反 | 所有表單都無法送出 | 對照欄位名稱重新貼上，並實際測試 |
| 設定後沒有測試 | 真正的客戶送不出表單，卻沒人發現 | 手機與電腦各送一筆，確認留言與通知都正常 |
| 用私人帳號建立 Cloudflare 小工具 | 人員異動後無法管理 | 使用公司共用信箱，並記錄在網站管理文件 |
| 把所有欄位設成必填來擋垃圾訊息 | 真正的客戶嫌麻煩而離開 | 只把回覆必需的欄位設為必填，搭配欄位格式 |
| 點開垃圾留言裡的連結查看 | 可能進入假冒登入頁或惡意網站 | 不點、不回，直接刪除 |
| 選用隱形模式卻沒更新隱私權政策 | 不符合 Cloudflare 的使用條件 | 在隱私權政策加入 Turnstile 隱私權附錄的說明 |
前三項都是「以為設定好了，其實沒有生效」，所以效果要用留言板的數字確認，而不是以畫面顯示儲存成功為準。
下一步：今天就能完成的三件事
把整篇濃縮成三件事：先到留言板看清楚垃圾訊息的特徵與數量；再用公司帳號建立 Turnstile 小工具（主機名稱填主網域、模式選 Managed），把兩把金鑰填進「設定 → 基本 → 安全性」並實際測試；最後調整欄位格式、清理舊留言，並每週記錄數量。
如果你還在規劃網站上的表單與聯絡流程，可以從Sharing AI 架站平台教學主題頁看後台各項功能的總覽；想了解平台方案，可以從 Sharing AI 架站平台開始。若希望由專業團隊協助檢查表單設定與整體詢問流程，也歡迎直接與我們聯絡。