多語系網站 SEO 怎麼做？hreflang 設定、架構選擇與常見錯誤完整解析

為什麼多語系網站需要特別處理 SEO？

許多企業在拓展海外市場時，第一步就是做多語系網站。但實務上，如果 SEO 沒有一起規劃，結果通常不是「流量變多」，而是「流量變亂」。很多人以為，網站做好翻譯、上線多語言版本，SEO 就自然會跟著到位。但現實往往相反——多語系網站如果沒有額外處理，反而可能比單語言網站的排名表現更差。

問題的根源在於：Google 無法判斷你的多個語言版本之間的關係與目標受眾，這會直接導致三個問題。

重複內容，讓 Google 不知道該排哪一頁

想像你有一個英文首頁和一個繁體中文首頁，兩者結構幾乎相同，只是語言不同。從 Google 的角度來看，這很可能被判定為「重複或高度相似的內容」——它不知道這是刻意的多語言設計，只看到兩個長得很像的頁面在互相競爭同一個位置。

結果往往是：Google 只選擇其中一個版本來排名，另一個版本幾乎消失在搜尋結果裡。

語言對上了，市場不一定對

就算 Google 正確辨識出語言，還有一層更細的問題：目標市場。繁體中文的使用者，可能來自台灣、香港、或海外華人社群，他們的搜尋習慣、慣用詞彙、甚至對品牌的信任感都有差異。如果沒有明確告訴 Google「這個版本是給台灣使用者用的」，它可能把你的台灣繁中版頁面推給香港用戶，或反過來——結果兩邊的轉換率都不理想。

外部連結的 SEO 權重，被稀釋掉了

好不容易有其他網站連結到你，這些連結帶來的權重（Link Equity）是 SEO 的重要燃料。但如果你的多語言版本各自獨立、沒有正確互相關聯，這些權重會分散到不同版本上，沒有辦法集中發揮效果。這就像把水倒進一個底部有好幾個洞的桶子，資源一直在流失。

→ 接下來，我們先看架構選擇，再進入 hreflang 設定。

多語系網站架構怎麼選？子目錄、子網域、ccTLD SEO 比較

在開始設定 hreflang 之前，有一個更根本的問題需要先決定：你的多語言內容要放在哪裡？

這個選擇不只影響技術實作的難易度，更直接決定了你在不同市場的 SEO 起跑點。目前主流的架構有三種，各有各的優勢與代價。

第一種：子目錄（Subdirectory）

example.com/zh-tw/
example.com/en/
example.com/ja/

子目錄是目前最多 SEO 專家推薦的方式，原因很直接：所有語言版本都住在同一個主網域下，共享同一份 Domain Authority。

你過去累積的網域信譽、外部連結，全部都能讓每個語言版本受益。

技術管理上也最集中——SSL 憑證、伺服器設定、分析工具，都只需要維護一套。對於大多數網站來說，子目錄是風險最低、效益最穩定的選擇。

唯一需要注意的是：URL 結構一旦確定就不要輕易更動，改動 URL 路徑對 SEO 的衝擊不亞於換域名。

第二種：子網域（Subdomain）

zh.example.com
en.example.com
ja.example.com

子網域在技術上彈性較高，你可以替不同語言版本部署不同的伺服器、框架，甚至交給不同的團隊獨立管理。

對於組織規模較大、各市場有獨立技術團隊的企業，這種架構在管理上會更清晰。

但 SEO 上有一個現實的代價：Google 傾向將子網域視為獨立的網站個體，主網域的 Authority 不會自動流入子網域。

這代表每個語言版本都需要從相對較低的基礎重新累積 SEO 權重，初期成長速度會比子目錄慢。

如果你的品牌在某個語言市場已經有足夠的內容量和外部連結資源可以投入，子網域的缺點是可以被彌補的；但如果資源有限，這個起步劣勢就值得認真考量。

第三種：獨立國家域名（ccTLD）

example.com.tw
example.co.jp
example.co.uk

ccTLD（Country Code Top-Level Domain）是地理定向信號最強的選擇。.com.tw 幾乎直接告訴 Google「這個網站是給台灣用戶的」，不需要額外設定。

用戶看到這類網址，也通常會有更高的本地信任感。

代價也最明顯：每一個國家域名都是一個完全獨立的網站，需要分別建立 SEO 基礎、累積連結與管理技術環境。

如果你有多個目標市場，等於要同時維護多個網站，成本會等比例放大。

ccTLD 適合在特定市場長期深耕、且品牌資源足夠的企業。對於剛起步的多語言網站，通常不是最優先選擇。

三種架構怎麼選？

沒有絕對正確的答案，但可以依照以下原則判斷：

• 資源有限、剛開始做多語言 → 選子目錄（成長最快）
• 各市場有獨立團隊 → 選子網域（管理彈性高）
• 深耕單一國家市場 → 選 ccTLD（在地信任最高）

選定之後最重要的一件事是：保持一致，不要中途更換。

架構切換會涉及大量 URL 變更與 301 轉址，處理不當很容易造成排名波動，甚至需要數個月恢復。 延伸閱讀： 網址選擇子網域or子目錄的全面比較

確認好架構之後，我們才能正式進入 hreflang 的設定。

hreflang 是什麼？Google 如何判讀？

hreflang 是 Google 用來判斷「語言版本」的標籤。

hreflang 的本質：一張語言版本對照表

hreflang 是一個放在頁面

裡的 HTML 屬性，由 Google 在 2011 年正式推出，專門用來處理多語言與多目標市場網站的 SEO 問題。

它的作用說穿了很簡單：告訴 Google，這個頁面有哪些其他語言版本，以及它們各自的網址是什麼。

每一行標籤就像是在說：「Hey Google，這個頁面的繁體中文版在這裡、英文版在這裡、日文版在這裡。」Google 讀到這段資訊之後，就能在搜尋結果中，把對的語言版本推給對的用戶。

Google 拿到 hreflang 之後，實際上怎麼運作？

當用戶在 Google 上搜尋時，Google 會同時參考幾個信號來決定推送哪個語言版本：用戶的瀏覽器語言設定、用戶所在的地理位置，以及你透過 hreflang 宣告的語言與目標市場對應關係。

三者疊加之後，Google 會選出最符合該用戶情境的頁面版本顯示在搜尋結果中。

舉個具體的例子：一位在台灣、瀏覽器設定為繁體中文的用戶搜尋某個關鍵字，如果你的網站正確設定了 hreflang="zh-TW"，Google 就會優先展示你的台灣繁中版頁面，而不是英文版或簡中版。沒有 hreflang 的情況下，Google 只能靠猜——而猜錯的機率比你想像的高。

三個常見的誤解，先釐清

誤解一：hreflang 只跟語言有關，跟目標市場無關

不對。hreflang 可以同時指定語言和目標市場。

誤解二：設定了 hreflang，Google 一定會照做

hreflang 對 Google 來說是「建議」，不是強制指令。如果你的頁面內容明明是英文，卻標注了 hreflang="zh-TW"，Google 會忽略這個標籤，以實際內容為準。

誤解三：hreflang 對所有搜尋引擎都有效

目前 Google 支援 hreflang，但 Bing 有自己的語言判讀機制，主要依賴頁面內容語言與 HTML 的 lang 屬性，並不讀取 hreflang 標籤。如果你的目標市場包含 Bing 流量較高的市場，需要另外處理。

hreflang 解決的，正是 canonical 解決不了的問題

你可能已經熟悉 canonical 標籤，它用來告訴 Google「這個頁面的權威版本是哪一個」，主要用來解決重複內容問題。

但 canonical 的邏輯是「選一個，忽略其他」，這對多語言網站完全行不通。你不可能讓 Google 只索引英文版、忽略繁中版——每個語言版本都需要被獨立索引、推給對應的用戶。

hreflang 的設計邏輯恰好相反：它告訴 Google「這些頁面都是有效的，只是給不同的人看的」，讓每個版本都能在對應的語言市場獨立排名，而不是互相壓制。

兩個標籤的角色不同，在多語系網站上通常會同時存在、各司其職。理解了 hreflang 的運作原理之後，接下來我們進入實作——語言代碼怎麼寫、有哪些格式規則需要注意。

三種實作方式：HTML、HTTP Header、Sitemap

知道了 hreflang 要寫什麼，下一步是決定要把它放在哪裡。

根據你的網站技術環境和規模，有三種合法的實作位置可以選擇。三種方式在 Google 眼中效力相同，選一種確實執行就夠了。

第一種：HTML

標籤（最常見）

每個語言版本的頁面，都必須列出所有語言版本的對應網址，包括自己指向自己。少了任何一個版本的自我宣告，Google 都可能視整組 hreflang 關係為無效。

適合的情境：

• 網站頁面數量不多（幾十頁到數百頁以內）
• CMS 架構（如 WordPress、Webflow）
• 想要最直接、最容易驗證的實作方式

主要缺點：頁面一多，維護量會快速增加。每新增一個語言版本，就要回去更新所有頁面的 hreflang 標籤組，容易出現遺漏。

第二種：HTTP Response Header

這種方式不修改 HTML，而是透過伺服器在回應標頭（Response Header）中直接傳遞 hreflang 資訊。

適合的情境：

• 頁面不是 HTML 格式，例如 PDF 或其他文件
• 希望將 SEO 設定集中在伺服器層
• 不希望影響前端開發流程

主要缺點：需要有伺服器管理權限，對不熟悉後端設定的團隊而言，初次設置門檻較高，也較難用一般 SEO 工具直接驗證。

第三種：XML Sitemap

在 sitemap 中集中宣告所有頁面的語言版本對應關係，是大型網站最常採用的方式。

適合的情境：

• 網站頁面數量龐大（數百頁以上）
• 頁面由系統動態產生
• 需要集中管理 hreflang 設定

主要缺點：sitemap 必須定期更新，新增或下架頁面時要同步維護，否則會造成 Google 判讀混亂。

三種方式怎麼選？

如果你不確定該用哪一種 hreflang 實作方式，可以參考以下判斷原則：

標籤，最直觀、也最容易驗證可用

• 頁面少、使用 CMS：建議使用 HTML
• 有 PDF 或非 HTML 資源：建議使用 HTTP Header，這類資源沒有
• 頁面數量多、由系統動態產生：建議使用 XML Sitemap，方便集中管理
• 需要由伺服器統一控制：建議使用 HTTP Header，由後端集中處理

選定方式之後，最重要的是確保全站一致。不要同一個頁面同時用 HTML 標籤和 sitemap 宣告不同的 hreflang 關係，兩者衝突時 Google 的行為難以預測，也會讓排查問題變得非常困難。

實作完成後，可以透過 Google Search Console 提交 sitemap，並使用「網址檢查」工具確認 Google 是否正確讀取 hreflang。這是驗證設定是否生效最直接的方法。

下一步，我們來看 hreflang 常見錯誤與排查方式。

x-default 怎麼用？什麼情境需要設？

在所有 hreflang 的設定值裡，x-default 是最容易被忽略、也最容易被誤用的一個。

它不代表任何特定語言，也不代表「預設語言是英文」——它的真正意思是：當用戶的語言或市場不符合你已定義的任何版本時，請把他們導向這個頁面。

x-default 通常放在整組 hreflang 標籤的最後一行，指向的網址則依據你的業務邏輯而定，可以是首頁、語言選擇頁，或是你認為最適合「語言未知用戶」的版本。

兩個最適合設定 x-default 的情境

情境一：你有一個語言選擇頁

有些網站在用戶第一次進入時，會先顯示語言或目標市場選擇頁，而不是直接跳轉到某個語言版本。這種情況下，x-default 應該指向該選擇頁，讓使用者自行決定。

情境二：你有一個全球通用的預設版本

更常見的情況是沒有語言選擇頁，而是直接以某個語言版本（通常是英文）作為全球預設。這時 x-default 就應該指向該預設版本。

x-default 不是必填，但不設可能有代價

很多網站沒有設定 x-default，Google 也不會報錯——它不是強制性的標籤。

但如果你的網站確實有來自「未涵蓋語言目標市場」的流量，不設 x-default 的結果是：Google 只能自行判斷該顯示哪個版本，而且結果並不穩定。

有時候會推英文版，有時候會推最近被抓取的頁面，無法控制。

設了 x-default，本質上就是告訴 Google：「當你判斷不出來時，請導到這裡。」

幾個常見誤解與錯誤用法

x-default 不等於「預設語言」

很多人誤以為設定 hreflang="x-default" 指向英文版，就代表英文是預設語言。這是錯的。

x-default 只處理「沒有對應語言版本」的用戶，英語用戶仍應透過 hreflang="en" 正確導向。

x-default 也需要符合對稱性

如果 x-default 指向某個頁面，那該頁面本身的 hreflang 標籤，也必須包含所有語言版本，整組關係才會成立。

不要指向會自動轉址的頁面

如果 x-default 指向的頁面會依據 IP 或瀏覽器語言自動 redirect，Google 可能無法正確抓取內容，導致 hreflang 設定失效。

建議指向一個穩定、可被索引的頁面。

接下來，我們來看設定完成後，如何驗證 hreflang 是否正確生效，以及最常見的錯誤與排查方法。

hreflang 常見錯誤與排查方法

hreflang 設定完成之後，很多人會發現一件令人沮喪的事：Google Search Console 開始出現一堆紅色警告，或者等了好幾週，搜尋結果的語言對應還是不對。

這不代表你做錯了什麼大方向，hreflang 本身的容錯空間很小，一個細節出錯就可能讓整組標籤失效。好消息是，常見的錯誤類型其實就那幾種，找到問題點之後修起來並不難。

錯誤一：對稱性不完整

這是 hreflang 最經典、也最常見的錯誤，沒有之一。

hreflang 要求所有語言版本必須互相確認——A 頁指向 B 頁，B 頁也必須反過來指向 A 頁。如果只有單向宣告，Google 會視整組關係為無效，直接忽略。

錯誤二：URL 格式不一致

hreflang 標籤裡的 URL，必須和頁面實際的 canonical URL 完全一致，包含每一個細節。

以下幾種情況都會造成 Google 無法正確比對：

最保險的做法是：先確認每個頁面的 canonical 標籤指向哪個 URL，hreflang 就照那個格式複製貼上，不要憑印象手動輸入。

錯誤三：語言代碼格式錯誤

hreflang 的語言代碼有固定規範，用了不合規的代碼，Google 不會報錯，只會默默忽略那個標籤。

錯誤四：hreflang 指向被重新導向或不存在的 URL

hreflang 標籤裡的每個 URL，必須是可以正常訪問、回傳 200 狀態碼的頁面。如果指向的 URL 出現以下情況，Google 都無法正確處理：

• 頁面回傳 404（已刪除或網址打錯）
• 頁面設有 301 或 302 重新導向
• 頁面被 robots.txt 封鎖爬取
• 頁面有 noindex 標籤

特別是重新導向這點，很多人以為 301 redirect 是安全的，Google 會跟著跳轉——但在 hreflang 的情境下，Google 要求標籤直接指向最終目標頁面，中間經過 redirect 的行為可能導致 hreflang 關係被忽略。

錯誤五：頁面內容語言與 hreflang 標籤不符

如果一個頁面標注了 hreflang="ja"，但頁面內容實際上是英文寫的，Google 會以頁面內容為準，忽略 hreflang 的宣告。

這個錯誤常見於以下情境：多語言版本剛上線、部分頁面翻譯還沒完成，卻已經先把 hreflang 標籤全部部署上去。

在翻譯完成之前，那些頁面的 hreflang 標籤不只沒有效果，還可能讓 Google 對整個語言版本的可信度產生疑慮。

建議的做法是：翻譯完成並上線之後，再加入對應的 hreflang 標籤，不要超前部署。

排查工具：怎麼找出問題在哪？

Google 網址檢查工具

在 Search Console 的搜尋列輸入任一頁面網址，點選「已抓取的頁面」，可以看到 Google 實際爬取到的 HTML 原始碼，確認 hreflang 標籤是否有被正確輸出，特別適合排查 JavaScript 渲染的網站是否有 hreflang 遺失的問題。

Ahrefs / Semrush 的網站健檢功能

兩者都有針對 hreflang 的自動化稽核，能標記常見錯誤並提供修正建議，適合定期做例行健康檢查，而不是只在出問題時才排查。

修正之後，多久會看到效果？

這是很多人想知道的問題。修正 hreflang 錯誤之後，Google 需要重新爬取並處理相關頁面，這個過程通常需要幾天到幾週不等，取決於你的網站爬取頻率和頁面規模。

比較穩健的做法是：修正完成後，在 Search Console 提交更新過的 sitemap，並對幾個重要頁面使用「要求建立索引」功能，主動通知 Google 來重新爬取，而不是被動等待。

hreflang 的錯誤不會讓網站排名一夕崩塌，但長期放著不處理，正確語言版本無法觸及對應用戶的問題會持續存在。

如果你也想先確認網站是否有其他收錄風險，可以延伸閱讀： Robots.txt 是什麼？哪些設定會害你不被收錄

多語系 SEO 還需要注意哪些細節？

hreflang 設定正確之後，多語系 SEO 的基礎建設算是完成了。但如果你的目標是在各個語言市場都取得穩定的排名，光靠 hreflang 是不夠的。

以下這些細節，是很多網站在多語言上線之後才發現自己忽略的地方——有些影響立即可見，有些則是長期累積的差距。

各語言版本都需要獨立的關鍵字研究

這是最常被輕忽的一點。很多團隊會先做好中文版關鍵字，再直接翻譯成其他語言，但這個做法往往無法反映實際搜尋行為。

不同語言的使用者，搜尋同一件事，不一定使用翻譯後的關鍵字。

👉 延伸閱讀： SEO 關鍵字怎麼選？完整策略解析

翻譯品質決定內容是否值得被排名

Google 評估內容品質的核心在於「是否對使用者有幫助」。機器翻譯即使語意正確，在自然度與語境上仍可能出現落差，進而提高跳出率，影響排名。

較務實的策略是：

• 核心頁面：人工翻譯 + 在地化潤稿
• 支援內容：AI 翻譯 + 人工校對
• 長尾內容：依資源決定是否翻譯

避免大量低品質內容上線，會拖累整個語言版本的 SEO 評分。

HTML lang 屬性不能忽略

hreflang 是給搜尋引擎看的，而