WordPress 嵌入 Google 地圖：三種方法教學

在聯絡頁放一張 Google 地圖看似簡單，實作時卻常碰到尺寸不對、手機畫面擁擠或載入變慢。這篇要解的就是這件事，但這裡把順序倒過來講。

WordPress 嵌入 Google 地圖有三條常見路線：直接貼 Google 地圖提供的 iframe、用 Elementor 的地圖小工具，或由開發者使用 Maps Embed API 組網址。單純的聯絡頁通常先試前兩種；需要批次產生多個地點時，再評估 API。三種方式都應先確認位置資料，並在手機上檢查載入與導航體驗。若尚未完成網站基礎設定，可先參考WordPress 架站全攻略。

先講結論：嵌入地圖不難，但操作順序很重要

地圖顯示的地點未必等於你管理的商家檔案。若嵌入的是商家地標，先打開 Google 地圖檢查地址、店名與資訊卡，再回商家檔案核對可編輯欄位；若只是一般地址或自訂座標，仍要確認它指向正確入口。不要只看 iframe 在頁面上能顯示，就認定訪客找得到店。

如果嵌入的是可管理的商家地標，先核對 Google 商家檔案；若是一般地址或不符合建立商家檔案資格的地點，則以實際地址和入口驗收：店名、地址、營業時間與商家類別逐項確認，必要時補上能代表現況的照片。地圖只是把位置資訊視覺化呈現出來，源頭錯了，下游怎麼嵌都救不回來。

所以這篇的順序是：商家檔案先弄對，再來選嵌入方法，接著顧行動裝置和速度。順序顛倒時，常會因地址或版面問題返工。如果你時間有限、只想看方法，可以直接跳到後面的兩種方法段落；但如果你希望這張地圖真的幫網站帶來價值，建議照順序讀完。

嵌入之前，先把 Google 商家檔案補齊（這才是會被搜尋到的部分）

這裡要先破除一個常見誤解：在網站聯絡頁嵌一張 Google 地圖，不會因此保證商家排到在地搜尋前面。在地結果主要取決於 Google 所說的相關性、距離與知名度；商家檔案完整度與評論等資訊，也能協助 Google 與使用者理解商家（見 Google 商家檔案說明的本地排名提示）。結構化資料可補充機器可讀資訊，但不是排名保證。互動地圖的主要價值，是幫已到站的訪客快速找到位置、降低問路摩擦。

動手嵌入之前，至少把商家檔案裡這幾個欄位核對一次：

• 商家名稱：應使用顧客在招牌、網站等真實世界資料中認得的商家名稱，不要為了塞關鍵字而改成「台北最好喝的手沖咖啡‧咖啡館」這種過度優化的寫法，Google 對這類名稱作弊有明確規範。
• 地址：有供顧客造訪的實體地點時填寫準確地址與入口；到府服務商家則依商家檔案規範設定服務範圍及是否顯示地址。網址上的導航仍須實測，不能只憑欄位推定結果。
• 營業時間：節假日、臨時公休都要更新。地圖上顯示「營業中」卻撲空的客人，比給一星評論還傷。
• 商家類別：主類別要選最精準的那一個（例如優先選「咖啡館」，勝過籠統的「餐廳」），次要類別再補充。
• 電話與網站：電話要能點擊直接撥（行動裝置上尤其重要），網站連結指向你的首頁或聯絡頁。

更新商家檔案後，再重新查看要嵌入的地點與資訊卡。變更可能需要審核或一段時間才顯示，也不能假設任何嵌入碼都會自動綁定你的商家資料。沒有商家檔案時，先確認是否符合建立資格；本站的Google 商家檔案教學可協助釐清管理流程。

兩種嵌入方法的本質差異：一張表先看清楚

進入實作之前，先用一張表把兩種方法的差異攤開。建議你先判斷自己的站屬於哪一種情境，再往下讀對應的方法，才不會兩種都試、兩種都半調子。

為什麼要把方法拆開講，是因為 WordPress 生態實在太分散了。WordPress 長年佔全球網站內容管理系統市場的過半比重（依 W3Techs 2026 年 6 月的統計），這意味著用 WordPress 的人橫跨各種技術程度：有人用官方區塊編輯器加一個免費主題就上線，有人整站交給 Elementor 之類的頁面編輯器全權視覺化打造，也有人是工程背景、習慣自己控網址參數和 API 金鑰。同一個「嵌地圖」需求，落在這三種人手上會對應到三種截然不同的最佳做法，硬要叫所有人都用同一招，只會讓簡單的事變複雜。

一個簡單的原則：如果你只是要在聯絡頁放一張能點導航的地圖，方法 A 就夠了；如果你的整個形象站是用 Elementor 拉出來的，聯絡頁的每個區塊都要對齊同一套設計語言，那方法 B 才不會看起來格格不入。下面分別示範。

方法 A：用 Google 地圖內建的嵌入碼，零外掛搞定

這個方法的好處是完全不需要裝任何外掛，不管你用的是 Gutenberg 區塊編輯器、傳統編輯器，還是某個不知名的佈景主題，都能用。原理是從 Google 地圖網站產生一段 iframe 嵌入碼，再把它貼進 WordPress。

實際步驟如下：

1. 打開 Google 地圖：在瀏覽器前往 Google 地圖，在搜尋框輸入你的店名或地址。建議直接搜尋已經建好的商家檔案名稱，這樣地圖會精準對到你的標記，比單純輸入一個地址點更可靠。
2. 點「分享」再切到「嵌入地圖」：在左側資訊面板找到「分享」按鈕，點開後切換到「嵌入地圖」分頁。這裡會出現一段以 <iframe> 開頭的程式碼。
3. 預覽並選擇大小：視窗裡會即時預覽地圖樣子，你可以從下拉選單挑一個預設尺寸（小、中、大、自訂）。大多數情況選「中」或「自訂」填入你的欄位寬度最保險。
4. 複製 HTML：點「複製 HTML」，把整段 iframe 帶走。這段程式碼是 Google 地圖「分享 → 嵌入地圖」提供的 iframe；照原樣保留 src，無須自行加入 Maps Embed API key。若改用開發者 API 網址，才需自行配置受限制的 key。
5. 貼進 WordPress：進到你要嵌的頁面，如果你用的是 Gutenberg，加一個「自訂 HTML」區塊，把程式碼貼進去；如果是傳統編輯器，切到「文字」模式貼上即可。千萬不要貼在「預覽」模式，否則 iframe 會被當成純文字顯示出來。
6. 調整寬度到手機友善：把 iframe 裡的 width="600" 改成 width="100%"，這樣地圖會自動填滿容器寬度，在手機上不會超出螢幕。高度維持像素值即可。

做到這裡，桌機上預覽應該已經能看到一張可互動的地圖，能拖曳、能縮放、能點導航。方法 A 的最大優點就是它跟你的編輯器完全脫鉤，未來即使你把整站從 Gutenberg 換成別的編輯器，這段 iframe 依然有效。如果你對區塊編輯器的操作還不熟，可以先看這篇 WordPress 頁面編輯器把基本功打穩，嵌地圖這類操作會直覺很多。

一個小提醒：嵌入碼裡的網址會帶一組 pb 參數，那是 Google 用來還原地圖狀態的編碼，不要手動改它，也沒必要刪。把它整段原封不動貼進去就好。

方法 B：用 Elementor 的 Google Maps 小工具，視覺化掌控樣式

如果你的站是用 Elementor 蓋的，那麼用 Elementor 內建的 Google Maps 小工具會比貼 iframe 更順手。頁面上的位置、縮放和高度可從 Elementor 小工具面板設定；但目前官方流程要求先建立 API key、啟用 Maps Embed API 與帳單帳戶，並在 Elementor 的 Integrations 輸入 key。版面間距和視覺效果需另外按網站設計調整，不保證比直接嵌入一致。

Elementor 是目前 WordPress 生態常見的頁面編輯器之一，在 WordPress 官方外掛目錄就能免費下載。如果你還沒裝過任何頁面編輯器，正在比較選哪一套，可以先看 主流頁面編輯器比較 再決定；已經確定要用 Elementor 的人，建議搭配這篇 Elementor 使用教學 一起看，會更清楚小工具在整個編輯流程裡的位置。

Elementor 的 Google Maps 小工具設定步驟：

1. 進入 Elementor 編輯模式：打開你要編輯的聯絡頁，按「使用 Elementor 編輯」。
2. 找到 Google Maps 小工具：左側小工具面板搜尋「Google Maps」，把它拖進你要的欄位。小工具可用性依安裝版本確認；依 Elementor 目前官方文件，使用前仍須在 Elementor → Settings → Integrations 填入 Google Maps Embed API key，並啟用對應 API 與帳單帳戶。
3. 輸入地址：在右側「內容」分頁的「地址」欄位輸入你的店名或完整地址。小工具會依輸入的位置顯示地圖；地址或店名可能對到不同結果，應預覽並核對標記是否指向正確入口。
4. 設定高度與縮放：在「地圖高度」填一個像素值（聯絡頁常見落在 350 到 450 之間），「縮放」值調整預設顯示範圍。街道等級大約落在 15 到 17，太小看不到路名，太大反而看不到周邊地標。
5. 選擇地圖類型：目前 Elementor 官方 Google Maps 小工具文件列出位置、縮放和高度；地圖類型是否可選應以現行小工具介面核對，不要把 Maps Embed API 的 maptype 參數當成小工具選項。
6. 控制選項：目前 Elementor 官方 Google Maps 小工具文件沒有列出這些控制開關；應在實際版本確認可用選項，並以手機與鍵盤測試可操作性。
7. 樣式微調：切到「樣式」分頁，可以調整地圖容器的圓角、陰影、邊界，讓它跟周圍的聯絡表單、地址文字區塊看起來像同一套設計。

方法 B 相對方法 A 多了一個明顯好處：所有設定都存在 Elementor 的版型資料庫裡，未來要改地址、改高度，回去拖一拖就好，不用重新去 Google 地圖複製嵌入碼。如果你之後要做多語系、或多個分店頁，也能把這個地圖區塊存成範本重複套用，這部分可以參考 Elementor Cloud Templates 跨網站設計庫 的做法。想要更豐富的標記動畫、多點地圖、自訂圖釘這類進階效果，則可以透過第三方擴充，相關選擇在這篇 Elementor 外掛推薦 裡有整理。

進階第三條路：Maps Embed API 加 API Key，用網址參數產生地圖

除了上面兩種圖形介面方法，還有一條開發者路線：用 Google 的 Maps Embed API，自己組一段帶 API Key 的網址，直接放進 iframe 的 src。這條路的好處是地圖完全由網址參數控制，可以寫進範本、可以批次產生、可以放進版本控制，對多分店或多語系站特別好用。

官方的快速上手文件在 Google Maps Platform 的 Get Started 頁。基本流程是：在 Google Cloud Console 建一個專案、啟用 Maps Embed API、產生一把 API Key、把這把金鑰設好 HTTP 來源限制（只允許你自己的網域呼叫），再用類似下面的網址組出嵌入碼：

https://www.google.com/maps/embed/v1/place?key=你的金鑰&q=店名或地址&zoom=16

Maps Embed API 要求有效 API key，正式使用時應加上網站來源與 API 限制。Google 目前把 Embed API 列為免費、無日用量上限，但建立專案時仍需啟用帳單帳戶；同一專案若也啟用其他付費 Maps API，仍可能產生費用。不要把「Embed API 免費」誤讀成整個 Google Cloud 專案都不會計費。

三種方法選哪一個，可以用這個原則：單一聯絡頁、不想碰程式，選 A；整站 Elementor、要視覺一致，選 B；多分店、有開發資源、要可重現可版本控制，選 C。對絕大多數中小企業站長來說，A 跟 B 已經綽綽有餘，C 是規模化之後才需要碰的工具。

Maps Embed API 常用的網址參數

選擇方法 C 的人，把幾個關鍵網址參數搞懂，就能不用開 Google 地圖介面、純靠文字產生各種地圖樣貌。下面是實務上最常用的四個：

• q：查詢字串，可以放地址、店名或「緯度，經度」。可使用地址、地名或帶 place_id: 前綴的 Place ID；若同名地點多，Place ID 更能精確識別指定地點，上線前仍需核對預覽。
• center：地圖中心點的座標，格式是「緯度，經度」。當你想要地圖框住某個範圍、但標記不在正中間時特別有用，例如把店標記稍微偏左，右邊留白放文字說明。
• zoom：縮放層級，數字越大越近。街道視角大約落在 15 到 17，整個城市等級落在 11 到 13。聯絡頁通常要讓人看得到周邊路名，所以抓 16 左右最實用。
• maptype：地圖類型，roadmap 是路線圖、satellite 是衛星圖。聯絡頁可先用預設 roadmap，再依位置特性與讀者需求測試 satellite 是否有幫助；避免把視角選擇當成絕對規則。

把這些參數組合起來，你可以為每一個分店用同一支範本批次產生地圖網址，地址從後台或試算表讀進來就行，不必每一張都手動去 Google 地圖拉。這正是方法 C 真正的價值所在，也是它跟前兩種圖形介面方法最大的分野。

Maps Embed API 目前可免費使用，官方文件標示沒有每日請求上限，但仍需要 API Key，且必須遵守 Google Maps Platform 服務條款（見 官方的用量與計費說明）。金鑰仍應設定網站來源與 API 限制，並定期查看用量，及早發現未授權呼叫。

地圖嵌入是隱形的效能殺手：先看數字再決定要不要嵌

講完怎麼嵌，接下來要談容易被忽略的載入成本。Google 地圖嵌入不管是 iframe 還是頁面編輯器小工具，本質上都會在頁面裡載入第三方地圖應用程式，包括 JavaScript 與地圖圖磚，實際傳輸量與主執行緒成本要用瀏覽器工具量測。

頁面載入慢、互動卡頓，可能反映在 Core Web Vitals 指標上。這些指標是眾多排名訊號中幅度較小的一項，更直接的用途是幫你找出真人使用時的等待與卡頓（可對照 Google 於 2020 年 11 月的 頁面體驗時程說明）。Google 的 web.dev 也整理了速度與使用者體驗、轉換之間的研究。

換個方式想：地圖嵌入就像在網頁裡開了一扇通往另一個複雜應用程式的窗，那扇窗一打開，瀏覽器就要同時跑你的網站和地圖程式兩邊的工作。在桌機寬頻下你感覺不明顯，但在手機的 4G、5G 環境下，或訪客訊號不穩時，這個負擔就會變成實實在在的等待時間。如果你的聯絡頁除了地圖還嵌了聯絡表單、圖片輪播、社群動態，整頁加起來的載入壓力會更快被感受到，行動裝置的使用者會最先察覺。

所以建議：嵌之前先量一次頁面速度當作基準，嵌進去之後再量一次，看看分數掉了多少。量測工具和讀數判讀可以參考這篇 載入速度優化全攻略。如果嵌入之後 Core Web Vitals 明顯下滑，那就該用接下來這幾個方法補救，放著不管只會讓問題慢慢累積。Core Web Vitals 跟排名的關聯，可以進一步對照這篇 Core Web Vitals 與 SEO 的解析。

讓嵌入地圖變輕的三個做法（延遲載入、靜態圖替代、精簡載入）

如果你發現地圖嵌入確實拖慢了頁面，有幾個從輕到重的做法可以選。這裡把它們列成三個層次，你按自己能接受的複雜度挑一個來做就好。

第一個做法：延遲載入（lazy load）。原理是讓地圖一開始不要載入，等到使用者滾動到附近或主動點擊後才拉取。實作上可在 iframe 使用 loading="lazy"，或採 facade 模式，先放一張經授權的靜態地圖或簡化位置卡片，點下去才載入互動地圖。延遲載入的通用觀念可延伸閱讀 延遲載入與網站效能。

第二個做法：用靜態位置卡片取代互動地圖。如果聯絡頁不需要拖曳、縮放，可以直接顯示地址、地標提示與「打開 Google 地圖導航」按鈕。若要顯示 Google 地圖圖片，可評估 Maps Static API 或其他授權允許的輸出；Static API 需要 API key、啟用帳單帳戶並按用量計費，不能把它當成免費截圖替代。不要自行截圖後當成可任意重製的素材。圖片本身的優化觀念可以對照 WordPress 圖片優化指南。

第三個做法：避免同區堆疊重型第三方元件。關閉控制項不一定會明顯減少地圖下載量，快取外掛也無法完整控制第三方 iframe 裡的資源。較可靠的策略是讓地圖延遲載入，並避免在附近同時放入影片、社群牆或大型輪播，再以 Network 與 Performance 面板驗證結果。

延遲載入、位置卡片與互動地圖不必依桌機或手機硬性分流。先看讀者是否需要在頁面內拖曳地圖；若只需查看地址與開啟導航，文字位置卡片可能更直接。若保留互動地圖，讓地址、電話與導航按鈕先於地圖出現，並以真實手機和效能量測確認結果。

嵌入地圖能不能幫你排名？把話說清楚

這一段要很誠實地回答一個很多老闆會問的問題：「在網站放一張 Google 地圖，SEO 分數會不會加分？」答案是：直接幫助很小，間接幫助看你怎麼用。

Google 公開的在地排名說明並未把「網頁有沒有嵌地圖」列成一項保證加分。應優先維護正確完整的商家檔案、評論與網頁上可見且一致的商家資訊；LocalBusiness 等結構化資料用來協助機器理解內容，不應包裝成排名槓桿。若嵌地圖只是為了提升排名，這個期待沒有可靠依據。

地圖的間接價值在於降低訪客找路、致電或留下詢問的摩擦，這是轉換改善，不應包裝成停留時間、跳出率或評論會回頭推升排名。真正需要經營的是商家檔案、可見且一致的商家資訊，以及能回答在地需求的頁面內容。結構化資料可參考 結構化資料 SEO 指南；轉換流程則可對照 提升網站詢問量。

地圖之外，聯絡頁該補的 LocalBusiness 結構化資料

既然講到結構化資料，順手把聯絡頁最該補的欄位列出來。用 LocalBusiness 這個類型（餐飲業可以再用更精準的 FoodEstablishment 或 Restaurant，服務業有 ProfessionalService），先讓頁面上的商家資訊清楚可見，再依 Google LocalBusiness 文件標記適合的欄位；其中 name 與 address 是該類型的必要屬性，電話、營業時間與 geo 為建議屬性，不是缺一不可的排名清單：

• name：商家名稱，跟商家檔案、網站 footer 完全一致。
• address：用 PostalAddress 結構拆成 streetAddress（門牌）、addressLocality（城市）、postalCode（郵遞區號），比一段純文字地址更容易被正確解析。
• telephone：電話號碼，建議帶國碼格式（+886...），方便搜尋引擎跨地理解。
• openingHoursSpecification：營業時間，用結構化的方式標出每天幾點開、幾點關。
• geo：經緯度座標，若提供 geo，座標應與實際商家位置一致；Google 將它列為建議屬性，但未保證加入座標會提升定位或排名。
• url：官方網站網址，指向首頁或聯絡頁皆可。

這份標記應和 Google 商家檔案、網頁上可見的 NAP 文字與地圖座標保持一致。結構化資料能讓機器更明確地理解商家資訊，但不保證特定搜尋版型或排名提升。

尺寸或載入成本過高，首先損害的是訪客找地址與聯絡店家的體驗。Google 沒有把地圖嵌入列為直接的在地排名加分項，也不能因一次 Core Web Vitals 變動就推斷排名升降。調整前後應分別量測頁面速度與訪客操作，確認地圖是否真的有幫助。

手機上的地圖：別讓它在小螢幕上變成災難

全球行動裝置佔網頁流量的比例長期維持在高檔（依 Statista 的統計）。Google 也已完成行動優先索引，也就是主要使用行動版內容建立索引，不是替行動版加一個獨立排名分數（見 Google Search Central 於 2023 年 10 月的 Mobile-first indexing 公告）。使用者若多半用手機找路，實機測試就不能省略。

手機上的地圖嵌入最容易出現三個問題，下面各自給出解法：

問題一：地圖寬度超出螢幕。症狀是地圖右邊被切掉、頁面出現橫向捲軸。原因是 iframe 的 width 寫死成像素值。解法是把 width 改成 100%（方法 A），或在 Elementor 小工具把欄位寬度設成自動填滿（方法 B）。這是最基本也一定要修的。

問題二：地圖高度太高，擠掉其他資訊。症狀是手機上一打開聯絡頁，整個第一螢幕被地圖佔滿，地址和電話反而要往下捲才看得到。解法是在行動裝置把地圖高度設小一點（例如桌機 450、手機 280），Elementor 可以直接在響應式設定裡針對手機單獨設高度。手機使用者的優先順序是地址、電話、導航按鈕，地圖是輔助，不該搶第一視覺。

問題三：點了地圖沒辦法直接導航。症狀是使用者得自己在地圖裡找「路線」按鈕。更好的做法是在地圖正下方放一個明顯的「導航到這裡」按鈕，連結直接指向 Google 地圖的導航模式（商家檔案的導航連結即可）。多一次點擊就多一次流失，手機使用者尤其沒耐心。響應式設計的整體觀念，可以延伸看這篇 響應式網頁設計。

這三個問題其實都指向同一個設計原則：手機版的聯絡頁要以「最快讓客人找到你、聯絡你、導航到你」為目標，單純把桌機的排版等比例縮小塞進小螢幕是行不通的。每多一個阻礙，就會少掉一批本來會上門的客人。

實際專案裡的選擇清單：什麼情境用哪一種

到底該選哪一種？接下來這張決策表不是標準答案，而是依需求、維護能力與效能成本整理的起點，你可以直接對照自己的狀況。

會需要做這種分類，是因為嵌入式地圖沒有「一種打法走天下」這回事。一個賣手沖咖啡的單店小店，跟一個有十個分站的連鎖餐飲品牌，需要的解法完全不同。搞清楚自己的規模和需求再選，才不會陷入「別人用 Elementor 所以我也用」這種複製貼上思維。如果你想從更上層的角度理解為什麼在地店家的網站要這樣配置，這篇 形象網站對企業的價值 有完整的討論；正在規劃整站架構的人，則可以對照這篇 用三個層次把 WordPress 形象網站搭起來 的流程，把聯絡頁這個環節放進整體藍圖裡看。實際上，類似的「在哪個頁面嵌哪種外部內容」的判斷，也適用於嵌入 Facebook 粉專或 Google 表單這類需求，做法可以互相參考 WordPress 嵌入 Facebook 跟 WordPress 嵌入 Google 表單。

嵌完之後的五分鐘檢查清單

收在這裡的，是一份嵌完地圖之後一定要跑一次的檢查清單。清單不長，但每一項都是實務上常見、出問題會讓客戶立刻發現的項目。花五分鐘照著走一遍，能幫你擋掉絕大多數的低級錯誤。

1. 換手機實際打開聯絡頁：不要只看桌機預覽。用自己手機開一次，確認地圖寬度不超出螢幕、高度合理、沒有橫向捲軸。
2. 確認地圖標記位置正確：對照你的實際門牌，標記有沒有偏到隔壁巷子。若是你管理的商家檔案資料有誤，先依權限提出更正，再重新打開嵌入頁驗證顯示結果；一般地址點或錯誤標記也可能需要另行修正，不能假設原 iframe 立即自動更新。
3. 點一次導航：從地圖或導航按鈕點進 Google 地圖導航模式，確認規劃的路線確實能到你的店。
4. 量一次頁面速度：嵌入前後各量一次，分行動版跟桌機版。如果行動版明顯變慢，回頭套用延遲載入或改靜態圖。
5. 檢查 NAP 一致性：地圖上的店名、地址、電話，要跟頁面上的文字、footer、商家檔案完全一致。四邊對不起來是在地 SEO 的大忌。
6. 檢查結構化資料：若頁面使用 LocalBusiness 結構化資料，讓店名、地址、電話、營業時間與 geo 座標和可見內容一致。它能協助搜尋引擎理解商家資訊，但不保證排名提升。
7. 放一個明顯的導航與致電按鈕：手機上「點擊撥號」跟「一鍵導航」要在第一螢幕就看得到，別讓使用者還要在地圖裡翻找。

完成後請用手機實際走一次：地址是否看得到、導航是否到正確入口、電話是否可點擊、地圖是否擋住其他聯絡資訊。這些是可驗證的使用體驗，比推測地圖本身會帶來多少搜尋流量更有用。

把地圖嵌入做好，背後其實是一套完整的在地數位經營思維：商家檔案是源頭，網站嵌入是出口，結構化資料和行動體驗是中間的橋樑。任何一環漏了，整個鏈條就鬆了。下次需要為聯絡頁加地圖時，就能依這四個環節逐項完成，不必只在 iframe 寬度上反覆試錯。

若只需要一張聯絡頁地圖，從 Google 地圖的分享嵌入碼開始即可；Elementor 網站可比較小工具的維護便利性，多地點批次管理再考慮 Embed API。上線前核對資料、手機版與載入成本，之後地點或營業資訊異動時再回頭檢查。