Contact Form 7 設定重點：欄位、寄信與追蹤

這篇要解決的事（先給答案）

你大概是這樣找到這篇的：WordPress 後台裝了一堆外掛，發現每個網站都需要一張「聯絡我們」表單，然後你聽過無數次 Contact Form 7 這個名字，卻一直沒有真的把它設定到位。或者你已經裝好了，信卻寄不到、垃圾信滿天飛、手機上看起來歪歪的。

我直接把答案講在前面：Contact Form 7 是一款免費的 WordPress 表單外掛，由 Takayuki Miyoshi 維護。它提供表單標籤、郵件設定與多種整合介面，適合願意自行調整欄位、樣式與寄信流程的人（見 Contact Form 7 官方網站）。

但要把它的價值發揮出來，你真正要搞懂的不是「怎麼按建立按鈕」，而是三件容易被忘記的事：欄位策略、信件可達性、送出後的追蹤。這篇我會從安裝一路帶到上線檢查表，中間穿插實務專案裡常見的踩坑，以及那些教學文件不會主動告訴你、卻會在半夜讓你debug到崩潰的地雷。

Contact Form 7 適合哪些網站

WordPress 在全球內容管理系統的佔有率長期超過四成（W3Techs 2026 年 6 月的統計），因此表單外掛、佈景主題整合與教學資源都相當多。除了 Contact Form 7，也有拖曳式表單與頁面編輯器自帶的表單功能。如果想通盤比較，可對照 WordPress 表單外掛推薦。

Contact Form 7 長期擁有大量使用者，原因之一是它的核心功能集中、客製空間大。

它不強迫套用完整視覺範本，樣式主要由主題與自訂 CSS 決定。對會寫一點 CSS 的人來說較容易調整；完全不碰程式的人，則可能更適合拖曳式工具。

它使用表單標籤（form-tags）定義欄位，例如 [text* your-name]、[email* your-email]。表單標籤不是一般 WordPress 短碼，但能精準控制欄位類型與選項。

面向	Contact Form 7	拖曳式付費表單
價格	完全免費	免費版功能受限，進階需年費
學習曲線	中等，需懂標籤語法	低，拖曳介面
樣式自由度	極高，HTML/CSS 完全可控	中等，受範本限制
附加功能	靠擴充外掛補齊	內建一條龍（分析、登入、付款）
適合誰	想精準控制、預算為零、會一點程式	要快速上線、不碰程式、預算充足

若要比較七款表單外掛，可參考WordPress 表單外掛推薦，其中同時整理免費與付費選項；以下則專注說明 Contact Form 7 從安裝到上線的流程。

動手之前，先問自己一個問題：這張表單要解決什麼

這是大多數教學不會講的事。很多人一打開 Contact Form 7 就開始加欄位，名字、電話、信箱、公司、預算、需求說明、預約時間、上傳檔案，一口氣全部堆上去。結果是：表單看起來什麼都能問，實際上沒有人填得完。

欄位數量、必填規則與提問方式都可能影響完成率，外掛名稱本身通常不是主要變因。若表單過長，可先移除當下不需要的欄位，再用自己的完成率資料比較改動前後。

以室內設計公司這類網站為例：聯絡表單常一口氣問了十幾個欄位，從坪數、預算、工期到風格偏好全設必填，訪客看到那排輸入框的第一個反應通常是關掉分頁。改善的做法很簡單，把欄位拆成「先留聯絡方式」與「細節用電話聊」兩段，第一段只留姓名、電話、一句話需求描述。這個動作的背後邏輯是：表單的任務在於讓對方願意把門推開，至於把客戶的條件問清楚，那是通話之後再做的事。

如果網站長期沒有詢問，問題可能出在流量、服務說明、行動入口或表單本身，不能先認定是哪一項。可搭配 網站沒人詢問怎麼辦，從整體轉換流程一起檢查。

安裝與啟用：三分鐘把外掛裝上去

安裝沒有什麼懸念。後台左側選「外掛 → 安裝外掛」，搜尋 Contact Form 7，找到作者是 Takayuki Miyoshi 的那一個，點立即安裝再啟用。如果你對安裝流程還不熟，WordPress 外掛安裝教學那篇有三種方法的完整示範，包含遇到權限錯誤時怎麼處理。

啟用之後，左側選單會多出一個「聯絡表單」（Contact）項目，點進去會看到一張預設表單，名叫「Contact form 1」。這張表單已經幫你組好基本的姓名、信箱、主旨、訊息欄位，而且附了一組短碼（shortcode），長得像這樣：[contact-form-7 id="123" title="Contact form 1"]。

把這組短碼貼到任何一頁（聯絡頁、關於頁、服務頁都可以），表單就會出現。你現在可以先貼到一個測試頁送送看，確認主機能正常寄信，再回來改細節。

一個小提醒：啟用後先把這張預設表單的名稱改掉。沿用「Contact form 1」會讓你之後管理多張表單時搞混，也會在短碼裡留下這個沒意義的名字。

從零組出第一張聯絡表單：四個分頁一次看懂

點「聯絡表單 → 新增表單」之後，你會看到四個分頁。這四個分頁就是 Contact Form 7 的全部靈魂，很多人只設第一個就按下儲存，難怪後面問題一堆。

分頁一：表單（Form）

這裡是用標籤（tag）組出欄位的地方。左上角有一排按鈕，文字、電子郵件、電話號碼、文字區域、下拉選單、核取方塊等等，點下去會跳出一個小視窗讓你設定欄位屬性，設定完它會把對應的短碼插進右邊的編輯區。輸出的東西長這樣：

[text* your-name placeholder "您的姓名"]
[email* your-email placeholder "您的 Email"]
[tel your-phone placeholder "聯絡電話"]
[textarea your-message placeholder "想談什麼？"]

那個星號 * 代表必填，沒有星號就是選填。這是欄位策略的第一個控制點：你能不能克制自己，不要把每個欄位都加上星號。

分頁二：郵件（Mail）

這是最多人跳過、卻最關鍵的分頁。它決定訪客按下送出後，系統會寄出一封什麼樣的信給你。欄位值可以用中括號帶入，例如你在「訊息內文」裡寫：

寄件人：[your-name]
信箱：[your-email]
電話：[your-phone]
內容：[your-message]

Contact Form 7 還提供特殊郵件標籤：[_remote_ip] 可帶入送出者 IP、[_post_title] 帶入表單所在頁面的標題、[_url] 帶入來源網址。依除錯與客服需求選用即可；IP 位址可能涉及個人資料，不要在沒有目的與保存規則時固定蒐集。

分頁三與四：郵件（二）與訊息

第三個分頁是「郵件（二）」，功能是讓系統寄一封確認信給填表的人。要不要開，看你服務的性質。如果你是接急件的行業（維修、到府服務），建議開，讓客戶知道「我的訊息送到了」；如果是高單價、需要人工作業的服務，反倒可以不開，免得自動回信跟實際回覆產生時間差，讓客戶覺得被晾著。

第四個分頁是「訊息」，就是各種狀態下的提示文字，例如送出成功、必填欄位空白、信箱格式錯誤。預設是英文夾雜，建議全部改成繁體中文，例如把「Please fill in the required field.」改成「這個欄位必填」。如果你的網站做多語系，這裡也會是翻譯的重點。

欄位策略：哪些該問、哪些千萬別設必填

這是我整篇文章最想讓你帶走的一節。表單的每一個欄位，都在跟訪客的耐心討價還價。多一個欄位，完成率就會掉一個檔次，這是業界做表單優化的共識，不是我發明的。差別只在於：你願不願意用欄位的取捨，去換那個被省下來的詢問。

我把常見欄位分成幾種類型，用一張表整理給你：

欄位類型	該不該問	處理方式
聯絡方式（姓名、電話或信箱）	必問	設必填，但二選一即可，不要電話和信箱同時必填
一句話需求描述	建議問	選填或必填皆可，欄位要夠大、placeholder 要具體
預算、坪數、人數、日期等條件	看行業	能延後到電話聊的，就不要放在表單
上傳檔案	謹慎開	會放大伺服器負擔與資安風險，非必要不開
性別、生日、職業	通常別問	對成交沒幫助，只會壓低完成率
訂閱電子報同意框	分開處理	獨立用訂閱表單處理，別混在聯絡表單

判斷一個欄位該不該留，我用一個很粗暴的問題：「沒有這個欄位，我能不能回這封詢問？」。能回，就代表這個欄位對成交不是必要，它只是你「順手想多知道」，那它就是完成率的敵人。

另一個常見錯誤是把需求說明欄的 placeholder 寫成「請輸入訊息」。這跟沒寫一樣。好的 placeholder 應該直接示範怎麼填，例如「例如：想在客廳加做一面電視牆，坪數約 8 坪」。當你把 placeholder 寫得像一個範例，訪客會本能地照著填，你也會收到結構更整齊的詢問單。

檔案上傳會增加儲存、郵件大小與資安風險。確實需要附件時，應限制允許格式與大小、更新外掛、驗證實際處理流程，並避免把上傳目錄設成可執行程式。若無法妥善管理，可改在後續往來中收件。

還有一件不能漏看：表單收集的資料要怎麼處理。姓名、電話與信箱可能涉及個人資料，應依實際蒐集情境檢視台灣《個人資料保護法》第 8 條等告知義務、隱私權政策、保存期間與存取權限。表單旁的一句簡短說明未必足以涵蓋所有法定事項；若資料還要用於電子報或行銷，也應另行確認合法依據與同意方式。涉及特定產業或大規模名單時，請讓法律專業人員審閱。

為什麼信寄不到？WordPress 寄信的真相與 SMTP

「表單顯示送出成功，卻沒有收到信」是常見問題。原因可能在郵件欄位、DNS 驗證、主機寄信服務、SMTP 設定或收件端過濾，應沿著寄送鏈逐段檢查。

WordPress 透過 wp_mail() 交由 PHPMailer 與主機設定的傳輸方式寄信；不少主機仍使用本機郵件服務。是否驗證寄件人、是否保存錯誤紀錄，取決於主機與郵件設定，因此「表單顯示成功」不等於郵件一定送達。

常見做法是改用經過驗證的郵件傳輸服務，可能透過 SMTP、API 或 OAuth 連線。使用郵件外掛時，優先採供應商支援的驗證方式與安全儲存機制，不要把帳號密碼直接寫進公開程式碼。

設好 SMTP 後，先寄測試信並檢查寄信紀錄與收件位置。再依郵件服務商文件設定 SPF、DKIM，確認寄件網域對齊；DMARC 則應在 SPF／DKIM 驗證正常後逐步部署。這些機制能改善身分驗證與政策控管，但不保證每封信都進收件匣。

一個被漏掉的細節：Contact Form 7 的「郵件」分頁裡有一欄「寄件人」。很多人直接填自己的信箱，這在 SMTP 改寫之後會被視為「冒名寄信」而觸發擋信。正確做法是寄件人設成你網域上的固定信箱（例如 no-reply@你的網域），把訪客填的信箱放在「回覆到」這一欄，這樣你按回覆時才會回給對方。

SMTP 服務怎麼選：三種來源的取捨

設 SMTP 的時候，你會面臨一個選擇：寄信帳號要用哪裡的？實務上有三種來源，各有適合的場景。

第一種是主機自帶的 SMTP。很多 WordPress 主機（例如你有 cPanel 的虛擬主機）會附一組網域信箱與 SMTP，直接拿來寄最省事。它的優點是同一個主機、同一個網域，驗證紀錄通常已經設好；缺點是這類郵件服務的寄信量與信譽管理很陽春，量大或被檢舉幾次就容易進垃圾匣。適合詢問量不大的小型網站。

第二種是一般辦公郵件帳號。有些供應商支援 SMTP、OAuth 或應用程式密碼，但驗證方式與寄送限額會調整，應依目前官方文件設定。這類帳號適合低量通知，不適合把大量自動郵件與日常信箱混在一起。

第三種是交易型郵件服務（transactional email）。這類服務通常提供身分驗證、退信或寄送紀錄，方案、限額與追蹤功能則依供應商當下條款而異。詢問量增加、需要監控退信，或同一張表單會觸發多封通知時，可以評估採用。

選擇時看寄送量、驗證方式、紀錄需求、資料處理地點與維護能力。無論使用主機郵件或交易型服務，都要先完成 SPF、DKIM 等設定並實際測試。

機器人垃圾信怎麼擋？三道防線各有用

表單上線後可能收到自動化垃圾信。Contact Form 7 提供 Akismet、reCAPTCHA 等整合方式，但需要分別設定；也可視實際垃圾量加入蜜罐或主機端防護。

實務上我會布三道防線，由輕到重：

• Akismet：Contact Form 7 支援的第三方垃圾內容過濾服務，需依文件在表單標籤標示姓名、信箱或網址等欄位。詳細流程可看 Akismet 垃圾留言防護教學。
• reCAPTCHA v3：這種驗證方式會在背景評估互動，不需要每次顯示核取方塊。Contact Form 7 提供整合介面，但仍要注意誤判、隱私與第三方腳本載入。
• 蜜罐欄位（honeypot）：在表單裡藏一個對人類隱藏、但機器人會傻傻去填的欄位，只要那欄有值就判定為機器人。這需要裝額外的擴充外掛（例如 Contact Form 7 Honeypot），但它對那種會繞過 reCAPTCHA 的進階機器人有意想不到的效果。

不要預設三種機制全部疊加。先選一到兩種與網站相容的防護，再觀察垃圾量與誤擋；新增機制後，也要用鍵盤、行動裝置與不同網路環境測試真人是否能正常送出。

行動裝置上的表單，跟你想的不一樣

全球網站流量中，行動裝置比例長期過半（Statista 2026 年 4 月的統計）。單一網站仍應查看自己的裝置資料，並用手機實測聯絡表單。

這件事改變了表單設計的所有優先順序。桌機上你把欄位排成兩欄還能看，手機上兩欄會被擠到讓人誤觸；桌機上一個 placeholder 寫長一點沒關係，手機上過長會被截斷，訪客看不清楚該填什麼。你在桌機預覽時覺得「這表單很好看啊」，到了手機上完全不是那回事。

針對行動裝置，我會固定檢查這幾件事：

1. 電話欄位改用 [tel]，不要用 [text]。tel 類型會讓手機直接喚出數字鍵盤，省掉訪客在英文鍵盤與數字之間切換的動作，這一個小調整能明顯降低中途放棄。
2. 信箱欄位用 [email]。同理，手機會帶出對應的鍵盤，而且 Contact Form 7 會自動做基本的信箱格式驗證。
3. 送出鈕要夠大。手指的點擊範圍遠大於滑鼠，按鈕高度建議至少 44px，而且四周要有足夠留白，避免訪客想按送出卻誤觸上一個欄位。
4. 欄位排序要符合單手拇指。把最重要的欄位（姓名、電話）放最上面，讓訪客在最舒適的滑動範圍內就能開始填。

這些不是設計美學，是輸入工程。每一個減少的點擊與切換，都會換成多一份完成的詢問單。

也可以為欄位設定正確的 autocomplete token，例如姓名用 name、信箱用 email、電話用 tel，協助瀏覽器提供自動填寫。Contact Form 7 的表單標籤語法與可用選項會隨版本調整，應依官方文件或欄位產生器輸出，不要直接把一般 HTML 寫法塞進標籤。

把陽春表單變好看：CSS 與主題相容性

Contact Form 7 不會替所有欄位套上一套完整視覺系統，實際邊框、間距與配色會受佈景主題和自訂 CSS 影響，因此同一張表單換主題後可能呈現不同。

如果主題已提供表單基本樣式，可能只需微調；若沒有，就補上必要的 CSS，例如輸入框寬度、內距、邊框、焦點狀態與送出按鈕。改完要一併檢查鍵盤焦點與錯誤訊息的可讀性。

Contact Form 7 輸出的 HTML 每個欄位都包在一個 .wpcf7-form-control 的 class 裡，送出鈕是 .wpcf7-submit。掌握這幾個 class，你就能用一段不超過二十行的 CSS 把整張表單重塑成你網站的風格。這也是我前面說它「樣式自由度極高」的原因，乾淨的 HTML 結構就是最大的自由。

給你一段可以直接拿去改的起手範例，把它貼到主題的「附加 CSS」或子主題樣式表裡就能看到效果：

.wpcf7 input[type="text"],
.wpcf7 input[type="email"],
.wpcf7 input[type="tel"],
.wpcf7 textarea {
  width: 100%;
  padding: 12px 14px;
  border: 1px solid #d0d0d0;
  border-radius: 6px;
  font-size: 16px;
}
.wpcf7-submit {
  background: #1a73e8;
  color: #fff;
  border: none;
  padding: 12px 28px;
  border-radius: 6px;
  cursor: pointer;
}

這段範例做的事很基本：把輸入框寬度撐滿、加上點擊起碼的內距與圓角、把送出鈕換成藍底白字。有一個數字要特別留意，font-size: 16px。這不是美觀問題，是 iOS Safari 的硬規矩：輸入框字級若小於 16px，iPhone 會自動放大整個頁面來聚焦輸入框，訪客填完一個欄位畫面就跑掉了。把手機版的輸入字級鎖在 16px 以上，是避免這個惱人行為的唯一方法。

一個進階技巧：如果你用 Elementor 這類頁面編輯器做版面，可以選擇不在 Elementor 裡用它的表單 widget，而是用一個「短碼」區塊把 Contact Form 7 嵌進去。這樣你同時擁有 Elementor 的版面控制力與 Contact Form 7 的標籤自由度，是很多進階站長的折衷做法。

送出之後發生什麼事：成功訊息、轉址與追蹤

表單送出成功，不代表工作結束，反而是另一段優化的起點。預設的 Contact Form 7 在送出成功後，會在表單的位置顯示一則綠色「您的訊息已成功送出」之類的提示。這個提示有兩個問題：一是它停留在原表單的位置，訪客如果沒往上滑根本看不到；二是它沒有給訪客「下一步」。

比較好的做法是把送出後的行為設計成一個完整的旅程。兩個方向你選一個：

方向一：感謝頁與轉址。使用目前支援的 wpcf7mailsent DOM 事件或相容的整合工具，在郵件成功送出後導向獨立感謝頁。舊版 on_sent_ok 已淘汰，不應再用。感謝頁可放下一步說明與必要的追蹤事件。

方向二：原地強化提示。不轉址，但把成功提示改寫成具體的下一步說明，例如「收到您的訊息了，我們會在一個工作天內回覆，急件請直接來電」。這對不希望訪客離開當前頁面的網站更合適。

不管走哪個方向，記得把送出這個動作接上你的追蹤系統。如果你用 Google Tag Manager 或 GA4，送出成功時觸發一個 generate_lead 或自訂事件，你才能在後台看到「這個月到底收到幾張詢問單、從哪一頁來的」。串接的具體做法，可以參考 WordPress GTM 與 GA4 串接那篇。

你怎麼知道表單在替你工作？三個衡量指標

表單上線之後，多數人的反應是「等信進來」。信有進來就安心，沒進來就著急。但這個判斷方式有個盲點：你只看得到「成功送出」的那端，看不到「打開表單卻沒填完」的那一大塊。要真的優化表單，你必須開始衡量，而不只是等待。

我會盯三個指標，缺一不可：

指標	看什麼	怎麼拿
表單頁的流量	有多少人被導到這一頁	GA4 的頁面瀏覽
表單完成率	實際送出的人佔看過表單的人多少比例	送出事件除以表單曝光
掉隊位置	哪一個欄位開始有人放棄	表單分析或欄位互動事件

第一個指標用來檢查上游。如果表單頁幾乎沒有瀏覽，應先處理流量與站內導引，再判斷表單欄位是否需要調整。

第二個指標是表單健康度的核心。完成率沒有絕對標準，因為產業差異很大：衝動型的訂閱表單可能要有兩成以上的完成率才算健康，需要深思的高單價服務詢問，個位數的完成率也可能屬於正常範圍。判斷的方式是跟自己比，先建立一個基準線，每次改動欄位之後觀察它往哪邊移動，跨產業的數字比較反而會誤導你。

第三個指標最難拿到，但也最有價值。如果你能看到「訪客填到第三個欄位就大量離開」，你就有具體的優化標的，而不是憑感覺改版。取得這個數據需要表單分析工具（有些付費表單外掛內建，或用 GA4 的事件追蹤搭配欄位的 blur 事件自己組），門檻較高。一個低門檻的替代方案是定期用真人的角度，自己走一次填表流程，很多卡點你親自走一遍就會發現。

把這三個指標想成體檢報告的三個欄位：流量是「有沒有人走進店裡」、完成率是「走進來的人有多少結帳」、掉隊位置是「結帳櫃檯哪一關在漏人」。三者一起看，你才知道該把力氣花在拉流量、改表單、還是拆欄位。

快取、多語系與其他地雷：上線前檢查

表單看起來都設好了，不代表它能在所有情境下正常運作。上線前我會固定檢查三個容易被疏忽的地雷。

地雷一：快取或安全規則妨礙送出。Contact Form 7 通常可以和頁面快取並用，不需要預設排除聯絡頁。若實際重現驗證或 AJAX 錯誤，再檢查快取延遲腳本、安全外掛、REST API／AJAX 端點與 CDN 規則，依錯誤紀錄做最小排除。相關設定可參考 WordPress 快取外掛。

地雷二：多語系站台的欄位沒同步翻譯。表單文字、錯誤訊息、placeholder 與郵件內容可能需要分語系處理。不要以為翻完主題就等於翻完表單，實際方式要看多語系外掛與 Contact Form 7 的整合。

地雷三：表單頁本身的速度。追蹤碼、未壓縮圖片與前端腳本都可能拖慢表單出現與互動。Core Web Vitals 是 Google 搜尋眾多訊號中影響有限的一組頁面體驗訊號，相關性與內容品質仍更重要；速度同時也會影響真實使用體驗，應用現場數據與轉換資料判斷；這兩點分別可對照 Google Search Central 2020 年 11 月的頁面體驗說明，以及 web.dev 的速度研究。

什麼時候你該換掉 Contact Form 7

讀到這裡，你可能會發現 Contact Form 7 的強項與弱項其實是同一件事：它的自由度來自於你什麼都要自己設。當你的需求超越「一張能寄信的聯絡表單」，開始需要條件邏輯（填 A 才會出現 B）、多步驟表單、付款整合、登入後自動帶入會員資料，Contact Form 7 就會開始顯得吃力。這不是它的錯，是它的設計本來就不是為了這些。

幾個明確的訊號代表你該認真考慮換：

• 你的詢問流程需要多步驟，例如選服務類型、填條件，再留下聯絡方式。
• 你需要讓訪客在表單上直接刷卡或超商付款。
• 你要把表單與 CRM 雙向同步，而不只是一封 Email 進來。
• 你的團隊裡沒有人願意碰 CSS 與短碼，你需要一個拖曳就能成形的介面。

這些情境下，付費表單外掛或頁面編輯器自帶的表單工具會省下你大量時間。它們要錢，但錢買的是「不用自己組」這件事。判斷的標準很簡單：算一下你為了讓 Contact Form 7 做出某個功能，已經花（或即將花）多少小時在查文件、裝擴充、改短碼，把那個時間換算成你的成本，你會很清楚該不該換。

更換工具前，先盤點並匯出既有送出紀錄。Contact Form 7 核心本身不保存表單送出內容；若另用儲存紀錄的擴充外掛，停用或移除前要查明資料表、匯出格式與新工具的匯入方式。也要依隱私政策確認哪些資料仍有保存必要。

這裡再補一個常見的延伸需求：如果你的表單是為了收電子報訂閱，那其實不該拿聯絡表單硬做，專門的訂閱工具會更順。這部分可以參考 MC4WP 電子報訂閱表單的做法，把聯絡與訂閱這兩種目的分開處理，兩邊都會更乾淨。

上線前檢查表：五個動作照著走

把上面內容整理成一張清單。表單正式對外開放前，依序走完這五步；之後每新增一張表單也可以沿用。

1. 實機測一次完整送出。用自己的手機、用 4G 網路、用一個平常不會用的信箱，從頭填到尾，確認信真的進到收件匣（不是垃圾匣）。這一步會同時驗證 SMTP、欄位設定、行動裝置體驗。
2. 逐欄位審視必填設定。把每個帶星號的欄位問一次「沒有它我能不能回信」，不能回才留必填。這一步通常會讓你砍掉兩到三個欄位。
3. 設定合適的垃圾信防護。先選一到兩種與網站相容的措施，例如 Akismet、reCAPTCHA 或蜜罐，再用正常與可疑內容測試誤擋情況；不必為了數量把所有機制一起疊上。
4. 把送出後的追蹤接上。確認 GA4 或 GTM 能收到「成功送出」這個事件，這是你之後優化表單的數據基礎，沒有數據等於瞎子摸象。
5. 檢查快取環境。在目前的快取、安全與 CDN 設定下完成一次真實送出；只有重現衝突時才加入必要的排除規則。

這五步走完，聯絡表單才算完成基本上線驗收，而不是單純放在頁面上。

持續檢查寄信可達性、垃圾信誤擋、欄位完成率與行動裝置操作，才能知道問題出在外掛設定、郵件鏈路，還是整體詢問流程。