WordPress 多語系外掛：Polylang、WPML 深度評比

網站要增加英文版，除了翻譯正文，還要決定語言網址、選單、內容更新與校稿流程。翻譯外掛若設定不當，可能讓目標語言頁無法被檢索，或讓搜尋者進入不合適的版本；先釐清需求，才能避免上線後重做。

在多語系網站的 SEO 診斷裡，最常見的狀況之一是「裝了翻譯外掛就以為沒事、三個月後才發現英文版根本沒被收錄」。這篇把 WordPress 上五款主流多語系外掛（Polylang、WPML、Weglot、TranslatePress、GTranslate）一次講清楚。不是那種列五個優缺點就結束的流水帳，而是從 SEO 決策的角度，告訴你每一款在什麼情境下是正解、什麼情境下是地雷。如果你想深入了解單一外掛的操作，站內另有 Polylang 完整教學 與 TranslatePress 多語系教學，這篇則把重心放在「怎麼選」這件更關鍵的事。

重點摘述：依翻譯產能與預算選擇

先講重點。如果你沒時間看完，可先對照這張決策表縮小範圍；選翻譯外掛不是選「最強的」，而是選「跟你的翻譯產能、技術能力、預算結構最對得上的」。

這張表是給「現在就要做決定」的人用的。但如果你願意多花十分鐘把後面的技術脈絡看懂，你會知道為什麼同一款外掛，在不同人手裡會有完全不同的命運。

為什麼該把翻譯外掛當成 SEO 決策，而不只是技術設定

很多人把多語系當成「把中文內容翻成英文，再掛一個語言切換按鈕」就結束了。這個想法在五年前或許還行，但在今天，多語系網站的本質是用一套新的語言版本，去搶另一個語系搜尋結果的排名。它是 SEO 基礎建設，不是裝飾品。

如果已驗證其他語言市場有需求，多語系可以成為擴張流量與服務範圍的工具；它不是所有長期網站的必選項。技術設定出錯的代價較高，常見原因有三個：

• 語言版本的收錄問題：英文版頁面如果技術上不讓 Googlebot 抓得到，那它等於不存在，你翻了等於白翻。
• 語言與地區的對應關係：可用語言代碼服務所有該語言讀者，只有內容針對特定地區時才加地區代碼。這牽涉到 hreflang 多語系標記 的正確設定。
• 標準網址設定：不同語言的實質翻譯通常不是重複內容，也不會因此受罰；各語言頁通常應使用自我 canonical，再用 hreflang 串起對應版本。錯把英文頁 canonical 到中文頁，才可能讓英文網址不被當成主要版本。

換句話說，翻譯外掛不只是一個「把 A 語言變成 B 語言」的工具，它同時要負責把 hreflang、網址結構、sitemap、語言切換、收錄控制這整套技術 SEO 做對。這也是為什麼五款外掛之間的差距，關鍵往往落在「SEO 基礎建設做得扎不扎實」，而單純比較誰翻得準其實是搞錯了重點。在挑外掛之前，你應該先把網站層級的 WordPress SEO 全攻略 想清楚，否則多一個語言只是多一個出錯的機會。

五款外掛到底差在哪：先把三種技術路線講清楚

市面上絕大多數的比較文，都是一款接一款介紹，看完你腦袋裡還是一團漿糊。實務上不妨換個方式想：與其記住五個產品，不如記住它們背後的三種技術路線。路線選對了，產品只是細節。

路線一：原生資料庫多語系（Polylang、WPML）

這條路的運作邏輯是：每一篇文章、每一個頁面，都會「複製」出對應語言的獨立版本，各自擁有一組獨立的網址、獨立的內容、獨立的標題與中繼資料。舉例來說，同一篇「關於我們」：

• 中文版：yourdomain.com/about
• 英文版：yourdomain.com/en/about
• 日文版：yourdomain.com/ja/about

各語言版本可有獨立網址，譯文存於自己的 WordPress 資料庫，方便自主備份。實際收錄仍取決於可檢索性與內容品質。成本要合計授權續約、自動翻譯用量、人工校稿及維護；本地儲存不等於長期成本必然最低。

Polylang 免費版提供基本多語內容管理，Pro 增加 DeepL 自動翻譯等功能，WooCommerce 整合另有產品。WPML 則採付費方案，翻譯管理、電商與頁面編輯器支援依方案區分。

路線二：視覺化前端翻譯（TranslatePress）

TranslatePress 也是把翻譯存進資料庫、產生獨立網址，但它以字串翻譯為主，不是為每種語言建立一份文章副本。它最大的差別在操作體驗：你不用進傳統的字串翻譯表格，而是開啟一個「所見即所得」的前端介面，直接在網站畫面上點你要翻的文字，當場輸入翻譯。對於非工程背景、看到程式碼就頭痛的內容經營者來說，這條路友善很多。

路線三：託管與即時翻譯（Weglot、GTranslate）

這兩款不能完全視為同一種實作。Weglot 以託管翻譯與可索引的語言網址提供 SEO 版本；GTranslate 免費版主要在瀏覽器即時翻譯，付費方案才提供可索引網址等 SEO 功能。實際渲染與代理方式應依當前方案文件確認。

這類服務可先自動翻譯，再由團隊人工修訂。成本依方案、字數、語言數與功能而異，機器初稿仍需安排校稿。Weglot 有小額度免費方案，也有月繳與年繳方案；GTranslate 的免費與付費服務另有用途及 SEO 功能差異。

把這三條路線記住，後面每一款外掛的優缺點，你都能對應回來理解，而不是死背功能表。

真正會咬人的成本是翻譯產能，不是外掛授權費

這件事必須講在比較表前面，因為它是絕大多數人多語系專案翻車的真正原因。一個多語系網站的長期成本結構，拆開來看是這樣的：

• 外掛授權或訂閱費：這是看得到、最容易比較的開銷，但它通常只佔總成本的一小部分。
• 翻譯人力成本：每一篇文章、每一個產品頁、每一封通知信都要翻，而且不是翻一次就結束。你每新增一篇中文內容，就要同步產出其他語言版本，這是一筆持續產生的隱性支出。
• 維護與校稿成本：機器翻譯要人工校、人工翻譯要品管、術語要統一、商品價格與庫存的語言同步要保持。這些都是長期工程。
• 技術維運成本：hreflang 要定期覆檢、收錄狀態要追蹤、外掛更新可能破壞既有翻譯結構，這些都要有人盯著。

很多團隊在挑外掛時，只盯著授權費比價，卻忽略了翻譯產能才是那個會持續膨脹的大宗。舉個具體的盤算方式：假設你有一百篇文章要做英文版，每篇平均翻譯加上校稿要一個小時，那就是一百個小時的人力。用機器翻譯先跑再人工校稿，或許能壓到三十小時，但三十小時依然是實打實的人力支出。你選 Polylang 省下的授權費，可能在頭三個月的翻譯工時裡就被吃掉了；你選 Weglot 換來的上線速度，也可能在第六個月被疊加上去的訂閱費追平。

先估計每月新增字數、目標語言與校稿工時，再用少量核心頁面試跑完整流程。可以採託管服務，也可以直接使用本地外掛；若未來可能搬遷，應先確認翻譯匯出格式、語言網址及還原方法。先用雲端再搬回本地不一定更省。

Polylang 深度評：免費主力，但你的耐心要夠

Polylang 是 WordPress.org 上最被信賴的多語系外掛之一，免費版就能做到完整的獨立網址、獨立收錄與 hreflang 自動輸出（見 Polylang 的 WordPress.org 外掛頁）。它的核心邏輯是「每個語言都是獨立的一套內容」，免費版主要由編輯建立與維護各語言內容；Pro 另提供內容複製、同步及 DeepL 自動翻譯。

它的強項：

• 免費版可建立語言內容、網址、hreflang 與切換器；進階網址及編輯功能依 Pro 功能表確認。
• 譯文存於自己的資料庫，可自行備份；若使用自動翻譯，仍涉及對應外部服務與費用。
• 可用既有 WordPress 編輯流程管理內容，主題、快取與外掛相容性仍需測試。

它的代價：

• 免費版以人工建立與校稿為主；Pro 提供 DeepL 翻譯等輔助，內容量大時仍要安排驗收。
• Polylang Pro 與 Polylang for WooCommerce 是不同產品，可依需求購買或選組合方案。
• 文章與頁面使用 WordPress 編輯流程，主題及外掛文字則有字串翻譯管理。

老實說，Polylang 適合「有翻譯人力、想長期養多語系流量、不想被月費綁住」的團隊，是這類需求的第一推薦。免費版能省下基礎授權費，但翻譯、校稿及進階功能仍要編列預算。如果你的網站是用 Astra 或 Elementor 架的，仍要測試語言切換、版型與動態內容；Polylang Pro 的 DeepL 整合目前不支援 Elementor 建立的內容，不能把 Pro 自動翻譯視為其替代流程，可以參考 Astra 主題教學 裡的搭配觀念。一個實務上的小提醒：用 Polylang 時，一開始就要把每種語言的固定網址結構（例如 /en/、/ja/）定清楚，因為它會貫穿整個網站的網址，事後調整等於要重做一遍內部連結，非常傷。

WPML 深度評：老牌付費王者，代價是費用與複雜度

WPML（The WordPress Multilingual Plugin）是提供多語內容管理與翻譯工作流程的付費外掛（WPML 官方網站）。它跟 Polylang 走同一條「原生資料庫」路線，但多了完整的翻譯工作流程：你可以指派翻譯給不同帳號、外包給專業翻譯服務、批次管理翻譯進度。

它的強項：

• CMS／Agency 方案提供電商及頁面編輯器支援，WooCommerce 商店仍要驗證實際擴充功能。
• 翻譯管理與團隊協作適合有分工需求的網站，入門 Blog 方案不包含這些進階工具。
• 可先查官方相容性目錄，再測試主題、外掛、快取與完整結帳流程。

它的代價：

• 純付費，採年度方案，不同方案有不同的站點數與功能，購買前可直接查 WPML 定價頁。擴張前要核對目前授權範圍與自動翻譯費用。
• 設定介面龐雜，新手第一次設定會被一堆選項淹沒。
• 它是重量級外掛，搭配不當的快取或主機時，對效能會有可察覺的影響。

WPML 的定位很清楚：它是給「把多語系當成正式業務、願意為了工作流程與相容性付錢」的成熟網站用的。如果你只是想加個英文版試水溫，WPML 會讓你覺得殺雞用牛刀。但如果你正在架設一個多語系 WooCommerce 購物車，產品多、分類雜，可把 WPML 列入測試名單，逐項核對商品、變體、通知信與金物流流程。

Weglot 深度評：託管翻譯與訂閱成本

Weglot 走的是雲端代理路線，提供自動翻譯與人工校稿介面。你安裝外掛、填入 API key、選擇要翻譯的語言，可在方案額度及設定範圍內建立語言版本，並檢查各語言網址的檢索與收錄狀態（Weglot 官方網站）。之後你可以進後台針對每一段文字做人工校稿。

它的強項：

• 可用自動翻譯產生初稿，減少逐頁建立譯文的操作。
• 可在服務介面人工修訂，仍需確認專業術語與重要交易資訊。
• 提供語言網址與 hreflang 等功能，網址 slug 翻譯等進階項目依方案確認。

它的代價：

• 月費／年費訂閱，按字數或語言數計價。網站內容越多、語言越多，費用越高，而且這是持續支出，不是一次性成本。
• 翻譯內容由 Weglot 服務託管。採用前要確認匯出、終止服務、資料保留與搬遷條款，並保留自己的來源與校稿資產。
• 機器翻譯的品質上限取決於引擎，專業或技術性內容仍需大量人工校稿。

Weglot 把部分工程與初始翻譯時間換成訂閱費，內容與語言增加時可能需要升級方案。WPML 同樣採年度授權，並非一次買斷；長期成本應用目前價格、字數、語言數、人工校稿與搬遷需求一起試算，不能預設哪一款一定較便宜。

TranslatePress 深度評：所見即所得，最適合非工程背景

TranslatePress 的將譯文字串存於本地資料庫，並提供語言網址，與每種語言各建文章的模型不同，但它把操作體驗做了徹底翻轉。你不用碰字串表格，而是開啟一個覆蓋在網站前端的翻譯介面，游標點到哪一段文字，就跳出輸入框讓你翻譯（TranslatePress 官方網站）。翻完存檔，畫面立刻更新。

它的強項：

• 可在前端畫面檢視上下文並修訂譯文。
• 免費版支援一個追加語言及 WooCommerce，也可使用自備 Google Translate API key；API 費用另計。更多語言、SEO Pack 與 DeepL 整合屬付費功能。
• 譯文存於本地資料庫；付費授權及自動翻譯額度仍需依方案計算。

它的代價：

• 內容量大時，要評估逐頁編輯與自動翻譯後校稿的工時。
• 付費版本依方案包含不同附加功能及 AI 額度，應以完整需求核對方案，而非假設每項都單獨販售。
• 高度客製化的主題、Ajax 畫面或頁面編輯器輸出仍要逐頁驗證。

TranslatePress 適合希望在實際畫面校稿的團隊。若要翻譯 SEO 標題、描述、slug 等資料，應一併評估付費 SEO Pack；只有前端文字翻好，仍不代表多語搜尋設定已完成。

GTranslate 深度評：免費服務的用途與索引限制

GTranslate 提供語言切換與即時翻譯，免費版裝上去、放一個語言切換器，訪客一點就能切到其他語言（見 GTranslate 文件）。依目前服務條款，免費服務限個人、教育、內部測試、非營利或政府等允許用途，商業或營利用途須採付費訂閱。

GTranslate 免費服務主要在訪客瀏覽器即時翻譯，沒有供搜尋引擎索引的獨立翻譯網址。限制來自這個方案的網址與服務設計，不能概括成 Google 無法索引 JavaScript 內容。

若目的是經營外語自然搜尋，應評估有獨立語言網址、hreflang 與中繼資料翻譯的方案。GTranslate 付費服務提供這類 SEO 功能，也允許人工修訂，可和其他產品一起比較成本與管理方式。

選 GTranslate 時先分清免費服務與付費方案，再確認商業用途、語言網址、人工校稿與終止服務的安排。付費版本身也是多語網站的候選，不必只因免費版限制就排除整個產品。

五款橫向比較：一張表看完關鍵差異

把前面拆解的細節收斂成一張總表。這張表回答的是：當你把「費用模式、SEO 結構、翻譯人力需求、上手難度、適合場景」擺在一起，五款的相對位置長怎樣。

以 SEO 為目的時，要確認方案能提供可檢索的語言網址，再逐頁檢查內容、canonical 與 hreflang。有網址只是技術基礎，搜尋引擎仍會自行判斷是否收錄及如何排序。

多語系 SEO 的三個地雷，選錯外掛也救不回來

就算你選對了外掛，還有三個 SEO 地雷是外掛幫你做好基礎、但你要自己確認沒踩到的。這三個地方，是多語系網站「明明翻了、卻沒流量」最常見的根本原因。

地雷一：hreflang 標記設錯或漏設

hreflang 是告訴 Google「這個頁面是給哪個語言、哪個地區的讀者看」的標記。它協助 Google 對應語言版本；Google 仍會從內容判斷語言，沒有標記也可能找到其他版本。大多數外掛會自動產生 hreflang，但你要確認它產生的是雙向的（A 指向 B，B 也要指回 A），而且語言代碼與地區代碼是對的。這件事的完整設定邏輯，可以對照 hreflang 多語系 SEO 手冊 來檢查。

地雷二：網址結構與子網域／子目錄的選擇

多語網址常見子目錄（/en/）、子網域（en.domain.com）與獨立網域。子目錄便於集中部署；子網域與獨立網域可分開管理，但會增加設定與維護工作。應依主機架構、市場及人力決定，並安排各語言網址的檢索驗收。可先比較 子網域與子目錄，並在變更前安排網址對照與轉址。

地雷三：語言版本的行動裝置體驗

Google 已全面採用行動優先索引，主要以行動版內容進行檢索與建立索引，此一轉換在 2023 年 10 月的 Google Search Central 公告中有完整說明。這不是額外排名加分，但多語系網站仍要確認各語言在手機上內容完整、切換器可用、版面沒有跑位。

多語 SEO 也要檢查搜尋者看到的標題與描述。像 Backlinko 的 Google CTR 統計 這類第三方研究可提供觀察方向，但不能直接預測自己網站的點擊率。應用各語言的 Search Console 查詢、曝光與點擊資料，調整符合搜尋意圖的 網址與 SEO 標題。

WooCommerce 多語系：電商站的特殊考量

如果你的網站是 WooCommerce 電商，多語系的複雜度會再上一個台階。因為電商內容不只是文章，還有商品頁、變體、結帳流程、email 通知、稅務與運費設定，這些全部都有翻譯需求。可先評估以下兩種內容管理方案，再與其他支援 WooCommerce 的產品比較：

• WPML 搭 WooCommerce Multilingual：需搭配包含電商功能的 WPML 方案；按商店需求驗證商品、分類、屬性、結帳與擴充外掛。
• Polylang 搭配 Polylang for WooCommerce：電商整合需另用對應付費產品，適合願意自行測試商品、變體、結帳與信件流程的團隊。

Weglot、TranslatePress 與 GTranslate 也提供 WooCommerce 相關功能。無論選哪款，都應測試變體、促銷價格、庫存、付款、物流與通知信，不宜只由譯文存放位置判定交易資料是否可靠。產品頁內容與搜尋呈現可延伸閱讀 WooCommerce 產品頁 SEO。

多語系外掛的效能代價：別讓翻譯拖垮你的 Core Web Vitals

本地與託管翻譯都可能影響前端效能，實際瓶頸要量測。可先理解 Core Web Vitals 的 LCP、INP、CLS，再比較各語言版本的載入、互動與版面穩定性；不宜直接把外掛架構當成效能結論。

不同路線可能有不同瓶頸：託管翻譯可能增加網路與代理處理，原生路線則可能增加資料庫查詢。實際影響取決於快取、CDN、主機與產品實作，不能直接斷言某一路線一定拖慢 TTFB、LCP 或 INP；上線前後要用相同網址與條件量測。

多語系頁面應檢查的三種效能問題

• 語言切換器的 CLS：切換按鈕如果是用 JS 在頁面載入後才插入 DOM，按鈕出現的瞬間會把下方內容往下推，產生累計版面位移。單語網站的動態元件也可能有相同問題，應預留空間或調整插入方式。
• 動態文字替換的 INP 風險：若方案確實在前端執行大量字串替換，可能增加主執行緒工作；互動效能可用實際操作與 INP 資料量測（見 web.dev 的 INP 介紹）。
• 字型載入的 LCP：英文版如果載入了原本中文版沒用的 web font（例如西文字體），若 LCP 元素是使用該字型的文字，字型下載及顯示策略可能影響 LCP。應依實測決定 font-display 與關鍵字型預載入，並非所有字型都要預載。多語系網站很容易因為「每個語言一套字體」而把這個傷口放大。

可分別用 PageSpeed Insights 與瀏覽器效能工具測中文版、英文版。若差異明顯，還要排除字型、圖片、第三方腳本、快取命中與內容長度，不能只憑「慢一秒」就認定翻譯外掛是根因。指標定義可對照 Core Web Vitals 與 SEO。

翻譯品質沒有絕對標準，但你需要一個可量化的 SLA

很多人會問一個問題：「機器翻譯到底夠不夠用？」誠實說，這問題本身問錯了。翻譯品質沒有絕對的夠不夠，只有「相對於這個頁面的用途夠不夠」。把這個觀念講清楚，你才不會陷入兩種極端：要嘛要求每一頁都做到母語完美，結果翻譯預算爆炸；要嘛全部交給機器，結果英文首頁讀起來像說明書，外國客戶看一眼就跳出。

下面三層是本文採用的實務分級，方便依頁面用途安排校稿資源；它不是通用產業標準。

這張表的價值在於，它讓「翻得好不好」這個模糊問題變成可操作的判斷。你不用再憑感覺爭論某段翻譯要不要改，只要先問：這頁是哪一級？第二級的頁面，校稿到「讀得懂、沒有硬傷」就收手，別為了一個介詞的優雅度糾結半天；第三級的頁面，則值得花母語者的預算做到自然流暢。沒有這個分級，校稿人員要嘛過度打磨浪費工時，要嘛草率放行砸了品牌。

大量翻譯可借用 MQM 品質框架 的錯誤分類與嚴重度，訂出適合專案的驗收方式；TAUS 的 Dynamic Quality Framework 則是相關的另一套工作脈絡，不應將兩者當成同一名稱。先定術語庫、重大錯譯的處理方式及抽樣規則，才能讓校稿有可重複的判準。這也呼應 內容行銷策略 中依內容用途安排品質標準的做法。

旗艦人工、長尾機器：大型網站的混合翻譯策略

頁面與語言增加後，可按內容用途分配人工與機器翻譯資源。是否採混合策略取決於風險、預算與校稿產能；選一款外掛也不代表只能採一種翻譯方式。

混合策略的核心是頁面分層、對應不同翻譯產能。把網站的所有頁面依照商業價值分三層：

• 旗艦層（首頁、核心產品頁、高轉換登陸頁、定價頁）：這些頁面每一個訪客的價值最高，翻譯品質直接換算成訂單，務必用第三級（專業人工或母語者）。
• 支援層（產品分類頁、部落格主力文、教學文件）：這些頁面帶流量跟信任，但單頁轉換價值較低，用第二級（機器翻譯＋人工校稿）就夠。
• 長尾層（舊文章、輔助說明頁）：仍要確保翻譯有用且正確；標籤與篩選器頁若內容薄弱，可不翻譯或不索引，不要只為 SEO 覆蓋批量產生機器翻譯。

WPML 可用翻譯管理分派工作，Weglot 可在自動翻譯後人工修訂，Polylang Pro 也有 DeepL 翻譯功能。可依各方案提供的權限、進度管理與審核工具安排混合流程，重點是明確標示哪些內容已校稿、哪些仍待驗收。

混合策略會把較多人工資源放在商業與風險較高的頁面，其他頁面則依用途安排機器翻譯與校稿。實際節省多少取決於字數、語言、術語難度與驗收標準，不能套用固定的八二比例或三分之一成本。

混合策略有一個不能輕忽的風險：品質分裂。讀者從做得精美的英文首頁點進一篇部落格，發現文筆突然變卡、用語不一致，信任會瞬間崩塌，這跟旗艦頁做得多好無關。緩解這個風險的關鍵是建立兩份文件：一份風格指南（brand voice、語氣、禁止用語），一份術語庫（產品名、技術詞、產業慣用語的標準譯法）。風格指南讓母語譯者跟機器翻譯遵循同一套語氣，術語庫讓全站同一個概念不會出現三種譯法。這兩份文件是混合策略的基礎建設，沒有它們，你的多語系網站會讀起來像拼裝車，再好的旗艦頁也救不回長尾頁流失的信任。

把這個觀念再往上拉一層，多語系網站的翻譯策略其實跟單語網站的內容分級是同一件事：不是每一篇內容都值得投入同等心力，差別只在多語系把這個取捨放大到「每一頁都要乘上語言數」。如果你還沒想過自己網站的內容分級，先回頭把 多語系 SEO 的整體策略跟網站的內容資產盤點一次，再決定哪一層用哪種翻譯產能，會比直接挑外掛更有效率。

已經用了某款，想換到另一款怎麼辦

另一個常被問到的問題是「我已經用了 GTranslate 免費版（或 Weglot），現在想把翻譯搬回自己的資料庫，要怎麼無痛換軌」。這個需求很真實，因為很多團隊一開始用雲端路線快速上線，等流量驗證了、確定值得長期投入，就想把內容所有權拿回來、把長期成本壓下來。

遷移的核心風險在於網址結構變動。如果你從雲端代理路線換到原生路線，英文版的網址可能會跟著改變，例如從 yourdomain.com/en/about 換成另一種 slug 結構。任何網址變動都牽動 301 重新導向 的設定，若未妥善對應，使用者與搜尋引擎可能無法順利到達新頁；搬遷期間也可能有暫時的排名波動。

建議先在 staging 重建翻譯並確認能沿用既有網址；若網址必須改，建立逐一對照的永久轉址、更新 hreflang、canonical、內部連結與 sitemap，再安排單一權威版本的切換。不要讓兩套外掛在正式站長期同時輸出可索引頁面，以免產生衝突與重複網址。上線後再用 Search Console 與伺服器紀錄持續監控。

上線前驗收清單：五項一定要逐條確認

很多多語系專案的真正問題出在「裝好了就以為完工了」這個心態，外掛選錯反倒不是最大殺手。多語系 SEO 是一個需要驗收的工程，沒有驗收就等於交屋沒驗漏水。這份清單是多語系網站上線前一定要逐項確認的，你可以直接拿來當上線後的第一份健檢表。

• 語言版本能不能被獨立收錄？在瀏覽器開英文版網址，檢查原始碼與渲染後內容，再用 Search Console URL Inspection 查看 Google 選擇的 canonical 與索引狀態。site: 查詢只能粗略參考，不能當成完整索引驗證。觀念可對照 Google 收錄檢查。
• hreflang 是不是雙向且正確？英文頁要指回中文頁，中文頁也要指向英文頁，而且語言代碼（en）與地區代碼（en-US）要跟你實際要服務的市場一致。每個版本也要包含自己；缺少雙向回指的對應可能被忽略。
• 語言切換器在行動版找得到嗎？切換器要讓使用者容易找到且不被遮住。搜尋引擎發現其他語言版本主要還要靠可抓取連結、hreflang 與 sitemap，不能只靠切換器。
• sitemap 有沒有包含所有可索引語言版本？XML sitemap 應列出要收錄的語言網址；hreflang 可放在 HTML、HTTP 標頭或 sitemap，三選一即可，不是每份 sitemap 都必須附 hreflang。可參考 XML sitemap。
• 結構化資料有沒有跨語言重複或錯亂？商品、文章、FAQ 這類 結構化資料 應符合頁面可見內容與該類型的欄位規範；翻譯名稱、描述等文字時，同步檢查結構化資料。不是所有類型都有必填語言欄位，也不是每頁都需要 FAQ 標記。

這五項跑完，你的多語系才算真的「對 Google 說得清楚」。它們跟外掛選擇是兩條獨立的線：外掛決定基礎建設做得好不好，驗收決定你有沒有真的把基礎建設用對。兩個都顧到，多語系流量才有機會長出來。

四個問題，幫你定下最終選擇

比較表看完了，但真正做決定時，多數人還是會卡在「我到底屬於哪一種」。把診斷多語系網站時常見的狀況收斂一下，會歸納出四個問題。你照順序回答自己，答案就會浮現。

1. 每月有多少翻譯與校稿產能？以實際字數測試人工、自動翻譯與審核工時，各產品皆應保留品質檢查。
2. 預算包含哪些持續支出？把授權續約、API 或 AI 額度、託管訂閱及校稿一起試算，WPML 不是一次買斷。
3. 團隊偏好哪種操作？試用前端校稿、WordPress 內容編輯及團隊分派流程，確認誰能維護。
4. 是否要經營外語搜尋？選有可檢索語言網址與必要 SEO 設定的方案；GTranslate 免費服務不提供這種網址，且商業用途須付費。

這四個問題的答案一旦明確，你的選擇通常只剩一個。判斷的關鍵在於哪一款跟你的人力、預算、能力、目的最契合，「最強」這個字眼其實幫不上忙。這跟挑主機、挑 必裝外掛 的邏輯是一樣的：沒有最好的工具，只有最對的組合。

六步行動方案：從決定到上線

決定好外掛之後，接著這六步是實務建議的上線節奏，幫你把「選對外掛」延伸成「把多語系真正做起來」。每一步都對應一個具體動作，不要跳過。

1. 先定網址結構。在裝任何外掛之前，決定好要用子目錄還是子網域，後續可以調整，但應事先準備網址對照、永久轉址與監控。
2. 備份再動手。裝多語系外掛會動到資料庫結構與網址路由，上線前一定要有一份完整備份。如果你還沒有備份習慣，先看過 UpdraftPlus 備份教學 再開工。
3. 裝妥外掛、設定主要語言。把中文設為預設語言，再加入第一個目標語言。第一次只做一個語言，跑通整個流程再加第二個。外掛安裝本身可以參考 WordPress 外掛安裝教學。
4. 先翻高流量、高轉換的那幾頁。不要妄想一次翻完整站。先挑首頁、關於我們、核心產品或服務頁、聯絡頁這幾個外國訪客一定會看到的入口，把它們翻到可用、可被收錄的程度。
5. 檢查 hreflang 與收錄狀態。Search Console 可確認網址索引狀態，但目前沒有專用 hreflang 報表；hreflang 應用原始碼、URL Inspection 的渲染內容或專用爬蟲檢查雙向回指。操作觀念可對照 Google Search Console 操作指南。
6. 追蹤各語言版本的流量與排名。依檢索頻率、網站權威與市場競爭持續觀察，沒有保證三到六個月見效。技術驗收可在上線後立即開始，索引與成效則按實際報表追蹤。

結語：多語系是長期投資，外掛只是起點

選擇時同時比較內容存放方式、翻譯工作流程、SEO 功能與持續成本。先以一種語言、少量核心頁面驗證，再擴大到其他語言；免費、付費或託管都不是品質與成效的保證。

多語系網站能不能成功，不只取決於外掛，也取決於翻譯品質、技術驗收、在地搜尋需求與持續維護。它不是一翻就立刻有流量的速成法，成效時間也沒有固定保證。

還有一個觀念值得反覆提醒：多語系不是把同一份內容換個語言上架就好，每一個語言版本都應該為那個語言的讀者重新想過。英文讀者的搜尋習慣、在意的好處、熟悉的用語，跟中文讀者不一定一樣。直接把中文文案逐字翻過去，技術上沒問題，但轉換率往往不如預期，因為你服務的是兩群腦袋裡裝著不同搜尋意圖的人。把每一個語言版本當成一份獨立的內容資產來經營，這才是多語系 SEO 真正的門檻。機器可以幫你把字翻對，但只有懂市場的人，才能把話說進讀者心裡。

如果正在評估多語系，先回答前面的四個問題，從一個目標語言與幾個核心頁面做小規模驗證。技術基礎完成後，仍要用收錄、搜尋需求、內容品質與轉換資料決定是否擴大。