WordPress 嵌入 Facebook Messenger 客服外掛教學

WordPress 接上 Messenger 之前，先搞清楚它到底解決什麼問題

網站有流量，聯絡表單卻不一定有人填。把 Messenger 放在明確位置，可以多提供一個聯絡入口；它能不能增加詢問，仍要看客群是否使用 Messenger、團隊能否及時回覆，以及實際追蹤到的對話與成交資料。

這篇談的是目前仍可用的做法：用 m.me 連結開啟 Messenger 對話、用 Chaty 之類的多通道外掛集中聯絡按鈕，或改用第三方站內客服。網路上大量「貼一段 Meta SDK 就能在網站內聊天」的舊教學已經失效，不要照著做。

先看結論：Meta 舊版 Customer Chat Plugin 的全部功能已於 2024 年 5 月 9 日停止服務；官方停用公告保留 m.me 連結作為可用入口，但沒有提供功能相同的新站內嵌入元件。這不代表整個 Messenger Platform 或所有 Facebook SDK 都在同一天停用，停掉的是 Chat Plugin（見 Meta 官方停用公告）。

兩種體驗要分清楚。舊版 Customer Chat Plugin 會把對話框嵌在網站裡；m.me 是 Messenger 的連結，點擊後會離開目前頁面，交由 Messenger App、Messenger 網頁版或裝置上的連結處理設定接手。Meta 目前的說明仍把 m.me/username 定義為 Messenger profile URL，但沒有保證每一種手機、瀏覽器與登入狀態都走同一條路（見 Meta Messenger 說明中心）。

Messenger 按鈕只是降低聯絡門檻的一種方式。若網站的主張、價格或 CTA 本身不清楚，多一顆泡泡也救不了詢問動線。需要一起檢查整體流程，可參考 網站沒人詢問怎麼辦。

三條接法，選哪一條才不會白做工

現在常見的接法可分成三類。差別不只在外觀，也在訪客會不會離站、網站多載入多少程式，以及後續能不能分派客服。

接法	費用	設定難度	能掛的通道	對速度的影響	適合誰
Messenger 的 m.me 連結按鈕	連結本身免費	低	Messenger	低，一般連結不載入聊天 SDK	只需要一個 Messenger 聯絡入口的網站
WordPress 多通道浮動按鈕外掛	依外掛與方案	低到中	依外掛支援範圍	低到中，需實測	要集中 Messenger、LINE、Instagram、WhatsApp、電話或 Email 的網站
第三方即時客服／共享收件匣	依服務方案	中	依服務整合範圍	中到高，需實測腳本與 iframe	需要站內對話、客服指派、標籤與報表的團隊

只有一個 Messenger 入口時，先做一般連結最省事。想讓訪客選擇不同通訊管道，可用 Chaty 這類多通道按鈕。需要留在原頁對話、多人分派或共享紀錄，才值得評估第三方客服系統。第三方系統的「Messenger 整合」不一定代表它能重建 Meta 舊版嵌入框，購買前要看清楚訊息實際送到哪裡、由誰保存。

不要同時把兩三套浮動元件塞在右下角。它們可能互相遮擋，也會重複載入樣式、事件監聽與追蹤碼。若業務上真的需要並用，至少分開位置與顯示頁面，並用手機、鍵盤和不同同意狀態完整測試。

多通道浮動按鈕的基本設定，可先看 WordPress 加 LINE 浮動按鈕教學，再把 Messenger 頻道換成已測試的 m.me 連結。

開始設定前，先把這四件事準備好

按鈕本身不難，容易卡住的是權限、連結和接手流程。上線前逐項確認：

1. 一個你有 Facebook access 的粉絲專頁。訊息會進到這個粉專的 Messenger 對話，至少要有人能查看設定、測試訊息並處理權限。Meta 說明指出，建立或修改粉專使用者名稱需要 Facebook access；只有 task access 並不足夠。
2. 使用 HTTPS 的網站。這是網站登入、表單與一般資料傳輸該有的基本條件。單純外連的 m.me 按鈕不需要舊版 Customer Chat 的網域白名單，也不需要貼 Facebook JavaScript SDK。
3. 一條真的能打開正確對話的連結。不要只在已登入的管理員電腦上測。用手機、桌機、無痕視窗，以及至少一個非管理員帳號確認。
4. 回覆責任。先寫下服務時段、負責人、預期回覆時間與無人值班時的自動回覆。按鈕有點擊卻沒人接，追蹤數字再漂亮也沒有用。

最常被略過的是第四項。若訊息送進一個沒人看的舊粉專，等於把詢問倒進封存信箱。還沒釐清訪客從接觸到成交的流程，可先畫一張 顧客旅程地圖，標出誰在什麼節點接手。

用 m.me 連結建立 Messenger 按鈕

這條路不載入舊版 Chat Plugin。訪客點擊後進入 Messenger 的對話入口，不會在 WordPress 原頁展開 Meta 對話框。

第一步：確認粉專使用者名稱與連結。Meta 說明指出，粉專使用者名稱會用在 facebook.com/username 網址，建立位置目前在「設定與隱私權 → 設定 → 粉絲專頁設定」的使用者名稱欄位；新粉專有時不能立刻建立使用者名稱（見 Meta 的粉專使用者名稱說明）。

看到一長串數字的粉專網址，不能直接斷定它「尚未設定使用者名稱」，因為同一個粉專可能同時能用 ID 與自訂網址存取。也不要把數字網址硬改成自己猜的名稱。最安全的做法是到粉專設定核對 username，或直接複製粉專目前提供的 Messenger 連結，再開啟測試。想要好讀、好記的網址，再設定可用的 username。

第二步：組出並測試連結。常用格式是 https://m.me/你的粉專使用者名稱。Meta 目前確認 username 會同步用在 Facebook 與 Messenger，變更後 facebook.com/username 與 m.me/username 都會跟著改（見 Meta Messenger 說明中心）。

不要把「手機有安裝 Messenger 就一定直開 App，沒安裝就一定到網頁版」寫成保證。App Links、預設瀏覽器、登入狀態、作業系統與 App 版本都可能改變落點。驗收標準應是手機與桌機都能抵達正確對話，不能只檢查網址外觀。

第三步：把連結加入 WordPress。可用按鈕區塊、導覽選單、自訂 HTML，或交給多通道聯絡外掛。若設定另開分頁，保留 rel="noopener"；按鈕最好有固定 class，例如 js-messenger-link，後面設定 GTM 會比較穩。

• 文案直接寫「用 Messenger 詢問」，不要只放一個沒有名稱的圖示。
• 手機版不能遮住結帳列、Cookie 選擇、返回頂端或無障礙工具。
• 導覽列、文章結尾與浮動按鈕若都使用 Messenger，應給不同 class 或位置參數。
• 測試粉專公開狀態、登入與登出狀態，也要確認陌生使用者是否能傳訊息。

?ref= 不是一般收件匣的 UTM。Messenger Platform 支援由 m.me 連結帶入 referral 資料，例如 https://m.me/你的粉專使用者名稱?ref=hero_button。Meta 的 webhook 文件說明，訂閱 messaging_referrals 後，使用者透過 m.me 或 ig.me 連結恢復對話時，系統會把事件送到已設定的應用程式 webhook。

這代表只有粉專與一般 Business Suite 收件匣，沒有 Messenger App、webhook 訂閱與儲存邏輯時，不能假設客服會在對話資訊裡直接看到 ref。目前可查到的官方 webhook 說明也沒有在該頁承諾 ref 的字數上限、允許字元或一般收件匣顯示方式，因此不在這裡硬填數字。實作時使用短、URL-safe、不含個資的代碼，並在測試環境確認 webhook 收到的 payload。只想量網站點擊，用 GTM 記錄通常更直接。

第四步：清快取並驗證。若按鈕或選單沒有更新，清除 WordPress 與 CDN 的必要快取，再用無痕視窗確認連結、粉專名稱、App／網頁落點，以及返回網站的動線。

用多通道外掛提供不同聯絡入口

客戶不一定都用 Messenger。Chaty 的 WordPress 外掛目前列有 Facebook Messenger、LINE、Instagram、WhatsApp、Email、電話等通道，免費方案也包含多個 click-to-chat 頻道、裝置顯示選擇、位置、CTA 與部分顯示觸發功能；精細頁面規則、分析或排程是否需要付費，應以安裝當下在 WordPress.org 外掛頁看到的版本與方案表為準。

設定時進入外掛的頻道選擇，加入 Messenger，再貼上已驗證的 m.me 網址。接著調整圖示順序、CTA、桌機／手機顯示與位置。外掛欄位若要求的是 username、粉專網址或完整 Messenger 連結，三者不能混著填；以該欄位的說明為準，存檔後檢查前台實際渲染出的 href。

Chaty 的 Messenger 頻道屬於 click-to-chat 入口，不等於恢復 Meta 舊版 Customer Chat。訪客仍會離開網站前往對應平台。這種方式的好處是可以把多個入口收在同一顆按鈕裡，代價是多一套外掛、樣式與 JavaScript，需要納入更新、無障礙、隱私與效能檢查。

聯絡按鈕與 Facebook Login 也是兩件事。若網站還要用社群帳號註冊，需分開評估登入權限、資料用途、帳號合併與維護成本，不能因為裝了 Messenger 按鈕就視為完成。

把聊天泡泡客製化成你品牌的一部分

按鈕上線後，至少檢查文案、位置、顯示條件與手機版面。外觀只要清楚一致，不必靠不停彈跳來搶注意力。

問候語寫清楚能處理什麼。「有問題歡迎詢問」資訊太少，可以改成「商品規格與到貨時間，可用 Messenger 詢問。服務時間為平日 9:00 至 18:00」。文案是否增加有效對話，仍要看自己的資料，可搭配 CTA 行動呼籲按鈕設計指南調整。

顯示時機跟著頁面任務走。文章頁可以常駐但不要自動展開，報價頁可在訪客看完方案後出現，結帳頁則應優先保護付款操作。不要把「停留 15 秒」當成通用答案；先看內容長度、頁面目的和誤觸情況。

位置要用實機檢查。手機右下角常同時有返回頂端、購物車、Cookie 橫幅與客服按鈕。只看桌機預覽抓不到這些衝突。WooCommerce 網站可對照 WooCommerce 購物網站架設全攻略，確保泡泡不蓋住加入購物車與結帳列。

配色要能辨識，也要有對比。沿用品牌色沒有問題，但不能讓圖示、外框或 focus 狀態消失在背景裡。品牌一致性不能凌駕可讀性。

無障礙：別讓鍵盤與螢幕閱讀器使用者被擋在門外

浮動按鈕本質上是連結或控制項。WCAG 2.1 的2.1.1（Level A）要求功能可用鍵盤操作，2.4.7（Level AA）要求鍵盤焦點可見；4.1.2（Level A）要求控制項的名稱與角色可由程式判定。用原生 <a> 或 <button> 通常比把 <div> 硬改成按鈕可靠。只有圖示時，可用 aria-label="用 Messenger 聯絡我們" 提供 accessible name；已有清楚可見文字時，不必重複堆 ARIA。

圖示與控制項必要視覺資訊對相鄰顏色至少要有 3:1 對比，對應 WCAG 2.1 的1.4.11（Level AA）。用 Tab 逐一走過頁面，確認泡泡能取得焦點、焦點外框看得見、Enter 能啟動，而且開啟後不會把焦點困住。

prefers-reduced-motion 適合用來停掉泡泡彈跳或位移，但要說準確：WCAG 2.1 的2.3.3「Animation from Interactions」是 Level AAA，不是 AA 的必備條款；W3C 把這個 CSS media query 列為可用技術。即使網站只以 AA 為目標，尊重減少動態偏好仍是實用做法。

這個泡泡不是真的免費：效能代價與 SEO 影響

一般 m.me 連結只是 HTML 連結，點擊前不需要載入 Meta 聊天 SDK。多通道外掛與第三方客服則可能增加 JavaScript、CSS、字型、iframe 和外部請求。到底多重，不能只看外掛宣傳頁，要在自己的頁面量。

Google 的速度文件指出，較慢的網站可能影響使用體驗與轉換，但改善幅度應以自己的數據驗證。

Core Web Vitals 會被 Google 排名系統使用，但 Google 也明確說，分數良好不保證排名；搜尋仍會優先呈現最相關內容，即使它的頁面體驗不理想。不要把移除一顆泡泡包裝成 SEO 排名保證（見 Google Search Central 對頁面體驗的說明）。LCP、INP、CLS 的測試方式可參考 Core Web Vitals 完全攻略。

測試時先留一份「未啟用客服元件」的基準，再啟用元件重測。Chrome 開發者工具的 Network 可看新增的網域、請求與傳輸量；Performance 可記錄載入與點擊泡泡的過程。火焰圖裡超過 50 毫秒的工作會被視為 long task（見 web.dev 的 long task 說明），但不要只數紅色標記，還要看它是否發生在使用者準備互動或點擊的時間。

INP 不是檔案大小測驗。Google 將一次互動拆成 input delay、event callback 的 processing duration，以及瀏覽器呈現下一幀前的 presentation delay。大檔案可能增加下載、解析與編譯成本；已載入的腳本若在點擊、輸入或動畫時做太多主執行緒工作，也會拖慢 INP。正確說法是「檔案大小與互動時執行成本都要查」，不能一口咬定問題往往只在其中一邊（見 web.dev 的 INP 最佳化與long task 最佳化說明）。

若外掛支援延後載入，先在測試環境比較。任意延遲第三方初始化可能讓第一次點擊沒有反應，也可能使追蹤事件漏掉。先讀供應商文件，再用 Lazy Loading 延遲載入實戰指南理解載入時序。快取可參考 WordPress 快取外掛推薦，整體效能則可對照 網站速度優化指南。

效能決策要跟業務資料一起看。若元件讓互動變慢，卻幾乎沒有帶來有效對話，就改回一般連結；若它確實接住重要詢問，便針對載入與事件處理優化。跳出率本身不能證明聊天泡泡造成離站，相關判讀可看 網站跳出率是什麼。

隱私與同意：聊天泡泡掛上去之前，先把合規想清楚

隱私風險取決於實作。一般 m.me 連結在點擊前不會因為這個連結本身載入 Meta 聊天 SDK；第三方客服、外掛分析或 iframe 可能在頁面開啟時發出請求、讀寫 cookie 或其他裝置資訊。不要依元件名稱猜用途，直接看瀏覽器 Network、Application 儲存項目與供應商文件。

若服務英國訪客，PECR 對 cookie 與其他裝置儲存／存取技術的基本規則是提供清楚資訊並取得同意；只有為使用者主動要求的線上服務所嚴格必要等情況才有例外。客服元件不能因為被叫做「客服」就自動歸為必要（見 英國 ICO 對 cookie 與類似技術的指引）。

實際檢查方式很簡單：先清除該網站的 cookie 與 local storage，在同意工具選擇「全部拒絕」後重新載入，再看客服供應商的請求與儲存項目是否仍出現。這只能驗證技術是否被攔截，不能單獨判定法律分類。若供應商、用途或服務地區涉及歐盟、英國或其他司法管轄區，應讓熟悉該地法規的人員確認。

在台灣，Messenger 對話只要包含姓名、聯絡方式或其他可直接或間接識別自然人的資料，就可能落入《個人資料保護法》的個人資料範圍。蒐集時需依實際情境處理告知事項、特定目的與安全維護，不能用一句「傳訊息即同意」概括所有用途（可對照 全國法規資料庫的《個人資料保護法》條文）。

一般對話不要要求訪客傳送完整信用卡資料、帳號密碼或不必要的證件影本。隱私權政策要列出實際使用的客服供應商、資料類型、用途與聯絡方式，不要從別站複製一份沒提到 Messenger 的模板。怎麼把第一次聯絡延伸成長期關係，可再看 內容行銷策略全攻略。

台灣市場的現實：Messenger 聊天泡泡，到底值不值得做

不要拿整體社群使用率直接替自己的網站做決定。網站訪客的年齡、產業、流量來源與購買情境，可能跟市場平均差很多。真正有用的資料是既有詢問從哪裡來、哪個按鈕有人點、哪個管道有人回，以及哪些對話走到報價或成交。

Messenger 已是粉專廣告與社群內容的主要收件匣時，網站加一個入口能延續現有流程。若粉專長期幾乎沒有訊息，先用成本低的 m.me 連結測試，不必急著買完整客服系統。想把整個粉專動態放進網站、讓訪客直接看得到，做法可參考粉專嵌入 WordPress。

LINE、Instagram 與 Messenger 各自有不同的帳號、權限與對話紀錄。多通道按鈕只是把入口收在一起，不會自動把所有訊息合併成同一個收件匣。團隊若沒有共享客服系統，仍要分別安排通知與負責人。

不知道該排哪個管道在前面，就查看近幾個月的客服來源、裝置比例與社群導流，再做一段時間的按鈕測試。這是在建立可用的目標受眾輪廓，可搭配 Persona 人物誌建立指南整理，不需要憑印象猜。

追蹤成效：怎麼證明這個泡泡真的帶來詢問

沒先設定追蹤，就只能知道「按鈕有裝」。觀察期應按網站流量與對話量決定，低流量站可能需要更久才看得出差異，不必硬套固定三個月。

一般 m.me 連結可用 Google Tag Manager（GTM）的「僅連結」點擊觸發條件，設定 Click URL 包含 m.me，再送出 GA4 自訂事件。GTM 官方文件確認 Click URL、Click Classes 與 Click Text 都是點擊觸發器可用的內建變數。

事件名稱可用 messenger_click，並帶上 link_url、link_text、page_location 或自行定義的按鈕位置。這些名稱屬於你的自訂量測設計，不是 Meta 或 Google 規定的必填 Schema 欄位。GTM 基礎可看 GTM Google 代碼管理工具新手攻略；WordPress 同時串 GA4 的流程在 WordPress GTM + GA4 串接教學。

具體設定可參考 用 GTM 追蹤通訊按鈕點擊，把條件改成 Messenger 連結或按鈕 class。發布前用 GTM Preview 真正點一次，確認觸發一次、不會重複送出，也不會誤抓頁面裡其他 Facebook 連結。

點擊不等於開始對話，更不等於成交。GA4 通常只看到訪客離站前的點擊；對方有沒有傳訊、客服有沒有回覆，需靠 Messenger 應用程式 webhook、客服系統或 CRM 串接。最低限度可由客服在成交紀錄中標記來源，再定期跟網站點擊比對。如何定義每一層轉換，可參考 行銷漏斗完全拆解。

訊息進來之後的那一哩路：別只掛按鈕，不接電話

按鈕上線只是起點。訊息分流、服務時段與後續紀錄，才決定這個入口能不能變成客服流程。

設定誠實的自動回覆。範例可以寫：「謝謝你的訊息。我們的客服時間是平日 9:00 至 18:00，非服務時間收到的訊息會在下一個工作日依序回覆。」不要寫「馬上回覆」卻讓對方等兩天，也不要假裝 24 小時都有真人。

訂出做得到的回覆時間。「五分鐘內回覆，成交率會提高多少」常被當成通則，但原始 Lead Response Management 研究分析的是六家公司的網路表單開發線索、超過 15,000 筆 leads 與 100,000 次電話嘗試，觀察指標是聯絡與資格判定，不是成交率。研究確實發現五分鐘與三十分鐘的聯絡、資格判定機率有大幅差距，卻不能直接外推到台灣 Messenger 客服、每個產業或實際營收（見 2007 年的 Lead Response Management 研究）。

這份研究能支持「新開發線索通常不宜拖太久」，不能支持「五分鐘內回 Messenger 就一定比較會成交」。客單價、決策週期、時區、問題難度、是否為既有客戶，以及對方選擇的管道都會影響期待。做法是公開可遵守的時間，並比較自己的首次回覆時間、有效對話率與成交率。

建立分流規則。把訊息分成售前疑問、報價需求、售後問題與客訴，指定負責人、回覆時限，以及何時改用電話或正式報價。訊息量一多，沒有分流就容易讓高價值詢問被閒聊淹掉。這套邏輯也可套進 Landing Page 轉換率優化全攻略的轉換路徑。

自動化只處理規則清楚的問題。營業時間、運費說明與公開庫存頁面可以用快捷回覆；退款爭議、醫療或財務資訊、特殊報價則應轉真人。要明確標示何時由真人接手，避免使用者以為自己正在跟客服人員對話。

準備開場範本，但不要只會貼罐頭。真人接手時先用一句話確認問題，再說明下一步，例如：「你想確認 A 商品本週能否到貨，對嗎？請提供配送縣市，我們查完回覆可到貨日。」這比只回「您好，請問有什麼需要」少一次來回。

常見踩坑與排解清單

排查時先測原始 m.me 連結，再查 WordPress。這樣可以快速分辨問題在 Meta 端、外掛設定或網站前台。

症狀	最可能的原因	解法
後台設好了，前台卻看不見	版型位置、顯示條件或快取尚未更新	檢查元件顯示條件、清除必要快取，再用無痕視窗測試
點擊後開到錯誤粉專或無法對話	m.me 值錯誤、粉專限制或登入狀態問題	先直接開啟完整連結，核對粉專 username、公開狀態與訊息權限
手機沒有直接開啟 Messenger App	瀏覽器、作業系統、預設連結設定或登入狀態不同	不要用是否直開 App 當唯一成功標準；確認訪客仍能抵達正確對話
訊息進來卻沒收到通知	粉專、裝置或管理工具的通知未開啟	檢查目前收件匣與裝置通知，再用非管理員測試帳號傳訊
行動裝置上泡泡擋住重要按鈕	沒有分開設定手機版位置	調整底部偏移或顯示頁面，避開結帳列、Cookie 橫幅與返回按鈕
頁面載入或點擊後明顯變慢	第三方請求、腳本評估、事件處理或版面計算增加	比較啟用前後的 Network 與 Performance 紀錄，找出實際網域與 long task
拒絕非必要 cookie 後泡泡消失	元件被同意管理工具歸在需同意類別	核對實際儲存、存取與用途，不要為了顯示泡泡就擅自改成必要類別
Tab 找不到泡泡，或螢幕閱讀器讀不出名稱	使用不可聚焦元素，或圖示沒有 accessible name	優先改用原生連結／按鈕，保留可見 focus，只有圖示時補適當 aria-label
GTM Preview 抓不到點擊	觸發條件與實際點擊元素不符	在預覽模式查看 Click URL、Click Classes 與 Click Text，再調整條件
?ref= 沒出現在一般收件匣	把 webhook referral 誤認為收件匣內建標籤	需要來源資料時設定 Messenger App、訂閱 messaging_referrals 並自行保存；只量網站點擊則用 GTM

第三方客服外掛還要看 Console 錯誤與 Network 請求。若停用外掛後問題消失，再查外掛衝突與供應商文件，不要直接重裝整個 WordPress。

這週就能動手的五步清單

把工作拆成五天，每天完成一個可驗收的結果：

1. 第一天：盤點條件。確認粉專 access、Messenger 連結、HTTPS、服務時段與負責人。缺任何一項都先補齊。
2. 第二天：選接法。只有 Messenger 就用 m.me；需要 LINE、Instagram、WhatsApp 等入口再用 Chaty；要站內對話與多人分派才評估第三方客服。
3. 第三天：上線按鈕。寫清楚文案與服務時間，設定桌機、手機位置，補上 accessible name 與可見 focus。
4. 第四天：處理效能、隱私與追蹤。比較啟用前後的請求和互動，測試拒絕同意狀態，再用 GTM 記錄點擊。
5. 第五天：走完整流程。用手機、桌機、無痕視窗與非管理員帳號，完成「點擊、傳訊、收到通知、真人回覆、紀錄來源」全流程。

觀察時同步看按鈕曝光、點擊、實際對話、首次回覆時間與成交。低流量網站要拉長觀察期；任何一環長期沒人維護，簡單的 m.me 連結通常比複雜客服腳本合適。

想往上游處理「網站為什麼會被找到」，可看 品牌官網架設全攻略；詢問進站後的長期經營，可從 WordPress 電子報外掛推薦開始。即時客服、內容與會員經營各有任務，不需要硬塞進同一個外掛。

要一起盤點 WordPress 外掛，可用 WordPress 外掛終極推薦清單做總體檢。外掛不是越多越完整；留下能被維護、能被量測，而且沒有擋住主要任務的工具就夠了。