Polylang 完整教學：打造 WordPress 多語系網站

想像一下這個畫面：你花了一年把一個中文網站做到 Google 第一頁，流量穩定、訂單也進來了，老闆這時丟來一句「我們明年要打日本市場，網站能不能加上日文？」這句話背後藏著一個技術選擇，你要怎麼讓同一個 WordPress 網站同時服務兩種以上語言的讀者。Polylang 就是解決這件事的免費外掛，這篇將實際配置 Polylang 的完整流程一次寫清楚，從安裝、語言設定、翻譯工作流、字串翻譯、語言切換器，一路講到上架前的多語系 SEO 檢查。

重點先講：Polylang 在 WordPress 官方外掛目錄提供免費版，核心邏輯是為不同語言建立相互關聯的內容版本，再用語言切換器與 hreflang 串起來。免費版以人工建立譯文為主；Pro 版目前可在自備 DeepL API 金鑰後逐篇產生機器翻譯草稿，仍須人工審校。動手前要先決定網址架構，並確認 hreflang 是否正確輸出。

換句話說，多語系網站不是「裝一個外掛就完工」的事，外掛只是骨架，真正的血肉是譯文品質與在地化深度。Polylang 給你的是一套把骨架搭穩的方法，至於每一種語言的內容要做到多在地、多貼近當地讀者的搜尋習慣與用語偏好，那是你需要長期投入的內容工程。把外掛當成起點，別把它看成終點，你的多語系才會走得久、走得穩。

先分清楚：你要的是「翻譯」還是「多語系」

很多人在找外掛時把這兩件事混在一起，結果裝錯工具、白忙一場。這兩個詞看起來像同一件事，其實解決的是不同的問題。翻譯，是把一段已經寫好的文字，從一種語言換成另一種語言，重點在「文字轉換」這個動作。多語系，是讓一個網站能同時維持好幾種語言的完整版本，每個版本各自有獨立的網址、獨立的 SEO、獨立的內容結構，重點在「架構」。

換個比喻就清楚了。翻譯像把一本中文小說翻成日文版，譯完就結束了。多語系像開一家同時供應中、英、日三種菜單的餐廳，三份菜單各自印製、各自定價、各自更新，客人走進來可以挑自己看得懂的那一份。Polylang 做的是後者，它給你的是「餐廳」的骨架，至於菜單上要寫什麼、每道菜在不同語言裡要不要微調，那是你自己要經營的內容。

這個區分會直接影響你的外掛選擇。如果你要的是一個能長期經營、每個語言都有獨立 SEO 價值的多語系網站，Polylang、WPML 這類「內容平行架構」的外掛才是正解。如果你只是想把現有頁面快速變成另一種語言、不在意 SEO，自動翻譯型工具可能更快。這幾條路線的完整比較整理在另一篇裡，建議先讀過 WordPress 多語系外掛深度評比，把 Polylang 放進整體地圖裡看，再決定要不要往下走。

Polylang 跟自動翻譯工具，骨子裡差在哪

差異在內容儲存與編輯流程。有些自動翻譯工具把譯文存於自家服務，有些則寫入 WordPress 資料庫，不能一概而論。Polylang 的各語言內容以 WordPress 內容項目存在，便於人工校稿與在地化；仍要備份資料，並確認搭配服務的合約與匯出方式。

機器翻譯快，但「快」不等於符合市場語境、專業術語與法規要求。Polylang 讓團隊直接管理各語言內容，代價是要自行安排翻譯、審校與更新責任。

把幾種主流多語系做法放在同一張表上比較，你會更清楚自己處在哪個需求位置。這張表整理的是「做法層級」的差異，不是單一外掛的功能規格表。

Polylang 提供較高的內容控制，也更依賴翻譯與維護紀律。代管服務若調價或停止，可能增加搬遷風險，但流量不一定立即歸零；真正要比較的是內容能否匯出、網址能否延續，以及是否能設定重新導向。

動手之前：先把多語系網址架構決定好

大多數教學一上來就叫你裝外掛，然後走到一半才發現網址結構選錯了，回頭改要動到一大堆已收錄的頁面。建議倒過來做：先把架構想清楚，再裝 Polylang。Polylang 給你三種語言網址的組織方式，每一種都會牽動你的 SEO 表現與後續維護成本。

這三條路沒有絕對優劣。子目錄常因部署、分析與維護較單純而適合中小型網站，但 Google 並未保證子目錄本身有排名優勢。選擇時應看團隊、主機、法規與市場管理需求；可搭配子網域 vs 子目錄的完整解析評估。

選定架構之後，還要想清楚「預設語言要不要帶語言代碼」。比方中文是你的主語言，你要用 example.com（不帶代碼）還是 example.com/zh/？實務上偏好讓預設語言不帶代碼，保留最乾淨的網址給流量主力語言，這對既有 SEO 資產的衝擊最小。這個決定一旦上線就很難回頭，所以務必在裝 Polylang 之前就拍板。

安裝 Polylang 與初始語言設定

架構決定好，接下來就是把 Polylang 裝起來。安裝方式跟其他 WordPress 外掛相同，如果你還不熟基本安裝，可以先看WordPress 外掛安裝教學。安裝本身不複雜，真正需要仔細處理的是語言與內容關聯設定。

Polylang 安裝完成後，後台側邊欄會多出一個「Languages（語言）」選單。第一步進到 Languages → Languages，把你網站要支援的語言逐一新增進來。假設你要做中、英、日三語，就依序把「繁體中文」「English」「日本語」加進清單。每一個語言新增時，Polylang 會要你確認三個欄位，這三個千萬不要亂填。

• 語言代碼（Slug）：這會出現在網址裡，例如 ja、en、zh-tw。網址 slug 與 hreflang 值是相關但不同的設定；hreflang 應使用受支援的語言代碼，必要時加地區代碼，例如 zh-TW。Google 也會自行判斷頁面語言，代碼填錯主要會破壞版本對應。
• 語言名稱：出現在語言切換器與後台介面，建議用該語言的母語寫法，例如日文寫「日本語」而非「Japanese」，這對使用者體驗更友善。
• 語系順序與預設語言：勾選其中一個語言為「預設語言」，它就是你網站打開根網址時預設顯示的語言。

新增完語言，建議立刻做兩件小事：到 Languages → Strings translations 把網站標題（site title）與網站描述（tagline）的多語系版本先填上，再到設定 → 一般，確認網站語言與 Polylang 的預設語言一致。這兩步看起來微不足道，卻能避免之後出現「中文網站標題出現在日文首頁」這種讓人尷尬的漏網之魚。

四個一定要調的 Polylang 設定

網址、語言切換與媒體行為都跟 Settings 有關。設定名稱會隨版本調整，每一項應對照 Polylang 官方文件。下面挑出四個上線前要確認的項目。

網址結構：把架構決策落實到設定裡

Languages → Settings → URL modifications 這一頁，就是把你前面決定的網址架構落實成系統設定的地方。你可以選擇「語言代碼以目錄形式呈現」（子目錄）、「以子網域呈現」，或「為不同語言設定不同網域」。選擇要跟你前面的架構決策完全一致，選完之後 Polylang 會自動幫每個語言產生對應的網址結構。記得勾選「Hide URL language information for the default language」（隱藏預設語言的網址語言資訊），這就是讓預設語言維持乾淨網址的那個開關。

偵測瀏覽器語言：友善但要有保留

「Detect browser language」可依瀏覽器語言引導首次訪客，實際範圍與記憶方式要以各版本的官方文件為準。開啟後仍要提供清楚的語言切換器，並測試使用者手動選擇是否會被尊重；不要對搜尋引擎或每個深層網址做無條件跳轉。

媒體同步：多語系圖片要不要各自獨立

媒體翻譯並非 Pro 才有：免費版也支援媒體的語言與翻譯關係。Pro 版主要增加內容複製與同步等便利功能。若各語言要用不同圖片、替代文字或說明，應建立對應媒體翻譯；若共用檔案，也要確認前台 metadata 顯示正確。

內容同步：分類、標籤與自訂欄位的行為

Synchronize（同步）設定決定當你新增一篇文章的翻譯時，哪些後設資料要自動帶過去。分類、標籤、精選圖片、自訂欄位（custom fields）都可以設定同步。建議的做法是：分類與標籤同步打開（省下重複勾選的功夫），但牽涉到各市場差異化的自訂欄位（例如各語言不同的價格、文案）就關掉同步，手動控制才不會把 A 市場的資訊帶到 B 市場。

翻譯文章與頁面：Polylang 的編輯工作流

設定都到位之後，就進入 Polylang 真正每天要用的部分：翻譯內容。Polylang 的翻譯工作流跟大多數人直覺想像的不一樣，它不是「在一個介面裡左右對照逐句翻譯」，而是「為每一篇內容開一個獨立的姊妹頁面」。理解這個邏輯，你就不會一直找不到翻譯輸入框在哪裡。

實際流程是這樣的。你先寫好一篇中文文章，在編輯器右側的「Languages」區塊，你會看到所有已啟用語言的清單，每個語言旁邊有一個「+」號。點下日文那一列的「+」，Polylang 會幫你開一個全新的日文文章編輯畫面，這個畫面跟一般寫文章完全一樣，你在標題與內容裡填入日文版即可。存檔之後，這篇日文文章就跟原本的中文文章「綁定」在一起，成為一組翻譯關係。

綁定後，前台可以在版本間產生語言切換連結與 hreflang。文章清單的語言欄位則用圖示表示翻譯關係；發布狀態仍應進入各語言內容或清單篩選確認，不要只靠國旗圖示判定。

各語言是獨立內容版本。免費版不會自動產生譯文；Pro 版可串接 DeepL 產生單篇草稿，但需要自備 API 金鑰，且部分頁面編輯器不相容。無論人工或機器產生，Polylang 都不保證翻譯品質，發布責任仍在編輯者；DeepL 機器翻譯的啟用條件詳見 官方的 DeepL 使用指南。

若要外包翻譯，Pro 版可用 XLIFF 或 PO 檔匯入、匯出內容；後台權限則要搭配 WordPress 角色與適用的權限管理方式設定。不要假設 Polylang 內建一個不需文章編輯權限的通用翻譯佇列。

字串翻譯：把佈景主題與外掛的文字也中文化

文章翻譯只是多語系的一半。另一半藏在你看不到的地方：佈景主題與外掛裡那些寫死的文字，例如按鈕上的「閱讀更多」、表單裡的「送出」、頁尾的「© 版權所有」。這些字不會出現在文章編輯器裡，卻會同時出現在所有語言的頁面上，如果沒處理，你的日文頁面可能會出現一顆寫著「閱讀更多」的中文按鈕，瞬間讓專業感破功。

Polylang 透過「Languages → Strings translations」來處理這件事。它會掃描你的佈景主題與外掛裡「已做好翻譯準備」的字串（也就是程式碼裡用翻譯函式包起來的文字），把這些字串列出來讓你逐一填入各語言版本。填完之後，按鈕、標籤、提示文字就會跟著頁面語言自動切換。

這裡會牽涉到一個更底層的主題：WordPress 的翻譯檔機制（.po / .mo 檔）。如果你的佈景主題根本沒有把字串做好翻譯準備，Polylang 的字串翻譯也抓不到它們，這時你需要回頭用檔案層級的方式中文化。如果你想深入了解這套檔案機制，可以讀 Loco Translate 中文化完整指南，它示範怎麼直接在後台編輯翻譯檔；習慣桌面工具的人，則可以用 Poedit 這類離線軟體來處理 .po 檔。兩條路都會產出 .mo 給 WordPress 讀取，Polylang 的字串翻譯跟這套機制是互補的，一個管後台可填的、一個管檔案層級的。

選單與語言切換器：讓讀者一秒換語言

語言版本都準備好了，如果讀者找不到切換的入口，一切白搭。Polylang 提供幾種放語言切換器的方式，選哪一種取決於你的選單設計與版面規劃。

最常見也最乾淨的做法，是把語言切換器加進網站主選單。到 Appearance → Menus（外觀 → 選單），在畫面右上角的「Screen Options（顯示選項）」裡勾選「Language switcher（語言切換器）」，勾選之後，選單左邊的可用項目就會多出「Languages」這一類，你可以把「Language switcher」勾選加進你的主選單，存檔後前台選單就會出現各語言的切換連結。

如果你的佈景主題支援 Widget（小工具）區域，Polylang 也提供一個「Language switcher」小工具，可以拖進頁尾、側邊欄或任何小工具位置。這對選單已經很滿、不想再塞東西的版面特別好用。切換器的呈現方式也很有彈性，你可以選擇顯示國旗、語言代碼、語言全名，或三者的組合。實務上偏好顯示語言代碼（zh / en / ja），原因是國旗在某些多官方語言的國家會踩到政治地雷，例如法語同時對應法國、加拿大魁北克、比利時，用國旗反而會冒犯某一方。

在語言切換器的設計上，有一個常被低估的細節：切換器要顯示「可切換過去的其他語言」，而不是「目前所在的語言」。讀者現在在看中文版，他要看到的是「English」「日本語」這些他可以點過去的選項，而非一個告訴他「你正在看中文」的標籤。這聽起來像常識，卻是不少網站都做錯的地方。

行動裝置上的語言切換器還有一個額外考量：手機版面寸土寸金，選單往往被收進漢堡選單裡，語言切換器很容易被埋到第二層，訪客根本找不到。常見的做法是在頁尾再放一組精簡的語言切換器，確保不管訪客從哪一頁進來、不管在哪個裝置上，都能很快換到另一個語言。切換器的「可發現性」直接影響多語系內容的實際被使用率，再好的譯文，如果讀者找不到入口去切換，也等於白做。

Polylang 免費版 vs Pro：你到底需不需要付費

這大概是最常被問到的問題。Polylang 的免費版其實已經涵蓋多語系網站的核心需求：新增語言、建立翻譯、語言切換器、hreflang 自動產生，這些全部免費就有。那 Polylang Pro 到底多給了什麼，值不值得花錢？可先對照 Polylang 官方下載頁的版本差異。

依 2026 年官方功能表，Pro 版主要增加翻譯 slug、跨語言共用相同 slug、內容複製與同步、啟停語言、XLIFF／PO 匯入匯出、DeepL 機器翻譯，以及 ACF、REST API 與網站編輯器等整合。媒體翻譯與部分 metadata 同步並非全部只限 Pro，實際劃分可見 Polylang 定價頁。

是否升級不應用語言數量判斷。若需要 slug 翻譯、內容複製同步、DeepL、XLIFF／PO 或特定整合，再評估 Pro；單純文章與頁面多語系，免費版可能已足夠。WooCommerce 商品、訂單、庫存等同步則需要另購 Polylang for WooCommerce 或 Business Pack，不是只升級 Polylang Pro 就完整涵蓋。

還有一個更根本的選擇題：Polylang 是不是最適合你的多語系外掛？如果你重視的是「視覺化、所見即所得的翻譯介面」，TranslatePress 可能更順手，它的多語系做法跟 Polylang 不太一樣，你可以對照著讀 TranslatePress 多語系教學，看看哪一套的邏輯跟你的工作習慣更合。

跟 WooCommerce 與 Elementor 一起用

多語系最常卡關的地方，不在 Polylang 本身，而在它跟你其他外掛的搭配。兩個最容易出問題的組合是 WooCommerce 與 Elementor，這也是台灣做外貿、做跨境電商的站長最常遇到的場景。

WooCommerce 商店若要同步商品翻譯、SKU、價格、稅率、庫存與相關分類，需要 Polylang for WooCommerce 擴充套件；多幣別仍是另一層需求，通常要搭配相容的多幣別或結帳方案處理，商品同步的細節見 Polylang 的商品管理指南。

Elementor 內容可透過各語言頁面分別編輯；若需要範本翻譯、語言顯示條件、語言切換小工具或額外整合，可評估第三方 Connect Polylang for Elementor。它不是所有 Elementor 文字翻譯都必裝的官方橋接器，上線前要自行測試版本相容性，外掛資訊可查 WordPress 外掛目錄的 Connect Polylang for Elementor 頁面。

快取層必須把不同語言網址或語言狀態正確區分，否則可能送出錯誤版本。各快取外掛與 CDN 的相容方式不同，沒有通用的「多語系模式」可保證正確；應查官方相容文件，並用未登入、無痕與不同語言偏好交叉測試。

多語系不等於多幣別，界線要畫清楚

這是 WooCommerce 站長最容易搞混的一個概念。多語系解決的是「客人看得懂哪種語言」，多幣別解決的是「客人用哪種貨幣結帳」。兩者常常相關，卻不是同一件事。一個日本客人可能看得懂英文、卻想用日圓付款；一個台灣客人可能在日文版瀏覽、結帳時想用新台幣。所以你不能假設「日文版就一律用日圓、英文版就一律用美元」，這層對應關係要看你的實際收款能力與物流範圍來設計。把這條界線畫清楚，你才會知道哪些設定歸 Polylang 管、哪些要交給多幣別或結帳外掛，不會在設定選單裡團團轉卻找不到該調哪一個。

常見陷阱：這些狀況上線後才發現就來不及

即使設定完成，仍有一些問題不一定會在後台顯示錯誤，需要上線前主動檢查。下面整理常見狀況與排查方式。

翻譯綁定斷裂：孤兒譯文吃掉你的收錄

Polylang 依翻譯關係產生 hreflang 與語言切換連結。若綁定遺失，頁面仍可能被 Google 依內容判斷語言並索引，但搜尋引擎較難知道它與其他版本的對應關係，切換器也可能無法連到。可依語言欄位篩選，抽查重要頁面的雙向綁定與原始碼。

預設語言網址變動：一個改動毀掉全站排名

預設語言是否帶代碼會影響網址。若上線後變更，應建立一對一 301 重新導向、更新 canonical、hreflang、內部連結與 sitemap，並監測索引。搜尋表現可能波動，但沒有固定「數週」時程，也不代表訊號一定完整轉移。

分類與標籤漏譯：分類頁變成 SEO 死巷

分類與標籤也可以建立翻譯關係。若網站前台會使用這些彙整頁，就要確認各語言名稱、slug 與文章歸類正確；若標籤頁本來不打算索引，則不必為了 SEO 強行建立完整分類樹。

SEO 外掛的多語系欄位：別讓中文 meta 出現在日文頁

如果你用 Rank Math 或類似的 SEO 外掛，要確認它跟 Polylang 的多語系欄位有正確接起來。具體來說，每個語言版本的標題（title tag）、Meta 描述（meta description）、社群分享用的 Open Graph 標籤，都要能在該語言的編輯畫面裡單獨填寫。多數主流 SEO 外掛都已和 Polylang 做好相容，但你要主動進到各語言版本，把這些欄位實際填上，不要讓日文頁面頂著一段中文的 meta 描述就上線，那會直接削弱這個頁面在日文搜尋結果裡的點閱率。

快取與語言切換的衝突：自己測不出來的 bug

這個問題前面提過，但值得在陷阱清單裡再強調一次。頁面快取若沒有正確區分語言，可能讓中文訪客看到日文版本；單一瀏覽器又可能因既有 cookie 而漏測。上線前應用無痕視窗、不同瀏覽器語言偏好與各語言網址交叉測試，降低錯誤版本送出的風險。

上架前八項多語系 SEO 檢查

內容都翻好、切換器也放好，先別急著開香檳。多語系網站最容易在 SEO 這一關翻車，而且翻得不明顯，常常是流量慢慢掉了你才驚覺不對勁。這裡把上架前一定要過的八個檢查項目列成清單，一項一項對著打勾。

1. hreflang 標記是否正確：每個語言版本都應列出自己與所有對應版本，而且各版本必須雙向回指；缺少回指時，Google 可能忽略標記。x-default 適合用於語言選擇頁或預設版本，但不是每組頁面的必填項目。完整規則請讀hreflang 多語系 SEO 完全手冊，官方依據是 Google Search Central 對本地化版本標記的說明。
2. Canonical 是否合理：不同語言內容通常各自 canonical 到自己的網址；若全部指向中文版，可能讓搜尋引擎選擇錯誤的代表網址。Canonical 是提示，不是「重複內容處罰」，原理請見Canonical URL 完全指南。
3. Sitemap 是否涵蓋所有可索引版本：Sitemap 通常由 WordPress 核心或 SEO 外掛產生，Polylang 不保證每個語言各有獨立檔案。重點是可索引的語言網址有被納入；Sitemap 只協助發現網址，不保證收錄。可對照Sitemap 產生與提交實作教學。
4. 語言切換連結是可爬的：使用可被搜尋引擎解析的連結，讓使用者與搜尋引擎能在版本間移動；hreflang 仍須在頁面或 sitemap 中正確提供。
5. 結構化資料的多語系處理：只使用目前受 Google 支援、與頁面可見內容一致的類型；結構化資料不保證複合式搜尋結果，FAQ 複合式結果已在 2026 年停止顯示。
6. 網站速度沒有因設定而退步：用 PageSpeed Insights 與實際裝置比較各語言的重要頁面。Core Web Vitals 綠色門檻是改善目標，不是搜尋排名的單一及格線。
7. Search Console 與原始碼檢查：Google 已移除 Search Console 的「國際定位」報表。可依需要驗證網域或 URL-prefix 資源，檢查索引狀態，並直接抽查頁面原始碼中的 hreflang 與 canonical。
8. 翻譯品質的最終審核：重要的法規、商品與品牌頁面應由熟悉目標市場的合格人員審稿。機器翻譯可協助初稿，但不能免除內容責任。

這八項看似瑣碎，卻是多語系網站能不能真正拿到國際流量的分水嶺。把技術性的 SEO 基礎工程跟翻譯品質這兩件事都做到位，你的多語系投資才會開始有回報。

你的下一步行動方案

讀到這裡，你已經把 Polylang 從概念、架構、安裝、翻譯、SEO 一路走完一遍。知識如果停在這裡就只是知識，要變成資產，得動手做。落地執行可拆成五個具體的下一步，你可以今天就開始走。

第一步，決定網址架構。回到前面那張對照表，在你目前的資源、市場優先順序、預算下，選定子目錄、子網域或不同網域其中一個。這個決定寫下來之後不要再改。

第二步，盤點要翻譯的內容清單。把你網站現有的頁面與文章列出來，標記哪些是「非翻不可」（首頁、關於我們、核心商品頁、聯絡資訊）、哪些是「可以晚點翻」（部落格長尾文章）。優先把心力砸在會帶來轉換的關鍵頁面，避免無差別全翻。

第三步，安裝 Polylang 並設定好四個關鍵選項。照前面講的順序：新增語言、設好網址結構、決定瀏覽器偵測、配置同步設定。裝完先不要碰任何翻譯，把骨架設對最重要。

第四步，挑一篇流量最高的核心文章，完整跑一遍翻譯流程。從建立翻譯、字串翻譯、語言切換器、到 hreflang 抽查，把整條流程用一篇文章走通。一旦這篇走通了，後面大量內容就是複製同樣的節奏。

第五步，上架前過一次八項 SEO 檢查。每一項都實際打開原始碼或 Search Console 確認，不要憑感覺。多語系 SEO 的錯誤多半無聲無息，只有用檢查清單逐項驗證，才能在傷害發生前攔下來。

多語系網站需要持續維護。翻譯品質、內容需求、可索引性與正確的 hreflang 都會影響搜尋引擎如何理解各版本，但不保證自然流量成長。先把網址架構、內容責任與上線檢查流程定清楚，再逐步擴充語言。