WordPress 嵌入 Google 表單教學：免外掛搞定

網站需要活動報名或問卷時，可以評估 Google 表單。它負責題目、提交和回覆管理，WordPress 頁面則提供活動說明與嵌入位置；先確認資料與通知需求，再選擇工具。

已有可填寫的 Google 表單時，可把官方嵌入碼放進 WordPress 的「自訂 HTML」區塊。帳號必須有保留 iframe 的權限，網站也需允許來源；接著驗證手機、填寫權限及通知。基礎操作可看WordPress 架站攻略。

以下以已完成題目設計的表單為起點，說明發布、取得嵌入碼、版面調整與驗收。表單可長期使用，也可以在需求改變時改用其他工具，判斷依據是實際流程。

發布 Google 表單並嵌入 WordPress

先確認誰能填寫，再取得嵌入碼。Google 表單目前的官方操作使用 Publish 與 More 選單。

1. 在 Google 表單編輯畫面選「發布（Publish）」，設定回覆者存取範圍，再發布。
2. 從「更多（More）」選「嵌入 HTML」，複製官方 iframe 碼。
3. 在 WordPress 文章或頁面新增「自訂 HTML」區塊，貼上嵌入碼並儲存。
4. 用未登入視窗和手機開啟前臺，完成一次提交，核對回覆紀錄及需要的通知。

前臺看得到表單後，仍要檢查訪客能否填寫、手機捲動是否順暢，以及負責處理回覆的人是否收到通知。

什麼時候該用 Google Forms，什麼時候該換掉它

Google 表單與 WordPress 表單外掛各有管理方式。像Contact Form 7這類工具可配合站內流程，Google 表單則把回覆處理放在 Google 服務；應依需求比較。

以下列出選擇工具時值得實際驗證的項目。

若功能與管理方式符合需求，Google 表單也可用於長期聯絡。需要更細的樣式、站內資料處理或成功事件整合時，再比較 WordPress 表單。

驗證新需求時，可先用一張簡短表單收集必要資訊。觀察期間應涵蓋實際受眾與活動情境，並把回覆內容與後續處理一起檢查，再決定要擴充哪些能力。

從「更多」取得嵌入 HTML

嵌入碼要從表單的編輯畫面取得；填寫者連結用來開啟表單，兩者用途不同。

先開啟表單編輯畫面，確認已發布，並檢查回覆者的存取範圍。限制組織或指定對象的表單，即使嵌入公開網站也仍有存取限制。

在編輯畫面的「更多（More）」選單選「嵌入 HTML」，複製顯示的 iframe 程式碼。介面翻譯可能不同，以官方目前的 發布與嵌入說明為準。

先保留官方提供的 src，寬高則依頁面容器與表單內容測試。後文提供寬度自適應的寫法，高度仍需實際驗收。

回覆者連結適合放在電子報、社群或網頁按鈕，讓訪客另開表單；嵌入 HTML 才是放進頁面顯示的 iframe。請使用填寫網址，不要把編輯網址公開。

把 iframe 碼貼進 WordPress 的三條路，與實務上最推薦的那一條

可依現有編輯器選擇下列入口。三種方式都要確認儲存後 iframe 未被權限或安全政策移除。

方法一：區塊編輯器的「自訂 HTML」區塊（首選）

在區塊編輯器新增「自訂 HTML」，貼上官方嵌入碼並查看前臺。若儲存後 iframe 消失，先檢查帳號的 unfiltered_html 能力與站臺政策。區塊操作可延伸閱讀Gutenberg 區塊工具。

方法二：傳統編輯器（Classic Editor）的文字模式

使用 Classic Editor 時，可在「文字」模式貼上 HTML，儲存後再檢查前臺與原始碼。編輯器處理、帳號能力和安全設定都可能影響保留的標籤。

方法三：頁面編輯器（Elementor、Divi）的 HTML 或程式碼小工具

Elementor 可使用 HTML widget；其他編輯器則依官方文件找相應的程式碼入口。頁面若依賴編輯器的資料與渲染，日後停用或更換該工具時，需要重新驗收版面。

已使用核心區塊編輯器時，可先選自訂 HTML，便於集中維護原始碼。切換主題通常保留文章內容，但寬度、樣式與安全政策仍要重新檢查。

嵌入失敗：分開檢查發布、權限與載入政策

先在未登入視窗直接開啟回覆者網址，確認表單本身可用，再檢查 WordPress 頁面的 iframe。這能把填寫權限與網頁嵌入問題分開。

在 Google 表單確認已發布、回覆者範圍正確，並從「已發布（Published）」核對是否接受回覆。停止接受時可顯示自訂訊息；需要開放時，依目前管理流程調整再測試。

若 WordPress 沒有保留 iframe，檢查帳號能力；若瀏覽器拒絕載入，查看 Console 的政策錯誤。本站 CSP 的 frame-src 控制可載入哪些框架來源；被嵌頁面的 frame-ancestors 或 X-Frame-Options 控制誰可嵌入它。依錯誤調整必要來源，不要全面移除安全限制。

保留錯誤訊息與實際 src，確認使用官方嵌入網址。若只有特定瀏覽器或帳號失敗，再核對登入、組織限制及瀏覽器隱私設定；快取調整應以實際舊內容證據為依據。

用網址參數預先填好表單，一個被低估的技巧

預先填值可減少重複輸入，例如把活動場次帶進題目。填答者仍可能修改這些值，因此它適合便利填寫，不適合用作可信任的身份或權限證明。

在 Google 表單「更多」選「預先填寫表單」，填入預設答案後取得連結。請使用該表單實際產生的欄位參數，題目改動後重新驗證連結。

最直接的用法是提供官方產生的預填連結。若要將預填參數加入嵌入網址，保留原本嵌入參數、正確編碼並實際測試每個值；回覆先存於同一表單，連到 Sheets 是另行設定。

來源欄位可作為回覆的參考，但要說明其可修改性。網頁 UTM、GA4 事件與 Google 表單回覆屬於不同資料，只有設計並驗證對應方式後才能一起分析。

手機版：寬度跟隨容器，高度依內容驗收

固定寬度 iframe 可能超出手機內容區。請在窄螢幕檢查頁面外層是否出現橫向捲動，以及表單內部的題目與按鈕能否操作。

例如固定 640px 的框架可能大於頁面可用寬度。可以用 width:100% 與 max-width:100% 讓外框跟隨容器，再檢查原有樣式是否覆蓋設定。

以下 CSS 示範自適應寬度。900px 只是高度範例，需要按題數、分節與手機版實際調整。

把 CSS 放到主題允許的自訂樣式位置，或交由網站維護者加入站臺樣式表；不同主題的編輯入口可能不同。

.gf-wrap { width: 100%; } .gf-wrap iframe { display: block; width: 100%; max-width: 100%; height: 900px; border: 0; }

調整範例高度後，測試每個分節、錯誤提示與提交結果。長內容可能需要框內捲動，應確認捲動和鍵盤焦點都能正常到達提交按鈕。

回到 HTML 區塊，在完整官方 iframe 外加一層 class 為 gf-wrap 的 div，並為 iframe 加上描述表單用途的 title。

例如外層開始標籤為 <div class="gf-wrap">，接著保留自己的官方 iframe，再以 </div> 結束。不要把表單編輯網址代入 src；另可提供「另開表單」的回覆者連結。

手機驗收也應包含頁面說明、導覽與主要內容。Google 主要使用行動版內容索引，實際效能與使用體驗仍需各自檢查。

由於同源政策，外層網頁無法直接讀取 Google 表單內部的 DOM 來計算高度。可採用經測試的高度、保留可操作的捲動，並提供另開表單選項。

上線前核對五項填寫設定

很多人以為嵌入碼貼好、手機不破版，就等於完工。其實 Google 表單後台有幾個設定，預設值不一定符合你想要的效果，建議在嵌入之前一次調整完，免得表單上線之後才發現收了一堆沒有用的欄位、或漏收了關鍵資訊。底下把這五個設定列成一張清單，是每次新建表單時建議走一遍的流程。

• Email：選擇不收集、已驗證地址或填答者自行輸入。已驗證地址需要 Google 帳號；自行輸入與帳號驗證是不同方式。
• 限制一次：限制為一次回覆需要 Google 帳號，限制對象是帳號，不等於辨識同一自然人。
• 進度提示：長表單可評估進度條，並實測各分節的順序與導引。
• 確認訊息：說明真正會執行的下一步與聯絡方式，回覆時間應符合自己的處理流程。
• 摘要與編輯：查看結果摘要可能向回覆者顯示文字回覆或圖表；開啟前確認資料適合分享。是否允許編輯自己的回覆另行設定。

調整後用符合與不符合權限的帳號各測一次，再確認嵌入頁面呈現和回覆管理。

部署時核對載入、資料管理與通知

嵌入服務需要網站與 Google 帳號兩邊共同維護。以下三項應納入交接和驗收。

載入：量測第三方框架的資源

iframe 會載入獨立文件及其子資源，實際負擔應用瀏覽器測量。位於首屏外的框架可評估 loading="lazy"；若表單是訪客進頁就要使用的主要內容，應優先確保及時可用。更完整的診斷可參考網站速度優化指南。

資料：管理表單、試算表與帳號權限

回覆可保存在 Google 表單，另可連結 Google Sheets。兩者的分享權限與備份需分別管理；蒐集前應釐清必要欄位、保存期限、可存取者及組織適用的服務條件。

涉及受管制或敏感資料時，先由負責單位確認可使用的服務、合約與控制措施，再決定架構。改用 WordPress 表單時，也需要核對實際資料位置、外部處理與下載權限。

通知：由 Google 表單或其整合負責寄送

嵌入本身不會讓通知改走 WordPress。可在 Google 表單「回覆」的更多選單啟用新回覆 Email 通知；若沒收到，先查 Google 表單設定與該帳號收件狀態。若改用站內表單寄信，再參考WordPress SMTP 發信設定；Google 表單通知不經該流程。

收集 Email 後，可以設定依要求或總是寄送回覆副本。副本是提交內容的回傳；若需要另外的品牌訊息、收件者分派或後續流程，需評估相應整合。

多位處理者應各自核對可存取的資料與通知。客製寄送可評估附加元件或 Apps Script，並檢查授權、配額及執行紀錄；這些流程仍需獨立維護。

追蹤時分清楚開啟連結與成功提交

外層 WordPress 的分析程式受同源政策限制，無法直接讀取 Google 表單內部操作。請先決定要量測的是頁面到訪、另開表單，還是 Google 已接受的回覆。

以下兩個方向各自回答不同問題，事件名稱應清楚區分。

若頁面有「另開表單」連結，可追蹤該連結點擊；這不代表 iframe 內提交成功。設定方法可參考GTM 與 GA4 串接，並用實際操作核對事件。

成功回覆可從 Google 表單紀錄或經驗證的提交整合確認。Apps Script 的 form-submit 觸發器處理伺服器端事件，並不因此控制填答者瀏覽器轉址；確認訊息中的後續連結點擊也應與成功提交分開記錄。

若需要把網站上的成功提交直接接入分析，可比較有明確成功事件或後端回報能力的表單工具，並核對事件去重、同意設定與資料範圍。

關於 Google 表單嵌入，三個最常提醒客戶的誤區

交接表單時，除了貼上程式碼，也應留下通知、資料及版面維護方式。

確認處理責任：列出誰查看回覆、誰收到通知、未收到信時如何查詢。測試時同時核對回覆紀錄和預定收件帳號，避免只驗收自己的信箱。

確認樣式與備份：Google 表單有自己的主題設定，外層網站 CSS 不能直接改跨來源框架內部。WordPress 備份也不包含 Google 表單資料；需要另外規劃匯出、共享與帳號恢復。

確認資料可攜性：定期依需求匯出回覆，記錄表單擁有者、協作者與試算表權限。保護備份並實際檢查可讀性，讓帳號異動或工具更換時仍能接手。

需求改變時，重新比較五項能力

以下項目適合在流程擴充時重新核對。現有工具能完成就繼續維護；若有具體缺口，再比較替代方案。

1. 通知是否需要更多收件者、條件分派或自訂信件。
2. 資料位置、存取、保存與稽核是否符合組織要求。
3. 核心聯絡流程是否需要更完整的成功事件與後續整合。
4. 現有題型與分節跳題是否足夠，或需要即時計算、欄位連動等其他能力。
5. Google 表單提供的樣式是否符合網站的品牌和使用需求。

可參考WordPress 表單工具比較核對功能。使用 Elementor 時，可對照Elementor Pro 表單製作教學；一般聯絡則可先測試Contact Form 7。最後依資料保存、通知與維護需求選擇。

如果你的目標不是「換掉」，而是「讓表單幫我帶來更多詢問」，那重點會落在表單設計跟行動呼籲的搭配，這部分可以參考如何讓網站帶來更多詢問跟CTA 行動呼籲設計指南，觀念是一樣的，無論表單是哪一套。

搬家不丟資料：從 Google 試算表搬到 WordPress 的兩條路

更換工具前，先匯出 Google 表單回覆並核對已連結的 Sheets。歷史資料如何保存或轉入新系統，應在切換前決定。

第一條路是「新舊並存」。新表單用 WordPress 原生外掛從今天起跑，舊的 Google 試算表當成歷史資料留檔。這條路最簡單，缺點是你的名單會分成兩個來源，後續要撈資料的時候得兩邊都查。如果你的舊資料只是備查、不會持續用到，這條路就夠了。

如果要把歷史回覆轉入新工具，先確認該工具支援的是「提交紀錄匯入」而非只匯入表單設定，並核對方案或擴充。用少量資料測試欄位對應、日期、電話前置零和選項，再進行完整搬遷。

CSV 可作為回覆備份的一部分，但不包含所有表單設定、附件與權限。依需求另外保存相關資料，驗證備份完整性及存取控制，再安排切換。

現在就動手的四步行動方案

講了一大堆，最後給你一份可以今天照著做的行動清單。別貪多，先跑完一輪，有問題再回來對照前面的章節。

1. 確認表單已發布、回覆者權限正確，並用低風險頁面試跑嵌入。
2. 讓 iframe 寬度配合容器，依內容調整高度，測試手機與鍵盤捲動。
3. 用未登入或目標帳號完成提交，核對回覆紀錄、確認訊息和需要的通知。
4. 依分析需求定義事件，把連結點擊與實際回覆分開；同步記錄資料管理與處理責任。

完成驗收後，保留設定與測試紀錄。日後題目、權限、主題或通知改動時，再跑一次相關流程。

評估表現時，先對齊觀察期間和流量範圍。表單可能由其他管道開啟，網站瀏覽與回覆數也可能包含重複或測試資料；兩者不能直接視為同一批人的轉換率。可配合使用者測試，檢查說明、欄位與操作阻礙。

工具選擇可以隨需求調整。先確認回覆能被妥善處理，再依具體缺口擴充設計、整合或分析；需要協助時可再評估合適的網站服務。

定期核對回覆與處理紀錄，標記測試及明確垃圾資料。判定重複前先看內容和業務情境，並依保存政策處理，讓後續分析有清楚的資料範圍。