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

其實不少人都遇過這種狀況：老闆突然丟來一句「我們網站要不要做個英文版？聽說多語系可以帶來很多國外流量」，你心裡一沉，因為你很清楚這句話背後藏著一連串會咬人的技術決策。選錯翻譯外掛，輕則翻譯內容亂掉、選單跑位，重則整個多語系的 SEO 結構崩盤，Google 看不懂你的語言版本，連帶把原本排名好好的中文頁一起拖下水。

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

重點摘述：九十秒決定你該用哪一款

先講重點。如果你沒時間看完，對照這張決策表，九十秒內能拿到方向；選翻譯外掛不是選「最強的」，而是選「跟你的翻譯產能、技術能力、預算結構最對得上的」。

你的情境	建議選擇	核心理由
預算有限、有翻譯人力、想長期養流量	Polylang	免費版就能做出完整 SEO 結構，每種語言獨立可索引
預算充足、內容量大、需要專業工作流程	WPML	老牌成熟、與電商與主題相容性最好
沒有翻譯人力、想靠機器翻譯快速上線	Weglot	雲端自動翻譯先跑完，再進後台人工校稿，上線速度最快
非工程背景、想用看的就翻完	TranslatePress	所見即所得前端翻譯，點哪翻哪
只想先放一個語言切換按鈕應急	GTranslate 免費版	零成本、零設定，但免費版有 SEO 致命傷（下面會講）

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

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

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

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

• 語言版本的收錄問題：英文版頁面如果技術上不讓 Googlebot 抓得到，那它等於不存在，你翻了等於白翻。
• 語言與地區的對應關係：Google 必須知道「這個英文頁面是要給美國人看、還是給英國人看」，標記錯了，排名訊號會分散。這牽涉到 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

這三個網址是真實存在、各自獨立、各自可以被 Google 收錄的頁面。翻譯內容存在你自己的 WordPress 資料庫裡，你完全擁有它。這條路的好處是 SEO 結構最乾淨、可控性最高、長期成本最低（因為沒有每月訂閱費）；代價是翻譯工作量大，而且你需要自己維護每個語言版本的內容同步。

Polylang 跟 WPML 都屬於這條路。差別在 Polylang 免費版就涵蓋大部分功能，WPML 則是純付費、但工作流程與相容性更成熟。

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

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

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

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

好處是設定極快、幾乎不需要碰技術，而且第一次翻譯完全交給機器。代價是：你通常要付月費（雲端服務按字數或語言數計價），長期成本會隨網站長大而墊高；而且翻譯品質的掌控權不在你手裡，要看那家服務的翻譯引擎水準。這條路適合「想快速上線、不缺預算、缺人力」的團隊。

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

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

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

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

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

換句話說，沒有任何一款外掛能幫你迴避「翻譯是需要人來做」這個本質。外掛能決定的，只是這些人力要怎麼分配、用什麼工具輔助、以及成本是前置還是分期。所以評估一個多語系專案時，第一個該問的問題向來是「你每個月能撥出多少時間做翻譯跟校稿」，至於想用哪款外掛反而是次要的。這個答案出來了，外掛的選擇幾乎就跟著定了。也因此建議，還沒有穩定翻譯產能的團隊，先用雲端機器翻譯（Weglot）上線、用流量數據驗證市場值不值得做，等確定要長期投入了，再考慮遷移到原生路線（Polylang 或 WPML）把成本結構壓下來。

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

Polylang 是 WordPress.org 上最被信賴的多語系外掛之一，免費版就能做到完整的獨立網址、獨立收錄與 hreflang 自動輸出（見 Polylang 的 WordPress.org 外掛頁）。它的核心邏輯是「每個語言都是獨立的一套內容」，你必須為每篇文章手動建立對應語言的副本，再逐一翻譯。

它的強項：

• 免費版可建立獨立語言內容、網址結構、hreflang 與語言切換；個別網址 slug 的翻譯等進階功能要核對 Pro 或附加方案。
• 翻譯存在你自己主機的資料庫，沒有月費、沒有字數上限、沒有第三方依賴。
• 輕量，跟大多數主題與快取外掛都能共存。

它的代價：

• 翻譯工作量最大。每篇文章都要手動建立副本、逐字輸入，內容一多就很吃人力。
• Polylang Pro 與 Polylang for WooCommerce 是不同付費產品／方案組合，WooCommerce 相容與 slug 翻譯要依目前功能表確認，不要只買 Pro 就假設電商需求全包。
• 介面是傳統的字串表格，對非技術人員不夠直覺。

老實說，Polylang 適合「有翻譯人力、想長期養多語系流量、不想被月費綁住」的團隊，是這類需求的第一推薦。它的免費本質把長期成本壓到最低，但你必須接受前期投入的翻譯時間。如果你的網站是用 Astra 或 Elementor 架的，Polylang 跟這類主流主題的相容性都很好，可以參考 Astra 主題教學 裡的搭配觀念。一個實務上的小提醒：用 Polylang 時，一開始就要把每種語言的固定網址結構（例如 /en/、/ja/）定清楚，因為它會貫穿整個網站的網址，事後調整等於要重做一遍內部連結，非常傷。

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

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

它的強項：

• 與 WooCommerce 的整合最成熟，多語系電商幾乎是它跟 Polylang Pro 兩強相爭。
• 翻譯管理介面完整，適合「有翻譯團隊、內容量大、需要流程控管」的企業站。
• 生態與相容性文件完整，但仍需針對實際主題、外掛、快取與結帳流程測試。

它的代價：

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

WPML 的定位很清楚：它是給「把多語系當成正式業務、願意為了工作流程與相容性付錢」的成熟網站用的。如果你只是想加個英文版試水溫，WPML 會讓你覺得殺雞用牛刀。但如果你正在架設一個多語系 WooCommerce 購物車，產品多、分類雜，WPML 的成熟度會幫你省下很多踩坑的時間。

Weglot 深度評：上線最快的多語站，但要算清楚長期成本

Weglot 走的是雲端代理路線，定位是「零技術背景、最快上線」。你安裝外掛、填入 API key、選擇要翻譯的語言，剩下的第一次翻譯它用機器翻譯自動跑完，立刻產生可瀏覽、可被 Google 收錄的多語系版本（Weglot 官方網站）。之後你可以進後台針對每一段文字做人工校稿。

它的強項：

• 上線速度最快，從安裝到看到英文版，往往在幾十分鐘內。
• 第一次翻譯完全自動，不必逐篇手建副本。
• SEO 結構做得相對完整，會自動產生 hreflang 與獨立語言網址。

它的代價：

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

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

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

TranslatePress 的技術底層跟 Polylang、WPML 同源（翻譯存進資料庫、產生獨立網址），但它把操作體驗做了徹底翻轉。你不用碰字串表格，而是開啟一個覆蓋在網站前端的翻譯介面，游標點到哪一段文字，就跳出輸入框讓你翻譯（TranslatePress 官方網站）。翻完存檔，畫面立刻更新。

它的強項：

• 所見即所得，翻譯體驗最直覺，行銷人員、內容編輯都能直接上手。
• 免費版涵蓋基本多語系功能，進階（WooCommerce、SEO 加強、機器翻譯整合）走付費升級。
• 翻譯內容完全在你自己的資料庫，沒有月費依賴。

它的代價：

• 面對大量內容時，逐頁點擊翻譯的速度比批次表格慢。
• 進階功能分散在多個付費附加套件，要湊齊完整功能可能比預期貴。
• 跟某些高度客製化的主題或頁面編輯器搭配時，字串抓取可能有遺漏。

TranslatePress 適合「非工程背景、團隊裡沒有專職開發、但又想自己掌控翻譯品質」的站長，是實務上的推薦選擇。它把翻譯的門檻降到最低，同時保留了 SEO 結構的完整度，是一個很平衡的選擇。

GTranslate 深度評：免費應急方案，免費版的 SEO 致命傷

GTranslate 是這五款裡門檻最低的，免費版裝上去、放一個語言切換器，訪客一點就能切到其他語言（見 GTranslate 文件）。對「只是想先讓外國訪客勉強看得懂」的需求，它是最快的零成本方案。

但這裡有一個必須誠實點出的地雷：GTranslate 免費版的翻譯，是透過 JavaScript 即時產生的。意思是，那個翻譯出來的頁面，對 Google 來說基本上是一個動態產生的內容，不是一個獨立、可被收錄、可被排名的真實網址。你以為自己做了一個英文版，其實你只是做了一個「給真人看的即時翻譯按鈕」，Google 根本不會把它當成一個能排名的英文頁面。

如果你做多語系的目的是養國外自然搜尋流量，免費版等於白做。GTranslate 的付費版才會把翻譯內容靜態化、產生可收錄的獨立網址與 hreflang，但走到付費版，你就要拿它的成本結構去跟 Weglot 比一比了。

所以從定位來看：GTranslate 免費版只適合「應急、不指望 SEO 成效、只求外國客戶當場看得懂」的場景，例如短期展覽、活動頁、臨時上線的品牌介紹。一旦你認真要把多語系當流量資產來經營，就該離開免費版，往其餘四款移動。

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

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

維度	Polylang	WPML	Weglot	TranslatePress	GTranslate（免費）
技術路線	原生資料庫	原生資料庫	雲端代理	視覺化前端	雲端 JS
費用模式	免費為主、Pro 年費	純付費、按站年費	月／年訂閱、按量計價	免費＋付費附加	免費
獨立網址可收錄	是	是	是	是	否（致命傷）
翻譯人力需求	高（手動為主）	高（但有流程工具）	低（機器先翻）	中（點擊翻譯）	零
長期成本可控	最佳	佳	隨成長墊高	佳	最佳（但無 SEO）
上手難度	中	偏高	低	最低	最低
最適合	有翻譯人力、長期養流量	企業站、多語系電商	快速上線、缺人力	非工程背景、重品質	應急、不靠 SEO

這張表裡最該被畫紅線的，是「獨立網址可收錄」那一列。它直接決定你的多語系內容能不能帶來流量。GTranslate 免費版在這一格的「否」，就是不建議把它拿來當認真多語系方案的核心原因。

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

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

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

hreflang 是告訴 Google「這個頁面是給哪個語言、哪個地區的讀者看」的標記。設對了，Google 會在對的地區的搜尋結果裡顯示對的語言版本；設錯或漏設，Google 就只能用猜的，猜錯了流量就分散或跑掉。大多數外掛會自動產生 hreflang，但你要確認它產生的是雙向的（A 指向 B，B 也要指回 A），而且語言代碼與地區代碼是對的。這件事的完整設定邏輯，可以對照 hreflang 多語系 SEO 手冊 來檢查。

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

多語系的網址結構有三種主流做法：子目錄（/en/）、子網域（en.domain.com）、獨立網域。這個選擇會直接影響權重怎麼分配、主網域的 SEO 能不能外溢給語言版本。子目錄的好處是權重共用、管理集中；子網域的好處是技術隔離、可以分別部署。沒有絕對的對錯，但這是一個在裝外掛之前就該定的架構決策，因為它牽動整個 子網域與子目錄 的 SEO 權重邏輯，事後改的成本很高。

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

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

再補一個跟點擊率有關的視角。Backlinko 2025 年 4 月的 Google CTR 統計分析了數百萬筆 Google 搜尋結果，發現排名位置對點擊率的影響是斷崖式的，第一名與第三名之間的點擊率差距非常可觀。把這個數據放回多語系情境：當你用對的外掛做出一個乾淨、可收錄、hreflang 正確的英文版，你等於是在英文搜尋結果裡多爭取一個能往上爬的版位；而你的英文版標題與中繼描述夠不夠吸引人，會直接決定你在那個版位能搶下多少點擊。所以翻譯不是只翻正文，連 網址與 SEO 標題 都要為目標語言的搜尋者重新想過。

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

如果你的網站是 WooCommerce 電商，多語系的複雜度會再上一個台階。因為電商內容不只是文章，還有商品頁、變體、結帳流程、email 通知、稅務與運費設定，這些全部都有翻譯需求。一般來說，電商多語系的範圍可收斂到兩個選擇：

• WPML 搭 WooCommerce Multilingual：整合最成熟，商品、分類、屬性、結帳頁都能完整翻譯，適合商品數量大、流程複雜的正式電商。
• Polylang 搭配 Polylang for WooCommerce：電商整合需另用對應付費產品，適合願意自行測試商品、變體、結帳與信件流程的團隊。

雲端路線（Weglot）也能處理 WooCommerce，但因為商品資料即時翻譯的特性，在變體商品、動態價格、庫存顯示這類需要精準同步的欄位上，偶爾會出現翻譯延遲或欄位對不上的狀況。如果你的電商對「價格與庫存必須分毫無差」很要求，原生資料庫路線會比雲端路線保險。想進一步了解電商多語系涉及的產品頁 SEO 細節，可以延伸閱讀 WooCommerce 產品頁 SEO。

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

多數人把翻譯外掛當成純後台的東西，以為「翻了就翻了，不影響前端」。這個假設在原生路線（Polylang、WPML、TranslatePress）上大致成立，但在雲端代理路線（Weglot、GTranslate）上是有代價的，而且這個代價會回頭咬你的 SEO。Google 把 Core Web Vitals（LCP、INP、CLS）當成排名參考訊號之一（見 web.dev 的 Core Web Vitals 說明），多語系網站如果因為外掛選擇讓這三個指標變差，等於在起跑點就輸人。

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

多語系情境特有的三個效能陷阱

• 語言切換器的 CLS：切換按鈕如果是用 JS 在頁面載入後才插入 DOM，按鈕出現的瞬間會把下方內容往下推，產生累計版面位移。這個 CLS 在單語網站不會出現，是多語系特有的陷阱。
• 動態文字替換的 INP 風險：若方案確實在前端執行大量字串替換，可能增加主執行緒工作；是否影響 INP 要用實際互動量測，不能只由外掛類型推定（見 web.dev 的 INP 介紹）。
• 字型載入的 LCP：英文版如果載入了原本中文版沒用的 web font（例如西文字體），卻沒做 font-display 或預載入，LCP 會被字型下載卡住。多語系網站很容易因為「每個語言一套字體」而把這個傷口放大。

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

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

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

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

品質層級	定義	達成方式	適用頁面
第一級：技術可用	HTML 結構、hreflang、網址都正確，頁面可獨立檢索	機器翻譯後仍需基本檢查，確保內容對讀者有用；無價值頁面不應只為擴大索引量而大量產生	內部文件、低風險輔助頁，或評估不索引的頁面
第二級：可被理解	讀者讀得懂你在賣什麼、在講什麼，沒有明顯語意錯誤	機器翻譯＋人工校稿（抓錯譯、漏譯、術語）	部落格文章、FAQ、說明文件
第三級：可被信任	讀起來像母語者寫的，用語、語氣、文化參考都到位	專業譯者或母語者執筆，搭配風格指南	首頁、核心產品頁、結帳流程、登陸頁

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

如果你的翻譯量大到需要對外驗收，業界有一套通用的品質衡量框架叫做 MQM（Multidimensional Quality Metrics），它把翻譯錯誤分類為準確性、流暢性、術語、風格等維度，每種錯誤給予權重與嚴重度，最後得出一個可比較的分數（見 TAUS 2014 年提出的 Dynamic Quality Framework）。你不必導入完整版，但可以借用它的精神：訂出你的術語庫（這個產品名英文怎麼講、那個技術詞用哪個譯法）、訂出可接受的錯誤密度（例如每千字容許幾個第二級錯誤），這就是你的翻譯品質 SLA。有了 SLA，外包翻譯或機器翻譯校稿才有驗收標準，而不是「看感覺」。這套思維跟 內容行銷策略 裡講的「為不同內容類型訂不同標準」是同一個邏輯。

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

前面把五款外掛講成「選一款」，那是給中小網站的決策框架。但當你的網站超過幾百頁、又要同時做三個以上語言，單一翻譯路線會在成本或品質的某一端崩潰：全部人工翻譯，預算扛不住；全部機器翻譯，旗艦頁的轉換率會被爛翻譯拖垮。實戰上，大型多語系網站幾乎都走混合策略，差別只在怎麼切分。

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

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

這個分層對應到外掛的選擇上，每一款都有對應的玩法。WPML 可以為不同頁面設定不同的翻譯流程（旗艦頁派給專業翻譯服務、長尾頁走內部機器翻譯），這正是它企業定位的強項；Weglot 讓你標記哪些頁面要做人工校稿、哪些維持機器翻譯狀態，校稿預算可以精準投在旗艦頁；Polylang 本身沒有內建機器翻譯，但可以搭配自動翻譯外掛先跑長尾頁，再針對旗艦頁手動覆寫。沒有一款外掛天生支援混合策略，但每一款都能被你「用混合的方式操作」。

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

混合策略有一個不能輕忽的風險：品質分裂。讀者從做得精美的英文首頁點進一篇部落格，發現文筆突然變卡、用語不一致，信任會瞬間崩塌，這跟旗艦頁做得多好無關。緩解這個風險的關鍵是建立兩份文件：一份風格指南（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 漏設或單向，是多語系流量分散的最常見兇手。
• 語言切換器在行動版找得到嗎？切換器要讓使用者容易找到且不被遮住。搜尋引擎發現其他語言版本主要還要靠可抓取連結、hreflang 與 sitemap，不能只靠切換器。
• sitemap 有沒有包含所有可索引語言版本？XML sitemap 應列出要收錄的語言網址；hreflang 可放在 HTML、HTTP 標頭或 sitemap，三選一即可，不是每份 sitemap 都必須附 hreflang。可參考 XML sitemap。
• 結構化資料有沒有跨語言重複或錯亂？商品、文章、FAQ 這類 結構化資料 的語言欄位要跟頁面語言一致，跨語言複製貼上常常會把中文 Schema 帶到英文頁，造成 Google 解讀混亂。

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

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

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

1. 你有多語系的翻譯人力嗎？有，往 Polylang 或 WPML 走（原生路線，成本可控）；沒有，往 Weglot 走（機器先翻、人工校稿）。
2. 你的預算結構是什麼？偏好一次性成本、長期攤提，選 Polylang／WPML；能接受按月訂閱、用錢換時間，選 Weglot。
3. 你的團隊有技術能力嗎？沒有工程背景、想自己操作，TranslatePress 的所見即所得最友善；有技術人力，Polylang 與 WPML 的批次表格效率更高。
4. 你做多語系的目的，是 SEO 流量還是應急？是為了養國外自然搜尋流量，就一定要選能產生獨立可收錄網址的方案（四款付費或免費原生方案都行），GTranslate 免費版直接出局；只是應急讓外國客戶看得懂，GTranslate 免費版可以頂著用。

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

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

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

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

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

選翻譯外掛，本質上是在決定「你要用什麼樣的成本結構與技術架構，去經營另一個語言的搜尋流量」。Polylang 用你的時間換長期低成本，WPML 用你的預算換成熟的工作流程，Weglot 用月費換上線速度，TranslatePress 用直覺操作換非技術人員的參與，GTranslate 免費版則是零成本的應急方案但拿不到 SEO 成效。沒有哪一款是全能的，只有跟你現況最契合的選擇。

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

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

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