Elementor Pro 表單教學：零程式碼搞定聯絡表單

表單做好看很簡單，表單做好用、不漏信，才是真的難。

相信不少人也遇過這種狀況：客戶跟你說「我填了表單給你欸」，你打開信箱卻什麼都沒收到。你進 WordPress 後台看，記錄裡也找不到那筆資料。一筆可能成交的詢問，就這樣人間蒸發。

Elementor 的 Form Widget 能用視覺介面建立表單，但畫面完成後，還要確認提交是否保存、通知是否寄達，以及 CRM 是否收到資料。以下依序整理欄位、多步驟、寄信、垃圾訊息防護與對帳；部分串接和追蹤需求可能需要額外工具或程式碼。

如果你還沒裝 Elementor Pro，先看 Elementor Pro 完整購買與功能指南的安裝與功能總覽；想了解 Elementor 整體操作，看 Elementor 完整教學。這篇預設你已經能在編輯器裡拖拉 Widget。

表單不是欄位拼圖，是網站的「收銀台」

很多教學把表單講成「把欄位拉一拉就好」。這是誤會。

想像一下，你開了一家裝潢精美的店，客人逛了一圈，走到櫃台準備結帳，結果收銀機卡住、店員找不到發票、信用卡刷不過。客人會怎樣？放下東西走人。網站的表單就是那台收銀機。SEO 把人帶進來，內容把人留下來，CTA 把人推到表單前面，但只要表單這一關出問題，前面全部白工。一個寄不到信的聯絡表單，跟沒有表單是一樣的。

所以我把表單當成一個獨立的轉換系統來設計，而不是頁面上的一個小元素。它要回答三件事：資料從哪來（欄位）、資料去哪裡（信箱還是 CRM）、資料有沒有真的到位（對帳）。這三件事任何一件漏掉，表單就是裝飾品。

實務上，我會把篇幅花在「信箱串接」和「對帳」上。表單好不好看，你打開預覽就知道；表單有沒有漏信，你不對帳永遠不知道。想看 Elementor 表單的設計變體（聯絡、訂閱、註冊），可以再對照 Elementor Pro 表單設計全攻略，那篇談的是表單類型分類，這篇談的是把任何一種表單做到「真的會送達」的工程。

換個角度想，表單其實是整個行銷漏斗裡「最後一公分」的環節。你花的廣告費、寫的內容、做的 SEO，全部要靠這一個動作（客人按下送出）才會變成可以追蹤、可以回覆的詢問。偏偏很多人把九成的力氣花在漏斗前面，只留一成的力氣給表單，結果在離成交最近的地方漏掉最多。把表單當成戰略資產來設計，別把它當頁面收尾的小零件，這個心態轉過來，你的詢問品質會立刻有感。

動手拉欄位之前，先回答這四個問題

我發現大部分的表單問題，都不是出在 Elementor 本身，而是出在「還沒想清楚就開始拉欄位」。表單還沒做之前，先把這四個問題寫在紙上，後面會省掉一半的除錯時間。

這四個答案，就是這篇後面所有設定的依據。比方聯絡詢問只要姓名信箱和訊息；報價詢問可能要加預算區間和需求描述，還要進 CRM 開商機。如果你正在做的是比較單純的聯絡表單，WordPress 表單外掛推薦那篇有 Elementor 以外的選擇比較，可以對照看哪個工具適合你的情境，未必每一種表單都要用 Elementor Pro 內建的。

還有一個判斷維度很多人沒想：表單的長度，應該跟「客人的意圖強度」成正比。意圖強、急著解決問題的客人（比方膝蓋痛要掛號、冷氣壞了要報修），願意填的欄位比較多；意圖弱、還在比價的客人（比方訂閱電子報、索取免費資源），只要一個信箱就好。把高意圖的詢問表單做深、把低意圖的訂閱表單做淺，兩邊的轉換率才會同時顧到。把所有表單都做成同一種深度，是最常見的設計失誤。

用 Form Widget 把欄位拉出來：欄位類型與排版邏輯

前置作業想清楚，這裡的速度會很快。在 Elementor 編輯器裡把 Form Widget 拖到畫面上，預設會給你姓名、信箱、訊息三個欄位，這就是聯絡表單的最小可用版本。

欄位類型怎麼選，我有一個判斷原則：能用選項就別讓客人自己打字。選項資料乾淨，後續進 CRM 才好分類，客人打字打錯的機率也低。

排版上有兩個小技巧。第一，相關欄位排成兩欄，比方姓和名、公司和職稱，畫面會緊湊很多。第二，必填欄位的標記要清楚，Elementor 預設會標星號，但你要在欄位的 Label 寫明白「必填」兩個字，手機上星號容易被忽略。

欄位的 Required（必填）設定要克制。每一個必填欄位都在勸退客人。我的習慣是：能選填就選填，只把真正拿不到就無法回覆的欄位設必填，通常是姓名和信箱。其他像電話、公司、需求細節，都能選填，甚至直接拿掉。

欄位驗證（Validation）和錯誤訊息，是另一個容易被忘記的細節。Elementor 表單在欄位送出不符合規則時，會顯示一段錯誤訊息。預設的訊息是英文的，你要在表單設定裡把它改成白話中文，比方 Email 欄位的錯誤訊息從「The field is invalid」改成「請輸入正確的 email 格式」。錯誤訊息的品質直接影響客人能不能一次填對，訊息越具體、越白話，客人越不會在這一關放棄。

還有一個進階用法：檔案上傳欄位。如果你收的作品集或需求文件，務必在欄位設定裡限制允許的副檔名（比方 pdf、jpg、png、zip）和檔案大小上限（比方 10MB）。沒有限制的話，有人會上傳幾百 MB 的影片或可執行檔，一個塞爆你的主機空間，一個帶來資安風險。檔案上傳這個欄位，寧可一開始就嚴格設限，也不要事後處理爆量的垃圾檔案。牽涉到檔案和表單安全，WordPress 資安防護全攻略有整站的防護建議可以一起看。

多步驟表單與條件邏輯：把長表單拆成對話

Form Widget 可用 Step 欄位拆成多步驟。依其他欄位答案顯示或隱藏欄位的條件邏輯，不是目前官方 Form Widget 文件列出的原生欄位設定；這類需求需另確認相容擴充或自訂實作。

多步驟的精神是：不要一次嚇跑人。比方一個報價詢問表單有十個欄位，拆成三步：第一步基本聯絡資料、第二步需求與預算、第三步補充說明。每一步只看到幾個欄位，心理壓力小很多。要先在 Form Widget 的 Form Fields 加入 Step 欄位並放在分段邊界，才會成為多步驟表單；再設定步驟文字、上一／下一步按鈕與進度樣式。

若要依「服務類型」顯示不同問題，先選擇明確支援表單欄位條件的工具。Elementor 的元素 Display Conditions 與表單答案分支是不同功能，不能在欄位進階面板假設存在 Conditional 開關。

條件欄位的顯示、必填、伺服器端驗證與保存必須使用同一套規則。隱藏欄位不能仍擋住送出，也不應把不適用的舊值寫進名單；要依實際擴充走過所有分支測試。

多步驟表單還有一個容易漏的點：「上一步」按鈕要確認資料有沒有被保留。同一表單流程應檢查已填內容能否保留；重新載入頁面、自訂腳本或瀏覽器行為可能改變結果，不能一概歸因於快取外掛。測試的時候一定要自己走一遍「下一步、上一步、下一步」的流程，確認資料還在。

多步驟表單搭配一個進度指示（progress bar 或「第 1 步／共 3 步」的文字），效果會再更好。原因是進度指示降低了客人「這要填多久」的不確定感，他知道還剩幾步就願意撐完。沒有進度指示的多步驟表單，有時反而比單頁表單更勸退，因為客人不知道盡頭在哪。這是一個零成本卻常被漏掉的轉換細節，設定就在 Elementor 表單的 Form Steps 樣式區塊。

表單的視覺設計：手機優先，欄位越少越好

表單的視覺設計，我只有兩個核心原則：手機先看、欄位先砍。

手機為什麼優先？因為現在超過六成的網站流量來自手機（依 Statista 的統計），你的聯絡表單多半是在手機上被填的。手機上的表單設計跟桌機完全不同：欄位要夠大、字級要夠大、按鈕要夠明顯，不然指尖點不到、iOS 還會自動放大畫面造成跳動。

欄位越少越好這件事，道理大家都懂，但捨不得砍。我的判斷方法是：每一個欄位都問自己「沒有這個欄位，我真的沒辦法回覆這個客人嗎？」答案如果是「還是可以回覆，只是要再問一次」，那就改成選填，或直接砍掉。你要的是讓客人先把信箱留下來，其他細節後續溝通都能補，不要為了「一次收齊」把人擋在門外。

頁面載入速度也會影響表單完成率。表單頁面載入超過三秒，流失會明顯上升（見 web.dev 對速度重要性的研究）。Elementor 表單本身不重，但如果你在同一頁塞了一堆動畫、大圖、第三方追蹤碼，表單還沒出來客人就走了。表單頁面要保持輕量，能用文字解決的就不要放圖。

有兩個視覺細節決定了表單「手感」好不好。第一是 Label（欄位標籤）的位置。Elementor 預設把 Label 放在欄位上方，這在手機上最好用，因為欄位變窄時 Placeholder（預留提示文字）式標籤會被輸入的字蓋掉，客人填到一半忘記這格要填什麼。如果空間真的不夠要用 Placeholder 式標籤，至少保留欄位上方的標題。

第二是按鈕狀態。送出按鈕應有 hover 與鍵盤 focus 的可辨識回饋；送出期間也應防止重複提交並顯示處理狀態。Elementor 可在 Style 面板調整一般與 hover 樣式，但 focus、載入文字與停用行為是否可直接設定，要依目前元件版本與表單行為確認，必要時需補 CSS 或程式。設計稿可先參考Figma 按鈕狀態與轉場教學定義各種回饋。

信箱串接的真相：分開檢查提交、郵件設定與投遞結果

這裡是整篇文章最容易救命的地方。

Elementor 表單預設用 WordPress 內建的 wp_mail() 寄信，而 wp_mail() 預設透過 PHP 的 mail() 函式，走的是主機的寄信功能。主機可能限制寄信，但也要檢查表單設定、授權、日誌與收件端，不能只由症狀認定原因。

症狀通常是這樣：客人填完、看到「感謝您的來信」、你卻什麼都沒收到。後台表單記錄裡有那筆資料，但信從沒到過你的信箱。這表示保存與通知的結果不同，仍需檢查 Elementor 設定、郵件路徑與收件端規則。

SMTP 或郵件 API 可讓 WordPress 經由指定服務寄信，但不會自動完成寄件網域驗證。仍需依服務商要求設定 SPF、DKIM、寄件者與授權，並用郵件日誌及實際收件結果驗證。

詳細的 SMTP 設定步驟，看 WordPress SMTP 發信設定教學那篇的完整走法，這裡只講和 Elementor 表單有關的接點。

在 Actions after Submit 加入 Collect Submissions，才能在 Elementor → Submissions 檢查成功保存的提交資料；再搭配郵件日誌核對通知是否送達。後台紀錄可協助補救通知失敗，但仍需備份與定期測試，不能保證每筆提交都不會遺失。

送出之後發生什麼事：通知信、自動回信與分信邏輯

很多人把表單設定停在「信寄到我信箱」這一步，但其實送出後的動作（Actions after Submit）才是把詢問變成成交的關鍵。Elementor Pro 表單的 Email 區塊，能做的遠比寄一封通知信多。

自動回信是很多人漏掉、卻對轉換率影響很大的一環。客戶填完表單後最焦慮的事就是「不知道對方有沒有收到、什麼時候會回」，這份不確定感會讓他在等待期間去找競品比價。一封即時的自動回信能消除這份焦慮，也讓你在還沒給報價前就先建立信任。

自動回信的內容有三個重點。主旨要明確（「我們已收到您的詢問」），內容要講清楚下一步會發生什麼（我們會在兩個工作天內回覆、或我們會先寄一份需求確認表給您），最好再給一個預期回覆時間，讓客人知道要等多久。這封信也能放下一步的引導，比方「追蹤我們的粉專」「先看看常見問答」，把剛建立的注意力延續下去，別讓客人填完就走。

通知信的格式也有學問。預設的通知信會把所有欄位列出來，但如果是給團隊內部看的，你可以在 Email Template 用短碼自訂信件內容，把最重要的資訊（客人姓名、信箱、詢問摘要）放最前面，讓接信的人一眼看到關鍵、能馬上處理。回覆時間敏感的詢問，信件排序就是效率。

這個「通知信加自動回信」的組合，是我會要求每一個上線表單都有的基本配備。少了自動回信，客人填完表單後是懸在半空中的，這份不確定感會削弱他對你的信任，也會降低他等你回覆的耐心。一封信的成本幾乎是零，卻能把詢問的「留存率」往上拉一截。很多團隊寄了幾個月才回頭補上自動回信，補完之後第一個回饋都是「客人變得比較願意等我們回覆了」。

垃圾訊息防禦：三道防線比一個驗證碼可靠

表單上線，垃圾訊息跟著來。機器人會自動填表單灌你信箱，塞一堆博彩和假連結。很多人第一反應是裝驗證碼（CAPTCHA），但驗證碼不是萬靈丹，只靠它一定擋不住。

我的防禦策略是三道防線疊起來，每一道處理不同類型的威脅。

Honeypot 是 Form Widget 的欄位類型：新增欄位並將 Type 設為 Honeypot。它能攔阻會填寫隱藏欄位的機器人，但不是所有垃圾訊息都會落入這個判斷。

Elementor 原生提供 reCAPTCHA 與 reCAPTCHA V3 欄位；先在 Integrations 設定對應版本的 Site Key 與 Secret Key，再放入表單。hCaptcha 需要另外確認相容整合，不能視為同一個原生選項。

第三道是 Akismet。Akismet 是 Automattic 的垃圾內容過濾服務。Elementor 官方說明要求 Advanced 或更高方案，並需設定 Akismet API Key、啟用整合及對應姓名、Email、內容欄位短碼，最後用測試提交確認攔阻結果。Akismet 的完整設定看 Akismet 垃圾留言防護教學。

防垃圾設定要依服務、方案與實際誤擋率調整。驗證碼、Honeypot 與內容過濾各有盲點，沒有任何一種能保證擋住所有人工或自動垃圾訊息。

接 CRM 與名單系統：webhook 雙通道，讓名單不漏接

表單只寄信到信箱，是最陽春的用法。一旦詢問量變大，你需要的是名單自動落地到 CRM 或電子報系統，而不是靠人去信箱手動轉登。畢竟電子郵件至今仍是名單轉換與後續經營的主力管道之一，行銷人對它的投入沒有縮手（見 HubSpot 2025 年的基準報告）。所以把表單接上自動化的名單流程，投報率遠高於純人工處理。

Actions after Submit 可設定 Email、Collect Submissions 等送出動作；Webhook 與進階服務整合須核對方案權限。啟用前先確認接收端支援的驗證方式、資料格式與錯誤紀錄。

Webhook 會把表單資料送到指定接收網址。實際欄位與格式要以設定及收到的測試請求為準，不能假設固定為 JSON；接收端是否建立或更新名單，也由其規則決定。

設定方式：到 Elementor 表單的 Actions after Submit 選 Webhook，在 Webhook URL 填接收端網址。送出測試表單，去接收端確認資料有沒有到。如果要做 WooCommerce 的詢價或結帳表單欄位客製，WooCommerce 結帳表單客製化教學和WooCommerce 詢價表單教學有對應的做法，跟 Elementor 表單是互補的兩條路。

可同時設定 Webhook 與 Collect Submissions，並用提交識別、時間、接收狀態與欄位值核對。CRM 可能把多次提交合併為同一聯絡人，不能只比較兩邊筆數；補送時也要防止重複建立資料。

以每月數十到上百筆詢問的服務型網站為例，要把 Elementor Pro 表單接 CRM、讓名單穩定落地、不漏信，靠的通常不是花俏的設計，而是 寄信服務、webhook 與後台留存、加上嚴格的對帳流程。設計漂亮是基本功，名單不漏才是真功夫。

表單接 CRM 最容易漏掉的四個細節

承接上一段的可靠性原則，我把線上最容易出問題、又最容易被疏忽的四個細節單獨拉出來。這四個點，每一個都可能讓一筆詢問憑空消失。

這四個細節，沒有一個是 Elementor 會主動提醒你的。它們都是「不對帳就發現不了」的隱形漏洞。第一個尤其常見：很多人以為 webhook 設好就沒事，結果 CRM 那邊欄位全空，因為 ID 是 field_xxx 這種代碼，對接的人根本看不懂。所以接 webhook 的時候，先送一筆測試資料，到接收端看實際收到什麼欄位名稱，照著那個名稱去對 CRM 欄位，這是最保險的做法。

第二個細節背後的觀念值得單獨講：表單的價值，取決於名單能不能被回覆。一個信箱打錯的詢問，再漂亮也是廢單。所以別只想在表單上堆欄位，回頭檢查你收進來的資料品質更實在。確認信箱欄位、下拉選項取代自由輸入、必填只留關鍵幾格，這三件事都在顧名單品質。名單量再大，回不了信就是白搭。

量測與除錯：用 GTM 追蹤表單提交，用對帳抓漏

表單上線後，你要回答兩個問題：有多少人送出表單？送出的表單有沒有真的變成名單？第一個靠追蹤，第二個靠對帳。沒有追蹤，你不知道表單帶來多少轉換；沒有對帳，你不知道那些轉換有沒有真的落地。

追蹤表單提交，用 Google Tag Manager（GTM）最靈活。主要有兩種做法。

把這個轉換事件接到 GA4，你就能在報表裡看到表單帶來的轉換數、來源、裝置。GTM 和 GA4 的完整串接流程，看 WordPress GTM 加 GA4 串接教學。如果你的表單是用在不同行銷活動的到達頁，記得用 UTM 參數標記流量來源，才能分辨哪個活動帶來的詢問最多，UTM 怎麼設看 UTM 追蹤碼完整教學。想從更源頭觀察整站流量怎麼進來，WordPress 安裝 Google Analytics 教學是基礎。

除錯的對帳流程，我固定這樣跑：

1. 在預定期間匯出已保存的提交與接收端處理紀錄。
2. 以提交識別、時間與欄位值比對，注意CRM可能更新既有聯絡人而非新增一筆。
3. 查明缺件、重複或合併原因，再補送需要的資料，避免重複建立。
4. 依服務需求安排實際提交、收信與串接測試；有異常時查日誌及告警。

定期核對與實際測試能幫助確認表單運作，也可搭配失敗告警與寄送日誌。否則你只是相信它應該沒問題，直到某天客戶問「我上個月填的表單你收到沒」，你才發現已經漏了一整個月。那種事，發生一次就夠你痛很久。

表單出問題時的症狀診斷表

對帳之外，表單出狀況時最需要的是「從症狀反推原因」。我把實際會遇到的幾種症狀整理成一張診斷表，你照著症狀找，多半能快速定位。同一症狀可能有不同原因，應搭配提交紀錄、郵件日誌與瀏覽器錯誤一起判斷。

這張表不用背，留著表單出問題的時候照著查就好。它的價值在於：大部分表單問題都是這六種的組合，能快速分類就能快速修。而這六種裡，有四種的根因都指向同一件事，就是你沒有把「後台留存」和「對帳」做起來。只要這兩件事有做，問題幾乎都會在你被客戶問之前就先發現。

行動清單：六步把 Elementor Pro 表單做到能上線

講了這麼多，給你一張可以直接照著走的清單。這六步走完，你的表單就不只是好看，而是真的能在收名單、不漏信。

1. 先寫下四個答案：表單目的、資料去哪、怎麼擋垃圾、成功定義。這張紙就是你後面所有設定的依據。
2. 用 Form Widget 拉欄位，能選項就別讓人打字，必填只留真正必要的。長表單可拆多步驟；條件欄位需先確認所用擴充支援，並測試顯示與必填規則。
3. 手機上預覽，檢查欄位高度、字級、按鈕、鍵盤類型。頁面保持輕量，別讓動畫和大圖拖垮載入。
4. 裝 SMTP 外掛，用網域寄件地址寄信，寄測試信進收件匣。把 Collect Submissions 打開當備援。
5. 依需求加入 Honeypot 與 reCAPTCHA；若方案支援，再評估 Akismet。hCaptcha 需另接相容擴充，任何組合都應檢查真人誤擋情形。
6. 接 webhook 到 CRM 或名單系統，用 webhook 雙通道（webhook 加後台留存）。設成功訊息或轉址到感謝頁，用 GTM 追蹤提交。依詢問量與接收端風險排定對帳及告警。

表單上線前，請實際送出一筆資料，確認後台留存、通知信與 CRM 都收到預期內容。之後定期核對紀錄，才能及早發現寄送失敗或串接中斷。

Submissions 可檢查成功保存的提交，但不能單靠它知道所有填錯、未送出或中途放棄的情況。若要分析各步驟放棄率，需另行設計前端事件與適當的同意機制，再與提交結果核對；不要把成功名單當成完整的表單漏斗。

如果你架站用的是 Bricks 這類新世代編輯器，Bricks Builder 教學有對應的表單做法；想用免費的 Google 表單先頂著，WordPress 嵌入 Google 表單是零成本方案；而Contact Form 7 完整教學則是另一條免費外掛路線。工具會換，但「寄信服務、webhook 與後台留存、定期對帳」這套可靠性的底層邏輯不會變。現在，輪到你把這六步在自己的網站上走一遍了。