網站要不要做多語系？子網域、子目錄與翻譯外掛的取捨與 hreflang 實作

網站要不要做多語系，多數人是從錯的地方開始想的。想的是「多一個語言等於多一份流量」，於是加一支翻譯外掛、把選單推成兩種語言、上線，然後半年後發現英文版的每一頁都比中文版薄，兩邊都沒有排名。多出來的不是流量，是兩倍的維護面積。

這篇不打算給你「多語系一定要做」的結論。實際上我認為台灣的中小型網站裡，該做的比例遠低於在做的比例。所以第一章先講判準：什麼情況根本不該做，以及「內容減半」這個代價實際上長什麼樣子。判準過了，才有後面的技術問題。

後面會依序處理四件事：網址結構要用子目錄、子網域還是獨立的國家頂級網域（各自的 SEO 影響與 Google 官方怎麼比較）、WordPress 上四條實作路線的授權與費用結構（外掛定價頁預設顯示年繳均攤價，跟你實際每月付的錢不是同一個數字）、機器翻譯的 SEO 風險與 Google 現行政策的原文，以及 hreflang 的正確寫法與四個最常見的錯誤。繁體與簡體中文要不要分開這題，會用 IETF 的語言標籤標準與 Google 自己的文件一起回答，因為兩邊的規則不完全一樣。

先講結論：多數網站不該做多語系

多語系是一個會持續扣血的決定。你每寫一篇新文章、每改一次價格、每換一次聯絡方式、每加一個表單欄位，成本都乘上語言數。這不是一次性的建置費用，是往後每一天的固定支出。

所以判斷的順序應該倒過來：先問「我有沒有能力永久維持第二個語言版本」，再問「值不值得做」。多數人是先被「值不值得」說服，然後在能力那一關撞牆。

三個「先不要做」的訊號

第一，中文版本身還沒有排名。這是最常見的一種。中文版一個月三百次曝光、沒有任何關鍵字進前二十名，然後決定加英文版來「擴大市場」。這件事的邏輯漏洞在於：搜尋排名是內容品質與網站權重的結果，不是語言數量的結果。中文做不起來，多半是內容深度、內鏈結構或技術地基有問題，這些問題會原封不動地複製到英文版，而且因為英文的競爭對手更多，結果只會更慘。先把單一語言做到有數據可看，這件事的優先順序遠高於多語系。如果你連現在哪些字有曝光都不知道，那要補的是Search Console 的驗證與基本報表判讀，不是翻譯外掛。

第二，你沒有第二語言的內容產能。誠實回答一個問題：接下來十二個月，你能不能每個月產出等量的英文（或日文、越南文）內容，而且是有人審過的內容？不能的話，第二語言版本會在三個月內固定下來，變成一組不再更新的靜態頁。搜尋引擎那邊看到的是一個大部分內容停在某個時間點的區塊，讀者那邊看到的是價格與服務內容跟中文版對不起來。

第三，你的目標客群其實看得懂中文。很多台灣的服務業網站加英文版，是為了「看起來比較專業」。這是品牌需求，不是 SEO 需求，而且它有更便宜的做法：做一頁完整的英文說明頁就好，不需要整站雙語。整站雙語的維護成本，跟一頁英文介紹的維護成本，差了一個數量級。

什麼情況值得做

反過來，下面這幾種情況，多語系是真的會回本的：

• 你有明確的第二市場，而且該市場的人不會用中文搜尋。例如做外銷的製造商、接歐美客戶的接案工作室、面向東南亞的電商。這種情況下英文版不是加分項，是入場券。
• 你的產品或服務本身就是跨語言的。軟體、線上課程、數位商品，複製成本近乎零，多一個語言就是多一批可以觸及的付費者。
• 你在做的是在地服務，但客人是外國人。民宿、診所、租車、代辦。這一類的頁面數量通常不多（十到三十頁），而且改動頻率低，維護成本可以接受。
• 法規或客戶要求。投標、認證、B2B 客戶的供應商審查，有時候會直接要求英文版官網。這時候沒得選，但也代表你可以把範圍限縮在被要求的那幾頁。

注意這四種情況的共同點：都能講出「誰會用什麼語言搜什麼字，然後買什麼」。講不出來的話，多語系就只是一個聽起來很進取的支出。

內容減半的真實算法

「內容減半」不是修辭。假設你現在有 80 篇中文文章，每個月新增 4 篇。加上英文版之後，如果產能沒有增加，實際會發生的是這樣：

1. 存量的翻譯債。80 篇要補英文版。一篇 3,000 字的文章，就算用機器翻譯打底，人工審修一篇抓 1.5 到 3 小時（後面談 MTPE 那段會拆得更細）。80 篇就是 120 到 240 小時。這是你在按下「啟用多語系」之前不會想到的那一筆。
2. 流量的攤薄。如果你沒有增加產能，每月 4 篇會變成中文 2 篇加英文 2 篇。中文版的成長速度直接砍半，而英文版從零開始累積權重，短期內兩邊都不會好看。
3. 維護面積翻倍。改一次導覽列文字、換一次頁尾的聯絡資訊、修一個表單、調一次價格，都要做兩次。而且漏掉的那一次不會有人通知你。

所以比較誠實的算法是：做多語系的前提，是你能把總產能提高到原來的兩倍，或者你接受中文版的成長暫停一年。兩個都做不到，就先不要做。

還有一個常被忽略的成本是技術面的。翻譯外掛會在每一次頁面請求時做語言判斷、字串比對與網址改寫，資料庫的資料表也會變多。網站本來就吃力的話，加上多語系通常會讓載入時間再往上跳一階，這一點在Core Web Vitals 三項指標的實測與修正那篇有更完整的量測方式。真的要裝之前，順手把外掛清單精簡一輪是划算的，因為多語系外掛通常是整站權重最重的那一支。

網址結構三選一：子目錄、子網域、獨立 ccTLD

判準過了，第一個技術決定就是網址長什麼樣。這個決定很難回頭改——改網址結構等於整站搬家，要做全站 301，而且會有一段權重重新累積的空窗期。所以值得花時間想清楚。

Google 官方對四種結構的比較

Google Search Central 的〈Managing multi-regional and multilingual sites〉列出四種選項，並各自標出優缺點。以下是官方原文列出的內容：

結構	範例	Google 列的優點	Google 列的缺點
國家專用網域（ccTLD）	example.de	地區定位訊號明確；伺服器位置無關緊要；站與站容易分離	昂貴（有時取得受限）；需要更多基礎設施；有些 ccTLD 有嚴格申請條件；只能鎖定單一國家
子網域加通用網域	de.example.com	容易設定；可以放在不同伺服器位置；站與站容易分離	使用者可能光看網址分不出這是地區定位（「de」是語言還是國家）
子目錄加通用網域	example.com/de/	容易設定；維護成本低（同一台主機）	使用者可能光看網址分不出是地區定位；單一伺服器位置；站與站較難分離
網址參數	site.com?loc=de	（官方未列優點）	Google 明確標示「不建議」：以網址切分困難；使用者難以辨識

這張表最值得注意的是它沒有說的部分：Google 沒有把任何一種列為「SEO 比較好」。四種結構在排名上沒有官方宣稱的優劣，差別在於維運成本、地區定位訊號的明確程度，以及你有沒有能力管理多個獨立站台。

子目錄為什麼是多數人的預設答案

如果你是一人或小團隊在經營一個 WordPress 網站，子目錄（example.com/en/）幾乎一定是對的選擇，理由有三個。

第一，權重不分散。這是實務上最重要的一點，雖然 Google 從未正式宣告子網域與主網域的權重是分開計算的。但無可爭議的事實是：子目錄跟主網域是同一個主機名稱，所有指向網站任何一頁的外部連結，都在同一個網域名稱底下累積。子網域與 ccTLD 則需要各自建立自己的連結資產。對一個外部連結本來就不多的網站來說，把有限的權重集中在一個網域，比分成兩份合理得多。

第二，設定與維護最便宜。一套 WordPress、一組憑證、一份備份、一次更新。ccTLD 路線通常意味著多站台，備份與更新的工作量會直接乘上站台數。這件事在你真的要還原一次備份的時候感受最深刻，做法可以參考外掛、主機端與異地備份的三層策略。

第三，WordPress 外掛的預設支援最完整。Polylang、WPML、TranslatePress 三者都支援子目錄，而且是預設模式；子網域與獨立網域在部分外掛裡是付費方案才有的功能（TranslatePress 的「Different Domain per Language」附加元件就掛在 Business 以上方案）。

什麼情況才值得用子網域或 ccTLD

子網域有一個子目錄做不到的優勢：可以放在不同的伺服器位置。如果你的第二語言市場在歐洲，而主站放在台灣的主機上，用子網域搭配當地的主機或 CDN，實際的載入速度會有可觀差距。要不要為此付出多維護一套環境的代價，取決於那個市場對你的營收貢獻。主機選擇的取捨可以看共享、VPS 與託管型主機的比較。

ccTLD 的門檻更高，值得用的情況大致只有三種：你在該國有實體營運據點、該國消費者對本地網域有明確偏好、或者你必須把不同市場的法律責任與營運主體完全切開。

另外有一個容易踩的坑：不是所有國碼網域都會被當成國家訊號。Google 的文件明白寫著，有些國碼網域（例如 .tv、.me）被當成通用網域處理，因為「使用者與網站經營者普遍認為這些網域偏通用、而非鎖定特定國家」。官方列出的這類網域包含 .ad、.ai、.as、.bz、.cc、.cd、.co、.dj、.fm、.io、.la、.me、.ms、.nu、.sc、.sr、.su、.tv、.tk、.ws，並註明清單可能變動。買一個 .io 想拿到英屬印度洋領地的地區定位，是不會發生的事。

兩個常被誤會的點

其一，Google 不看網址判斷語言。這一點很多人搞錯。Google 的文件寫得非常直接：「Google 使用你頁面上可見的內容來判斷語言。我們不使用任何程式碼層級的語言資訊，例如 lang 屬性或網址。」在 hreflang 的說明裡，Google 又補了一次：範例中的 en、en-gb、de 這些子網域名稱「不會被 Google 用來判斷頁面的目標受眾，你必須明確地標示目標受眾」。

所以把網址取成 /en/ 不會讓 Google 認定那是英文頁；讓 Google 認定的是頁面上實際的英文內容，以及你設定的 hreflang。這也解釋了為什麼「只翻譯導覽列和頁尾、內文維持中文」這種半套做法會出問題——Google 的多語系文件直接點名了這個情境，說這會造成「同一份內容配上不同語言的模板，重複出現在搜尋結果中」的糟糕體驗。

其二，不要在同一頁上並列兩種語言。官方的建議是「每一頁的內容與導覽使用單一語言，並避免並列翻譯」。左右對照的雙語版面在紙本上很好用，在搜尋引擎眼裡是一頁語言不明的內容。

WordPress 的四條實作路線與費用結構

選好網址結構之後才輪到選工具。WordPress 上的多語系方案大致可以分成四類，差別不只在價格，更在翻譯內容存在哪裡——這決定了你哪一天想換方案時，資料搬不搬得走。

路線一：資料庫型（Polylang、WPML）

這一類的做法是「一種語言一篇文章」。中文版是一筆文章，英文版是另一筆文章，兩者之間建立關聯。優點是所有內容都是原生的 WordPress 文章，可以正常編輯、正常搜尋、正常被其他外掛處理；缺點是文章數量會隨語言數等比膨脹。

Polylang 的免費版在 WordPress.org 上有 80 萬以上的啟用數，本身就支援多語系、hreflang 標籤與語言切換器。Polylang Pro 的官網公告價為：1 站 99 歐元、3 站 198 歐元、5 站 297 歐元、25 站 495 歐元，屬年繳授權，官網並註明「續約目前享 50% 折扣」。Pro 版加的是網址代稱（slug）翻譯、可選子目錄或子網域或獨立網域、與 DeepL 的機器翻譯整合等。要注意 Polylang 官網自己標註的兩個限制：DeepL 整合需要你自備 DeepL 的 API 金鑰，而且目前不相容於 Elementor 與部分頁面編輯器；官網也明講「Polylang Pro 不提供一鍵『翻譯全站』的功能」。

WPML 是老牌的付費方案，沒有免費版。官網目前公告三個方案：Multilingual Blog 39 歐元、Multilingual CMS 99 歐元、Multilingual Agency 199 歐元，皆含一年的支援與更新。實際上多數人需要的是 99 歐元那一階，因為 39 歐元的 Blog 版不含字串翻譯（佈景主題與外掛吐出來的文字）、不含頁面編輯器支援、不含選單翻譯、不含 WooCommerce 支援，這幾項對一個真的要上線的網站幾乎都是必要的。CMS 方案含 9 萬點 AI 翻譯額度，Agency 方案含 18 萬點。授權站數：Blog 是 1 個正式站加 3 個開發站，CMS 是 3 個正式站加 9 個開發站，Agency 不限。

WPML 官網的常見問題另外寫明一件重要的事：不續約的話，「WPML 會繼續在你的網站上運作，所有翻譯都會繼續顯示，但你無法更新到新版本」。也就是說授權過期不會讓網站壞掉，但會停在一個逐漸過時的版本上——這是安全風險而不是功能風險。

路線二：前端擷取型（TranslatePress）

TranslatePress 的做法不同：它不複製文章，而是把頁面前端輸出的字串抓下來，讓你在一個所見即所得的介面上逐段翻譯，譯文存在自己的資料表裡。好處是不管內容從哪來（文章、佈景主題、外掛、頁面編輯器），只要顯示在前台就能翻；壞處是譯文與原文的關聯建立在字串上，原文改一個字，那一段的譯文就要重新處理。

免費版在 WordPress.org 上有 40 萬以上的啟用數。付費方案的定價頁是一個很好的範例，說明「年繳均攤」跟「實際月付」的差別：頁面上大字寫著 Personal 每月 8.25 歐元，小字才寫「按年計費，每年 99 歐元」。99 除以 12 正好是 8.25，所以那個 8.25 是年繳金額攤到每個月的數字，不是你可以選的月付方案——這一頁沒有月付選項，底下明白寫著「價格皆按年計費、每年自動續訂」。三個方案分別是：Personal 每年 99 歐元（1 站、5 萬字 AI 翻譯額度）、Business 每年 199 歐元（3 站、20 萬字）、Developer 每年 349 歐元（不限站數、50 萬字）。

AI 額度用完可以另外加購，官網公告的加購價是 10 萬字 24 歐元、20 萬字 40 歐元、50 萬字 90 歐元、100 萬字 160 歐元。要注意的是，「Different Domain per Language」（每個語言用不同網域）與 DeepL 整合都要 Business 以上才有，所以如果你打算走獨立網域路線，Personal 方案不夠用。

路線三：全託管翻譯服務（Weglot 這一類）

第三條路線是把翻譯整個外包給第三方服務：你的網站裝一支輕量外掛或改一段程式碼，內容送到對方的伺服器翻譯並託管，語言版本的網址由對方提供。優點是設定最快、幾乎不需要技術知識；缺點是你的譯文不在自己手上，而且計價通常是按字數與語言數，跟你的網站規模直接綁在一起。

以 Weglot 官網公告的定價為例，它是少數同時提供真月付與年付的方案，兩種價格的差距可以直接看出來。免費方案 0 元，限 2,000 字、1 種語言；Starter 每月 15 歐元，或每年 150 歐元（限 1 萬字、1 種語言）；Business 每月 29 歐元，或每年 290 歐元（限 5 萬字、3 種語言）；Pro 每月 79 歐元，或每年 790 歐元（限 20 萬字、5 種語言）；Advanced 每月 299 歐元，或每年 2,990 歐元（限 100 萬字、10 種語言）。年繳等於付十個月的錢，官網自己標示為「年繳送兩個月」。

這裡有一個定價陷阱要看懂：Weglot 官網對字數的定義是「跨所有語言翻譯的不重複字總數」，而且註明這是一個固定上限、不會每月重置。也就是說這不是「每月可翻多少字」的流量制，是「你的網站總共有多少字」的規模制。一個 80 篇、每篇 3,000 字的中文站，光原文就遠超過 Starter 的 1 萬字上限。用這類服務前，先把自己網站的實際字數算出來，不然方案會挑錯一到兩階。

路線四：多站台（各自獨立的 WordPress）

最後一條路線是不用翻譯外掛，直接開第二個 WordPress。走 ccTLD 或子網域的人常常會走到這裡。它的好處是兩邊完全獨立、互不影響，佈景主題和外掛可以各自選；壞處是兩份更新、兩份備份、兩份安全維護，而且 hreflang 要自己接（Rank Math、Yoast 這類 SEO 外掛都可以手動填寫跨網域的 hreflang，但不會自動配對）。

這條路線適合「兩個市場的內容本來就不一樣」的情況——不是同一篇文章的兩種語言，而是各自寫給各自市場的獨立內容。這種情況其實不叫多語系網站，叫兩個網站，而且通常是更誠實的做法。

四條路線的費用與取捨

路線	代表工具	官網公告價（查核日 2026-08-02）	譯文存放位置	最適合
資料庫型（免費起步）	Polylang 免費版	0 元；Pro 年繳 99 歐元起（1 站），續約官網標示享 50% 折扣	你的資料庫（原生文章）	內容不多、願意手動翻、想保留完整掌控權
資料庫型（功能完整）	WPML Multilingual CMS	99 歐元，含一年支援與更新、3 個正式站、9 萬點 AI 額度	你的資料庫（原生文章）	用頁面編輯器、有 WooCommerce、需要字串翻譯
前端擷取型	TranslatePress	年繳 99 歐元（頁面顯示為每月 8.25 歐元，即年繳均攤），Business 199 歐元、Developer 349 歐元	你的資料庫（獨立資料表）	佈景主題與外掛字串多、想用所見即所得介面翻
全託管服務	Weglot	真月付 15 歐元起；年繳 150 歐元起（等於付十個月）。字數為固定總量上限，不每月重置	服務商的伺服器	要最快上線、字數少、不介意受制於第三方
多站台	各自獨立的 WordPress	只有主機與網域成本，但工時乘上站數	各站自己的資料庫	兩個市場內容本來就不同

所有價格皆為各廠商官網於查核日公告的價目，之後可能調整，實際以官網為準：Polylang、WPML、TranslatePress、Weglot。以上皆以歐元計價，實際扣款金額還會受當日匯率與發卡行的國外交易手續費影響，這一筆記得算進去。

費用之外的三筆隱形成本

其一，鎖定成本。三種外掛的資料結構完全不同，中途換方案幾乎等於重做。Polylang 與 WPML 之間有官方的搬遷工具，但 TranslatePress 那種「譯文綁在字串上」的結構，要搬到「一種語言一篇文章」的結構，實務上就是重新翻一次。選之前先想清楚，比選之後省錢重要得多。

其二，相容性成本。多語系外掛會深度介入 WordPress 的查詢、選單、網址改寫與快取，跟頁面編輯器、快取外掛、電商外掛都可能打架。真的要上多語系的電商站，這件事的複雜度會再翻一倍，因為商品、規格變體、結帳流程、金流訊息全部要翻，可以先看WooCommerce 從安裝到金流物流的完整流程，把單語言版本跑順了再談雙語。

其三，關鍵字研究的成本。這一筆最常被漏掉。把中文文章翻成英文，不等於你選對了英文關鍵字。中文的「網站架設費用」直翻是 website building cost，但英文市場實際被搜尋的可能是 how much does a website cost。直翻的標題幾乎不會命中真正有搜尋量的字。每個語言都要重做一次關鍵字研究，工具與方法可以參考免費與付費關鍵字工具的搭配方式。這一項的工時，通常比翻譯本身還多。

機器翻譯的 SEO 風險：Google 實際怎麼說

這一段是全篇最多人講錯的地方，而且錯的方向兩邊都有：一邊說「機器翻譯一定被懲罰」，另一邊說「Google 早就不管了，隨便翻」。兩個都不對。我們直接看官方條文。

2024 年 3 月之前：政策明文寫過機器翻譯（此條文已撤下）

先標清楚性質：以下這段是歷史沿革，不是現行政策。這一條在今天的 Google 頁面上已經找不到，引用它來主張「Google 現在禁止機器翻譯」是錯的。但知道它存在過，才看得懂為什麼網路上一堆文章還在這樣寫。

Google 的垃圾內容政策（spam policies）曾經有一節叫做「Spammy automatically-generated content」（濫用性的自動產生內容），其中逐條列出的例子包含這一句：

「Text translated by an automated tool without human review or curation before publishing」——未經人工審閱或編修即發布、由自動化工具翻譯的文字。

這一條在 2024 年 1 月 14 日的頁面封存版本上仍然存在，可以自己開來對照。也就是說，在那個時間點之前，「機器翻譯直接發布」確實是被政策白紙黑字點名的行為；2024 年 3 月之後，這一節整個被下面要講的新條文取代了。

2024 年 3 月之後：改成「大規模濫用內容」

2024 年 3 月，Google 在核心演算法更新的同時公告三項新的垃圾內容政策，其中一項是「scaled content abuse」（大規模濫用內容）。Google 在公告文章裡直接說明了這是取代關係：

這項新政策建立在我們先前關於自動產生內容的垃圾內容政策之上，確保我們能在必要時對大規模濫用內容採取行動，無論內容是透過自動化、人力，還是人力與自動化的組合所產生。

同一篇公告裡，Google 用一個自問自答把新舊政策的差別講得很清楚：新政策的用意，是讓大家更清楚地聚焦在一個概念上——如果目的是操縱搜尋排名，大規模產製內容就是濫用，而且不論涉及的是自動化還是人力。

現行的政策條文（頁面標示最後更新 2026 年 5 月 15 日）在「大規模濫用內容」的例子裡，翻譯仍然被點名，只是被放進了一個更大的句子：

抓取資訊摘要、搜尋結果或其他內容來產生大量頁面（包含透過同義詞替換、翻譯或其他混淆技術等自動化轉換），且提供的價值極低。

那到底能不能用機器翻譯

把三段官方文字放在一起，結論其實很明確，而且跟直覺不太一樣：Google 從來沒有禁止機器翻譯這個工具，它禁止的是「大規模產出低價值頁面」這個行為。舊政策把「未經人工審閱的機器翻譯」當成這個行為的典型症狀，新政策把描述往上抽象了一層，但症狀沒有變。

換成可以執行的判準，我會這樣分：

1. 機器翻譯打底、逐句人工審修、譯後有人負責品質：這是完全正常的工作流程，跟任何專業翻譯公司的做法一樣。Google 的政策從頭到尾針對的是「未經人工審閱」，不是「用了機器」。
2. 機器翻譯直接發布，但只有少量頁面（例如十幾頁的公司介紹）：不太可能構成「大規模」，但會有另一種代價——譯文品質差會直接傷害轉換率與品牌觀感，而且讀者的離開行為長期來看對排名沒有好處。這是產品問題，不是政策問題。
3. 機器翻譯直接發布幾百上千頁，目的是搶排名：這正是「大規模濫用內容」描述的行為，而且不需要有人檢舉，這類頁面通常在演算法層面就拿不到名次。

還有一個技術面的注意事項：如果你用的是翻譯小工具那種「在瀏覽器端即時翻譯」的方案，那些譯文根本不會被索引，因為它們不存在於伺服器回傳的 HTML 裡，也沒有各自獨立的網址。這種做法對使用者可能有幫助，但對 SEO 是零，別把它當成多語系。

MTPE 的真實工作量

「機器翻譯加人工後編修」在翻譯業界有個正式名稱叫 MTPE（Machine Translation Post-Editing），而且它的計費方式跟純人工翻譯是分開的。實務上要注意兩件事。

第一，後編修不是「掃一遍看看有沒有怪怪的」。機器翻譯最會出錯的地方，恰好是搜尋引擎最在意的地方：專有名詞、產品名、技術術語，以及帶有行動意圖的句子（按鈕文字、表單標籤、行動呼籲）。這些字在原文裡只佔一小部分，但錯了就毀掉整頁的可信度。

第二，品質差的原文會讓後編修比重譯還慢。中文原文如果句子長、主詞省略多、用了大量成語與雙關（台灣的行銷文案很愛這樣寫），機器翻出來的東西會需要整句重寫。這種情況下 MTPE 的省時效果接近零。想知道翻譯這一行實際怎麼計價、MTPE 的行情跟純翻譯差多少，可以看翻譯接案的計價方式與 MTPE 現實那篇，從發案方的角度看也很有用——它會告訴你外包一輪要花多少錢，好跟「自己來」的工時做比較。

hreflang 的正確寫法

hreflang 是一組告訴 Google「這一頁還有哪些語言與地區版本」的標註。它不是排名因素，它的作用是讓 Google 在已經決定要顯示你的頁面時，挑出對這個使用者最合適的那一個版本。

這一點值得再強調一次，因為它決定了你該對 hreflang 抱多大期待：做對了，你會看到搜尋結果裡出現的是使用者語言的版本；做錯了，會發生的是使用者被丟到看不懂的版本，或是兩個語言版本互相干擾。它不會讓你從第 20 名變成第 3 名。

三種實作位置，效果相同

Google 的文件寫明三種方法「從 Google 的角度來看是等價的，你可以選任何一種」：

• HTML 的 link 標籤：放在 head 裡。最常見，也是所有 WordPress 多語系外掛的預設做法。Google 特別提醒標籤必須在「格式正確的 head 區段」內，而且不要把 hreflang 跟其他屬性（例如 media）混在同一個 link 標籤裡。
• HTTP 回應標頭：用 Link: 標頭。這是唯一能替非 HTML 檔案（例如 PDF）標註語言版本的方法。
• XML sitemap：用 xhtml:link 子元素。頁面數量多的時候這個方法最好維護，因為所有標註集中在一個檔案裡，改起來不用動頁面本身。

三種只要選一種，不要重複做。同時放在 HTML 與 sitemap 裡不會加分，只會讓你之後除錯時多一個要對照的地方。

一組最小可用的範例

假設你有一個繁體中文為主的網站，加了英文版，網址結構走子目錄。那麼中文頁與英文頁的 head 裡都要放同一組三行標籤，一字不差：

<link rel="alternate" hreflang="zh-Hant" href="https://example.com/pricing/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

三個重點：每一頁都要列出自己（Google 的原文是「Each language version must list itself as well as all other language versions」）；網址必須是完整網址並含通訊協定，https://example.com/foo 可以，//example.com/foo 或 /foo 都不行；每一頁的這組標籤內容完全相同。

如果用的是 sitemap 的做法，Google 文件說得更直白：如果你有 3 個版本的頁面，你的 sitemap 就會有這三個版本各自的網址項目，而每一個項目底下都有 3 個一模一樣的子項目。

x-default 是什麼，什麼時候要放

x-default 是一個保留值，用途是「當使用者的瀏覽器語言設定跟你所有的語言版本都對不上時，要把他送到哪一頁」。Google 說明這個值「原本是為語言選擇頁設計的，所以搭配那類頁面效果最好」，而且不需要為它指定語言碼，因為那一頁的語言本來就不重要。

實務上如果你只有中英兩種語言，把 x-default 指向主要語言版本（通常是原始語言）是安全的做法。有語言選擇頁的話就指向選擇頁。沒放不會壞，但放了對非中非英的使用者比較友善。

hreflang 最常見的四個錯誤

Google 的官方文件底下有一節就叫「Common Mistakes」，列了三項。第四項（跟 canonical 打架）不在那份清單裡，但它是實務上最容易讓整組標註失效的原因，所以我把它一起放進來，並且會標明哪些是官方原文、哪些是實務歸納。

錯誤一：缺少自我參照

最常見，也最容易犯，因為它在直覺上是多餘的——「這一頁就是中文版，為什麼還要在中文版上寫『中文版在這裡』？」

原因是 Google 是把整組標註當成一個集合在處理的。少了自我參照那一行，這個集合就不完整，Google 可能無法確定這一頁在集合裡的身分。官方在「所有方法通用的準則」第一條就寫了這件事，而且在 sitemap 與 HTTP 標頭兩節裡各重複了一次「including itself」（包含它自己）。

WordPress 的多語系外掛通常會自動處理這一項。會出錯的是手動貼標籤的情況，尤其是走多站台路線、自己在 SEO 外掛裡填 hreflang 的時候。

錯誤二：語言碼寫錯

Google 對格式的要求非常具體：語言碼要用 ISO 639-1，地區碼（可選）要用 ISO 3166-1 Alpha 2，而且只有列在這兩份標準裡的碼才支援。官方直接舉了一個不支援的例子：es-419（拉丁美洲西班牙文）不被支援。

官方在這一節放了一個警告框，內容是很容易踩到的：「你不能單獨指定國家碼。第一個碼代表的是語言，Google 不會自動從國家碼推導出語言。」它舉的例子是比利時：de-be（比利時的德語）、nl-be（比利時的荷語）、fr-be（比利時的法語）都正確，但單獨寫 be 是錯的，因為 be 是白俄羅斯語的語言碼。

另一個高頻錯誤是地區碼。Google 說如果你用了「被保留作其他用途」的碼，那部分標註會被忽略，並點名三個：EU、UN、UK。英國的正確地區碼是 GB 不是 UK——這一個錯誤在中文的 SEO 教學文裡出現的頻率高得驚人。

錯誤三：單向沒有互指

這一項是三項官方常見錯誤裡後果最嚴重的，因為它會讓整組標註直接被忽略。Google 的原文是：「如果兩個頁面沒有互相指向對方，這些標籤會被忽略。」而且官方解釋了為什麼要這樣設計：這是為了避免其他網站上的某個人，任意建立一個標籤、宣稱自己是你某一頁的替代版本。

所以 hreflang 本質上是一種雙方同意的機制。A 頁說「我的英文版是 B」，B 頁也要說「我的中文版是 A」，這組關係才成立。

官方還補了一段很實用的例外處理：「如果要為每一種語言維護一組完整的雙向連結變得困難，你可以在某些頁面上省略某些語言；Google 仍然會處理那些互相指向的部分。」但接著提醒，新擴充的語言頁面一定要跟原始或主要語言雙向連結。翻成白話：優先確保每個新語言版本跟主語言之間是通的，新語言彼此之間可以先不通。

還有一種變形的單向錯誤，是網址對不上：中文頁指向 https://example.com/en/pricing/，但英文頁的實際網址是 https://example.com/en/pricing（沒有尾斜線），或者其中一邊是 http、另一邊是 https。這種情況下 Google 看到的就是兩個不同的網址，互指關係不成立。hreflang 裡的網址必須是最終網址，不能是會 301 跳轉的那一個。

錯誤四：跟 canonical 打架

先說清楚：這一項不在 Google 官方的「常見錯誤」清單裡。以下是把官方兩份文件合起來讀之後的實務歸納。

Google 在 hreflang 文件裡寫了一句關鍵的話：「頁面的在地化版本只有在主要內容仍未翻譯的情況下，才會被視為重複內容。」也就是說，真的翻譯過的中文版與英文版，Google 本來就不當成重複內容，不需要用 canonical 去指定誰是正版。

而在多地區網站的文件裡，Google 說明了 canonical 該用在哪裡：「如果你在多地區網站上，於不同網址提供相同語言的相似或重複內容（例如 example.de/ 與 example.com/de/ 顯示相似的德文內容），請挑一個偏好的版本，並使用 rel="canonical" 元素搭配 hreflang 標籤。」

兩段合起來，分工就很清楚：canonical 負責在「同一語言的重複頁」之間挑代表，hreflang 負責在「不同語言版本」之間對應。把英文頁的 canonical 指到中文頁，等於告訴 Google「英文頁不是我要被索引的那一頁」，Google 索引中文頁，英文頁上的 hreflang 就沒有作用對象了。

這個錯誤在 WordPress 上有一個典型的觸發方式：多語系外掛正常輸出 hreflang，但 SEO 外掛的 canonical 設定沒有跟著語言走，於是所有語言版本的 canonical 都指向原始語言。每一個語言版本的 canonical 應該指向它自己。上線後一定要逐一語言版本檢查一次，這是十分鐘就能做完、但漏掉會白做半年的檢查。

怎麼驗證：一個要先知道的壞消息

過去 Search Console 有一個「國際定位」（International Targeting）報表，可以看 hreflang 的錯誤清單。這個報表已經停用了。Google 的說明頁寫著：使用 Search Console 的國家定位功能來鎖定搜尋結果「經評估對整個生態系的價值不高，已不再支援」，但同一頁也明確保證「Google 會繼續支援並使用你頁面上的 hreflang 標籤」。

所以標註本身仍然有效，只是官方的除錯報表沒了。現在可行的驗證方式有三種：

1. 用 Search Console 的網址檢查工具，看實際擷取到的已轉譯 HTML 裡有沒有你預期的那組標籤。這一步能抓出「外掛設定看起來對、但前台其實沒輸出」的情況，包含被快取外掛吃掉的狀況。
2. 直接看原始碼。每個語言版本各開一頁，逐字比對三件事：有沒有自我參照、網址是不是完整且最終的網址、canonical 是不是指向自己。
3. 用第三方的 hreflang 檢查工具。Google 自己的文件底下就列了兩個並註明「這些工具不由 Google 維護或檢查」，等於是預設你會用外部工具。用歸用，最終仍以原始碼為準。

繁體與簡體中文，要不要分成兩個版本

這是台灣網站獨有的一題，而且它比中英切分更麻煩，因為繁簡不只是字形轉換，還牽涉到詞彙差異。先看標準怎麼定義，再談實務。

BCP 47 怎麼寫

語言標籤的國際標準是 IETF 的 BCP 47，目前的正文是 RFC 5646。它把標籤拆成「語言、文字系統、地區」三層，而中文正好是文件裡最常被拿來當範例的語言。RFC 5646 的範例清單裡直接列了這幾個：

• zh-Hant：以繁體中文字（Traditional Chinese script）書寫的中文
• zh-Hans：以簡體中文字（Simplified Chinese script）書寫的中文
• zh-Hans-CN：以簡體字書寫、用於中國大陸的中文

對應到台灣就是 zh-Hant-TW。文件也說明了這三層的關係：如果語言標籤 B 包含語言標籤 A 作為前綴，那麼 B 通常比 A 更窄或更明確；因此 zh-Hant-TW 比 zh-Hant 更明確。

但 RFC 5646 同時給了一個很重要的節制原則：只有在子標籤能為標籤增加有用的區別資訊時，才應該使用它；多餘的子標籤會干擾語言標籤的意義、理解與處理。文字系統子標籤那一條講得更具體：除非文字系統能為標籤增加區別性資訊，否則不應該用文字系統子標籤來構成語言標籤。

換句話說，標準本身不鼓勵你把標籤寫到最長，它鼓勵你寫到「剛好足以區別」的長度。中文的情況是，繁簡確實是有意義的區別，所以 zh-Hant 這一層是站得住腳的；至於要不要再加地區，取決於你是不是真的針對特定地區做了不同的內容。

Google 的 hreflang 支援哪些寫法

Google 這邊的規則跟 BCP 47 不完全一樣，這是實務上最容易踩到的落差。官方文件寫的是：語言碼用 ISO 639-1，可選的第二段是 ISO 3166-1 Alpha 2 的地區碼，「只有列在這兩份標準裡的碼才支援」。

但同一頁接著有一段專門講中文的說明，非常值得逐字看：

至於語言的文字系統變體，正確的文字系統會從國家推導出來。例如使用 zh-TW 給台灣的使用者時，文字系統會被自動推導（在這個例子裡是：繁體中文）。你也可以使用 ISO 15924 明確指定文字系統，像這樣：zh-Hant（繁體中文）、zh-Hans（簡體中文）。跟其他語言碼一樣，你也可以再指定一個可選的地區。例如用 zh-Hans-US 來指定給美國使用者的簡體中文。

這一段解決了兩個疑問。第一，zh-TW 是可以用的，而且 Google 會自己推導成繁體。第二，Google 明確支援三段式的寫法（它自己舉的例子就是 zh-Hans-US），所以 zh-Hant-TW 是合法的，即使同一頁前面那句「一個或可選的兩個值」讀起來像是只允許兩段。

實務建議：三種情境

情境一：只服務台灣，沒有簡體需求。那就不要分。網站只有一種中文，hreflang 用 zh-Hant 或 zh-TW 都可以，選一個然後全站一致。我個人偏好 zh-Hant，因為它描述的是「這是繁體中文」這件事實，不預設讀者一定在台灣，香港、澳門與海外華人也讀繁體。

情境二：要做簡體版，內容只做字形轉換。老實說我不建議這樣做，但如果一定要，至少要知道你在做什麼：繁簡轉換工具處理不了詞彙差異。台灣說「影片」「軟體」「網路」「品質」「資訊」「預設」，對岸的對應說法全部不同，字形轉完之後仍然是台灣用語，只是換了字形。對真正的目標讀者來說，這是一個讀起來明顯是外地人寫的版本。而且從 Google 的角度，兩份主要內容高度相同、只有字形不同的頁面，落在「主要內容未真正翻譯」的灰色地帶。

情境三：要做簡體版，而且做在地化。詞彙、幣別、案例、法規、聯絡方式全部換成當地版本。這時候用 zh-Hant-TW 與 zh-Hans-CN 分開是正確的，因為兩個版本確實是不同的內容，不只是不同的字形。但也請誠實評估：這已經不是「加一個語言」，是經營第二個市場。需要的投入跟前面講的英文版一樣多，甚至更多，因為中國大陸的搜尋市場主力不是 Google。

lang 屬性跟 hreflang 不是同一件事

最後補一個常被混在一起的東西。HTML 的 lang 屬性（例如 lang="zh-Hant-TW"），跟 hreflang 是兩套獨立的機制，用途也不同。

Google 的多語系文件講得很白：「Google 使用你頁面上可見的內容來判斷語言。我們不使用任何程式碼層級的語言資訊，例如 lang 屬性或網址。」所以就 Google 排名而言，lang 屬性不影響什麼。

但它對螢幕報讀器影響很大——報讀器靠這個屬性決定用哪一種語音引擎念，寫錯的話中文內容會被用英文發音規則念出來，完全聽不懂。這是無障礙的基本要求，跟語言切換器的鍵盤操作、對比度一樣屬於必檢項目，可以對照WCAG 重點與八個常見問題那篇的檢查清單。多語系外掛通常會自動處理 lang，但佈景主題把語言碼寫死的情況並不少見，值得看一次原始碼確認。

語言切換的介面與使用者體驗

技術做完了，還有一半的工作在使用者這一端。這一段的每一條都有官方依據，而且都是被違反得很頻繁的。

不要自動重導

這是 Google 講得最重的一條。官方原文：「避免自動把使用者從網站的某個語言版本重導到另一個語言版本。例如，不要根據你認為使用者的語言是什麼來重導。這些重導可能會讓使用者（以及搜尋引擎）無法瀏覽你網站的所有版本。」

接著的建議是：考慮加入指向其他語言版本的超連結，讓使用者可以點選切換。也就是說，Google 要的是使用者主動選，不是你替他決定。

還有一條相關的：「不要用 IP 分析來調整你的內容。IP 位置分析困難且通常不可靠。而且 Google 可能無法正確爬取你網站的各個變體。Google 的爬取大多（但不是全部）來自美國，而我們不會嘗試變換位置去偵測網站的變體。」

這一段解釋了一個常見的災難：站長設定了「偵測到非台灣 IP 就跳英文版」，結果因為 Googlebot 大多從美國發出請求，Google 從此只看得到英文版，中文版形同不存在。同一份文件也提醒，Googlebot 送出的 HTTP 請求不會設定 Accept-Language 標頭，所以靠瀏覽器語言判斷來動態切換內容的做法，對爬蟲同樣無效。

切換器要放哪、長什麼樣

幾條實務原則，都很無趣但有效：

• 放在頁首右上或頁尾，兩個位置擇一並全站一致。使用者找不到切換器的時候，會去這兩個地方找。
• 用語言自己的名字寫，不要用翻譯過的名字。寫 English 不要寫「英文」，寫「日本語」不要寫「日文」。找英文版的人，看得懂的是 English 這個字。
• 不要只用國旗。國旗代表國家不代表語言：英文不只英國在用，西班牙文不只西班牙在用，而且對某些地區的使用者，用錯國旗是政治問題。要用國旗就搭配文字，或乾脆只用文字。
• 語言數超過五種就用下拉選單，五種以內用並排的文字連結。並排連結的點擊成本比下拉少一次操作，能不下拉就不下拉。
• 切換器要是真的超連結。用指令碼綁在一般容器元素上的切換器，爬蟲跟不進去，鍵盤使用者也移動不到。

切換之後要落在對應的那一頁

這是使用者體驗上最大的破口，也是很多外掛的預設行為做錯的地方：使用者在一篇文章裡按下英文，結果被丟到英文版首頁。

正確的行為是切換到同一篇文章的英文版。如果那一頁沒有英文版，才需要有一個明確的降級規則。三種常見處理方式，我的建議順序是這樣：

1. 切換器上把沒有翻譯的語言隱藏或標為停用。最誠實，使用者不會白按一次。
2. 導到該語言的分類頁或最接近的上層頁，並在頁面上說明這篇尚未提供該語言版本。次佳。
3. 一律導到該語言首頁。最差，但也最常見，因為它是很多外掛的預設值。

順帶一提，沒有翻譯的頁面不要用機器翻譯臨時補上去，也不要輸出一個空白的英文版網址。前者是前面談過的品質問題，後者會產生一堆內容極少的頁面，而 Google 的 hreflang 文件已經說了：主要內容未翻譯的在地化版本會被視為重複內容。

幣別、日期與表單，也要跟著切

語言切了，但價格還是新台幣、日期還是民國年、表單的必填提示還是中文——這是「翻譯了但沒在地化」的典型症狀，而且轉換率的損失比翻譯品質差還嚴重。上線前逐一檢查這幾個地方：價格與幣別、日期格式、電話號碼格式（有沒有國碼）、地址、表單的驗證訊息與錯誤提示、電子郵件自動回覆，以及付款頁面的所有文字。最後兩項最常漏，因為它們不在前台頁面上，要實際跑一次流程才看得到。

從零開始的實作順序

把前面所有東西收成一份可以照著跑的順序。不要跳步，尤其是第一步。

第零步：確認要不要做。回到第一章的判準。中文版還沒有排名、沒有第二語言的產能、或目標客群其實看得懂中文，就停在這裡，去做別的事。

第一步：先備份，再選網址結構。備份是因為多語系外掛會改資料庫結構，退回去不像停用一支外掛那麼簡單。結構選定之後就不要再改，改一次等於整站搬家。多數情況選子目錄。

第二步：決定第一批要翻的頁面，而且刻意選少。不要一次翻整站。挑十到二十頁：首頁、服務或產品頁、聯絡頁，以及三到五篇最有流量的文章。這批做完跑一個月，你會知道自己實際的維護負擔有多大，再決定要不要擴大。

第三步：每個語言各做一次關鍵字研究。在翻譯之前做，不是之後。研究結果會直接改變你要翻哪幾頁、以及標題怎麼下。這一步跳過的話，前面所有工都可能白做。

第四步：翻譯，機器打底加人工審修。審修時重點看四個地方：標題與描述、專有名詞、行動呼籲的按鈕文字，以及所有數字與單位。

第五步：檢查 hreflang 與 canonical。每一個語言版本各開一頁看原始碼，確認三件事：有自我參照、網址是完整的最終網址、canonical 指向自己。這一步十分鐘，但漏掉會讓前面全部的工作打折。

第六步：檢查切換器與在地化細節。切換後落在對應頁面、幣別與日期格式、表單訊息、自動回覆信。實際走一次完整的詢問或購買流程。

第七步：送出 sitemap，然後等。新語言版本被索引需要時間，通常以週為單位。這段期間不要一直改結構，讓 Google 把新的網址爬完。

第八步：一個月後看數據再決定。看英文版有沒有曝光、進來的是哪些字、使用者的停留與離開情況如何。有訊號就繼續擴充，完全沒有訊號就要回頭檢查是關鍵字選錯還是標註做錯，而不是繼續加頁面。

如果你正在從更前面的階段開始，網域還沒買、主機還沒選，那順序應該再往前推一層，先把單一語言的地基打好，可以對照自架站新手的六個決策與網站架設新手指南。整體預算怎麼抓，自架、找接案與套版平台三種方案的價格比較那篇可以當基準，多語系的費用是加在那個基準之上的。

常見問題

只加一個英文版，會不會影響中文版原本的排名？

正確做的話不會。Google 的文件明確寫著，頁面的在地化版本「只有在主要內容仍未翻譯的情況下」才會被視為重複內容，真的翻譯過的英文版與中文版不構成互相競爭。會出問題的是兩種做法：一是只翻導覽列和頁尾、內文維持中文，Google 的多語系文件直接點名這會造成同一份內容配上不同語言模板重複出現；二是 canonical 設定錯誤，讓英文頁的 canonical 指向中文頁，等於自己宣告英文頁不該被索引。真正會傷到中文版排名的，通常不是英文版的存在，而是你把原本用來寫中文內容的時間分掉了一半。

用瀏覽器端的即時翻譯小工具算不算多語系？

對 SEO 來說完全不算。那類工具是在瀏覽器端即時翻譯，譯文不存在於伺服器回傳的 HTML 裡，也沒有各自獨立的網址，Google 無從索引，你也不可能對它下 hreflang。它唯一的價值是讓臨時來訪的外國讀者勉強讀懂內容，如果你的目的只有這個，那它很便宜也很合理；但不要把它當成「網站有英文版」，因為在搜尋結果裡它等於不存在。

hreflang 沒做，多語系網站會怎樣？

不會被懲罰，網站也不會壞掉，但你會失去「讓 Google 挑對版本」的能力。實際的症狀通常是：英文使用者搜到的是你的中文頁，或是兩個語言版本在同一組查詢裡互相取代、名次上上下下。Google 的文件也說了，它或許能自行找出你頁面的替代語言版本，但通常最好由你明確標示語言或地區專屬的頁面。所以 hreflang 是一個「做了會讓事情變準確」的東西，不是一個「不做會被扣分」的東西。優先順序上，它排在內容品質與正確翻譯之後，但排在絕大多數的技術微調之前。

WPML、Polylang、TranslatePress，一定要選哪一個？

先問三個問題再決定。第一，你用不用頁面編輯器（Elementor 這類）？用的話要注意 Polylang Pro 的 DeepL 整合目前不相容於 Elementor 與部分編輯器，這是官網自己標註的限制。第二，你的網站有沒有大量來自佈景主題與外掛的文字（按鈕、標籤、提示）？有的話 TranslatePress 的前端擷取方式處理起來最省事，WPML 則要買到 99 歐元的 CMS 方案才有字串翻譯。第三，你打算不打算換？打算的話優先選譯文以原生文章形式存放的方案（Polylang、WPML），因為那是最容易搬走的結構。預算真的很緊、內容也不多的話，Polylang 免費版加自己手動翻，是完全可行的起點。

繁體中文的 hreflang 到底要寫 zh-TW 還是 zh-Hant？

兩個 Google 都支援，差別在於你想標示的是什麼。zh-TW 標示的是「給台灣使用者的中文」，Google 的文件說明它會自動從國家推導出繁體文字系統。zh-Hant 標示的是「繁體中文，不限地區」，涵蓋台灣、香港、澳門與海外的繁體讀者。如果你的內容有明顯的台灣在地脈絡（台幣定價、台灣法規、本地服務），用 zh-TW 合理；如果內容是通用的繁體中文，用 zh-Hant 更貼切。真正重要的不是選哪一個，而是全站一致，而且每一頁的那組標註內容完全相同。BCP 47 對這件事的說法是：當同一個語言標籤被一致地用來代表同一種語言時，互通性最好。

資料來源

• Google Search Central — Tell Google about localized versions of your page（hreflang 三種實作方式、通用準則、支援的語言與地區碼、x-default、常見錯誤；頁面標示最後更新 2025-12-22）
• Google Search Central — Managing multi-regional and multilingual sites（四種網址結構的優缺點、語言判斷依據、避免自動重導、重複內容與 canonical 的分工、被視為通用網域的 ccTLD 清單；頁面標示最後更新 2025-12-10）
• Google Search Central — Spam policies for Google web search（現行「大規模濫用內容」條文；頁面標示最後更新 2026-05-15）
• Google Search Central Blog — What web creators should know about our March 2024 core update and new spam policies（說明新政策如何取代原本的「自動產生內容」政策）
• Internet Archive — Google 垃圾內容政策 2024-01-14 封存版本（已撤下的「Spammy automatically-generated content」一節與機器翻譯條文原文，僅供對照歷史沿革，非現行政策）
• Search Console 說明 — The International Targeting report is deprecated（國際定位報表停用，但 hreflang 仍持續支援）
• IETF RFC 5646（BCP 47）— Tags for Identifying Languages（語言標籤結構、zh-Hant 與 zh-Hans 與 zh-Hans-CN 範例、子標籤的節制原則）
• 外掛與服務定價（皆為 2026 年 8 月 2 日查核當日的官網公告，之後可能調整）：Polylang Pro、WPML、TranslatePress、Weglot
• 外掛啟用數與版本：WordPress.org — Polylang、WordPress.org — TranslatePress