Hreflang 完整實作指南,zh-TW 與 zh-Hant 的差異、x-default 用法、18 個常見錯誤
3 種 Hreflang 實作方法與 2 大中文代碼差異解析。Hreflang 是精準分發多語系流量的訊號,正確配置 zh-TW 與 zh-Hant 能避免 Canonical 衝突導致的索引災難。掌握 x-default 設定原則並排除 18 個常見錯誤,確保各國使用者看見正確網頁版本。
本文重點
- Hreflang 是建議訊號,不提升排名,但能精準替換搜尋結果網址以提高點擊率。
- 各語言網頁須設定自我指向 Canonical 標籤,若全指向主版將引發重複內容判定,導致多語系索引災難。
- zh-TW 限定台灣市場;若僅有單一繁中版本,應設定 zh-Hant 代碼,以涵蓋全球的繁體中文受眾。
- x-default 適用於語言選擇頁或全球預設版;實作時應擇單一方式統一設定,避免邏輯衝突。
Hreflang 是多語系 SEO 中最核心但也最容易出錯的技術環節,正確設定才能確保不同國家與語言的使用者在搜尋結果中看到對應的版本。這篇指南將帶你深入理解 Hreflang 的運作機制,釐清 hreflang zh-TW 與 hreflang zh-Hant 的差異、掌握 hreflang x-default 的應用場景,並徹底排除報表中的各類 hreflang 錯誤。
一、Hreflang 的核心概念與 Google 真正解讀的訊號
Hreflang 標籤的主要作用是告訴搜尋引擎網頁的特定語言與地區版本,讓搜尋引擎能在搜尋結果中提供最符合使用者語言偏好的網頁。這是執行多語系 SEO 時不可或缺的基石。
(一)Hreflang 是建議不是命令與 Google 優先顯示機制
根據 Google Localized Versions 官方文件,Hreflang 在搜尋引擎眼中是一個訊號(Signal)而非強制指令(Directive)。當使用者的語系設定、IP 位置或搜尋意圖與網頁宣告的 Hreflang 相符時,Google 會利用這個訊號在搜尋結果中「替換」顯示對應的 URL 版本。
這意味著 Hreflang 本身並不直接提升網頁的排名權重,它的功能在於精準分發流量。如果你的英文版網頁原本排在第一頁,當台灣使用者搜尋相同關鍵字時,Google 會依據 Hreflang 訊號,將搜尋結果上的英文版 URL 替換成繁體中文版的 URL,從而大幅提升點擊率與使用者體驗。
(二)Canonical 與 Hreflang 的關係以及多語站常見的衝突排序
Canonical 標籤用來指定「標準版本」以解決重複內容問題,而 Hreflang 則用來指明「不同語言的對等版本」。在多語系網站中,這兩者的設定如果產生衝突,會導致嚴重的索引災難。
實作上的鐵則:每個獨立語言版本的網頁,其 Canonical 標籤必須指向自己(Self-referencing canonical),再透過 Hreflang 互相連結。
許多開發者會誤將所有語言版本的 Canonical 都指向英文主版,這會向 Google 傳遞一個錯誤訊號:「這些外語版都是重複內容,請只索引英文版」。一旦網頁因為 Canonical 設定被判定為非標準網頁而不予索引,上面的 Hreflang 標籤也會連帶失效,導致多語系 SEO 策略全盤崩潰。關於頁面層級的 SEO 基礎設定,可參考 On-Page SEO 檢查清單。
二、語言碼與地區碼的正確組合與 zh-TW 及 zh-Hant 的差異
Hreflang 的代碼必須嚴格遵守國際標準格式:語言碼在前(小寫),地區碼在後(大寫),中間以連字號(-)分隔。不可隨意自創代碼,也不可單獨使用地區碼。
(一)ISO 639-1 語言碼與 ISO 3166-1 地區碼對照表
根據 W3C Language Tags 規範,設定 Hreflang 時必須採用 ISO 639 語言碼 來指定語言,並可選擇性地加上 ISO 3166 地區碼 來限定國家或地區。
- 只指定語言(合法):
hreflang="en"(適用於全球所有英語使用者,無論在美國、英國或澳洲) - 指定語言與地區(合法):
hreflang="en-GB"(僅針對英國的英語使用者) - 只指定地區(非法):
hreflang="GB"(這是無效的寫法,搜尋引擎無法辨識)
(二)zh-TW 與 zh-Hant 等繁簡中文代碼的實際差異與適用場景
在設定中文市場時,最常遇到 hreflang zh-TW 與 hreflang zh-Hant 的混淆。這兩者在定義上有著根本的差異:
- zh-TW:代表「針對台灣地區的中文使用者」。這裡的
TW是地區碼。如果你的網站有專為台灣市場設計的定價、在地化活動或物流資訊,應該使用這個代碼。 - zh-Hant:代表「繁體中文」,不限定地區。根據 IANA Language Subtag Registry,
Hant是文字(Script)代碼而非地區碼。如果你的網站只有一個繁體中文版本,且希望能同時服務台灣、香港、澳門及海外的繁中讀者,使用zh-Hant是最廣泛且正確的選擇。 - zh-HK:代表「針對香港地區的中文使用者」。
- zh-CN:代表「針對中國大陸的中文使用者」。
- zh-Hans:代表「簡體中文」,不限定地區。
若你的網站同時有台灣站與香港站,正確的配置應為分別設定
zh-TW與zh-HK;若只有一個繁中內容站,則設定zh-Hant即可。
(三)x-default 的真正用途與全球版之間的關係
hreflang="x-default" 是一個特殊的屬性值,用於指定當使用者的語言或地區與網站提供的任何 Hreflang 版本都不匹配時,系統預設應該顯示的網頁。
根據 Google Managing multi-regional sites,hreflang x-default 通常應用於以下兩種場景:
- 語言選擇頁面(Language Selector):當使用者造訪根網域時,顯示一個讓使用者自行選擇國家與語言的入口網頁。
- 全球預設版(Global Default):通常是英文版網頁。當一個來自法國的使用者造訪你的網站,但你的網站只有中文與英文版(沒有
fr),此時 x-default 標籤會引導 Google 在法國的搜尋結果中顯示英文版。
三、Hreflang 的三種實作方法與優劣比較
實作 Hreflang 有三種被搜尋引擎官方支援的方法:HTML 標籤、HTTP Header 與 XML Sitemap。在同一個網站中,強烈建議選擇其中一種並全站統一使用,避免多種方法混用造成邏輯衝突與維護災難。
(一)在 HTML head 中使用 link 標籤實作
這是最直觀也最常見的方式,直接將 <link> 標籤放入網頁原始碼的 <head> 區塊中。
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="zh-Hant" href="https://example.com/zh/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />
- 優點:實作簡單,適合語言版本較少(3-5 個以內)的小型網站,多數 CMS 系統也有外掛支援。
- 缺點:當語言版本增加時,HTML 原始碼會變得非常臃腫,拖慢網頁載入速度。此外,每次新增一種語言,就必須修改全站所有現有頁面的 HTML。
(二)使用 HTTP Header 實作非 HTML 資源
針對 PDF 檔案、Word 文件或圖片等無法修改 HTML 原始碼的資源,可以在伺服器端的 HTTP 回應標頭(HTTP Header)中加入 Hreflang 宣告。
Link: <https://example.com/en/document.pdf>; rel="alternate"; hreflang="en",
<https://example.com/zh/document.pdf>; rel="alternate"; hreflang="zh-Hant"
- 優點:能為非 HTML 資源建立多語系關聯。
- 缺點:設定門檻高,需要伺服器權限(如修改 .htaccess 或 Nginx 設定檔),且難以透過常規的網頁原始碼進行除錯。
(三)大型多語站首選的 Sitemap 實作方式
hreflang sitemap 是大型跨國網站的最佳實踐。將所有語言版本的對應關係寫入 XML Sitemap 中,能將設定從個別網頁中抽離出來,集中在伺服器端管理。
<url>
<loc>https://example.com/en/page/</loc>
<xhtml:link rel="alternate" hreflang="zh-Hant" href="https://example.com/zh/page/" />
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
</url>
- 優點:保持 HTML 原始碼乾淨,減少網頁體積。新增或移除語言版本時,只需更新 Sitemap 檔案,無需改動網頁程式碼。
- 缺點:XML 結構較為複雜,需要開發自動化腳本來生成。詳細的 Sitemap 提交與管理策略可參考 Sitemap 實作與 GSC 提交。
四、Hreflang 雙向確認與自我引用
任何 Hreflang 設定都必須符合「雙向確認(Return Tags)」與「自我引用(Self-referencing)」兩大核心原則,否則搜尋引擎會直接判定標籤無效並忽略該設定。
(一)為什麼每個語言版本必須互相聲明
hreflang 雙向確認是指:如果 A 網頁用 hreflang 指向了 B 網頁,那麼 B 網頁也必須用 hreflang 指回 A 網頁。
這個機制的目的是為了防止權重劫持與惡意宣告。如果沒有雙向確認機制,任何第三方網站都可以單方面在自己的網頁上宣告「我是 Apple 官方網站的中文版」,藉此混淆搜尋引擎。雙向確認確保了所有語言版本都在同一個管理者的控制之下,建立了可信的語言叢集。
(二)自我引用 self-referencing hreflang 的必要性
每個網頁不僅要宣告其他語言版本的 URL,還必須在 hreflang 列表中包含「自己」。
假設你有一個英文版網頁與一個中文版網頁,在英文版網頁的 <head> 中,除了指向中文版,也必須有一行指向自己的代碼:
<!-- 英文版網頁的 head 區塊 -->
<link rel="alternate" hreflang="en" href="https://example.com/en/" /> <!-- 自我引用 -->
<link rel="alternate" hreflang="zh-Hant" href="https://example.com/zh/" />
這項設定能讓搜尋引擎在抓取單一網頁時,就能取得完整的語言對應矩陣,確保演算法能正確解析該頁面在整個多語系架構中的位置。
五、18 個 Hreflang 常見錯誤與修正範例
實務上,超過 70% 的多語系網站存在各種 hreflang 錯誤。這些錯誤不僅會導致國際 SEO 策略失效,甚至可能引發索引異常。以下盤點最常發生的 18 個錯誤。
(一)地區碼用了錯誤的國家代碼
開發者常憑直覺填寫地區碼,導致使用了非 ISO 3166-1 標準的代碼。
- 錯誤範例:
en-UK(英國)、en-EU(歐洲)、zh-RC(中華民國) - 正確修正:英國的 ISO 代碼是
GB,應寫為en-GB。歐盟(EU)不是國家,不能作為地區碼。
(二)只用語言碼不指定地區碼造成的問題
如前文所述,Hreflang 可以只寫語言碼,但絕對不能只寫地區碼。
- 錯誤範例:
hreflang="TW"、hreflang="US" - 正確修正:必須加上語言碼,如
hreflang="zh-TW"或hreflang="en-US"。
(三)忘記加 x-default 與自我引用
漏掉 x-default 會讓 Google 在遇到未定義的地區流量時,不知道該派發哪個頁面,可能導致使用者看到錯誤語言的版本。漏掉自我引用則會破壞語言矩陣的完整性,這是新手最常犯的語法缺失。
(四)沒有雙向確認導致 GSC 報無回傳標籤
這是 hreflang GSC 國際定位報表中最常見的「無回傳標籤(no return tags)」錯誤。當英文版指向了日文版,但日文版的原始碼中卻漏掉了指回英文版的 hreflang 時,就會觸發此錯誤。確保全站輸出的 hreflang 矩陣完全一致是唯一的解法。
(五)hreflang 指向重定向頁面或 noindex 頁面
Hreflang 屬性中的 URL 必須是 HTTP 狀態碼為 200 OK,且允許被搜尋引擎索引的最終頁面。
- 指向 301 重定向頁面會消耗不必要的爬蟲預算(Crawl Budget)。
- 指向帶有
noindex標籤的頁面會產生邏輯衝突,導致 Hreflang 叢集失效。
(六)剩餘 13 個常見錯誤一次盤點
除了上述 5 個致命錯誤,以下 13 個細節也常導致設定失效:
- 分隔符號錯誤:使用了底線
_而非連字號-(如zh_TW是錯的)。 - 使用相對路徑:
href屬性必須使用絕對路徑(包含https://與完整網域)。 - 代碼順序顛倒:語言碼與地區碼順序寫反(如
TW-zh是錯的)。 - 指向不存在的頁面:URL 拼寫錯誤,導致指向 404 頁面。
- 放置位置錯誤:HTML 實作時,將
<link>標籤放在了<body>區塊中(必須嚴格放在<head>內)。 - 多種實作方式衝突:同時使用 HTML 與 Sitemap 實作,且兩邊的 URL 對應關係不一致。
- Canonical 跨語言指向:將不同語言版本的 Canonical 標籤全部指向同一個主要語言版本。
- URL 參數干擾:帶有追蹤參數(如 UTM)的 URL 被寫入 hreflang 中,導致與標準 URL 不符。
- 忽略行動版 URL:若網站仍使用獨立的行動版網址(m.example.com),未正確設定對應的行動版 hreflang。
- 分頁未設定:文章列表的第 2 頁(?page=2)指向了其他語言的第 1 頁,而非對應語言的第 2 頁。
- 語法未閉合:HTML 標籤中的引號漏打或未正確閉合。
- 動態切換未改 URL:使用者在網頁上點擊切換語言,畫面變了但 URL 沒變(不同語言必須有獨立的 URL)。
- 混淆 lang 屬性:誤以為設定了 HTML 標籤的
lang="zh-TW"就等同於設定了 Hreflang。兩者功能完全不同。
六、GSC 國際定位報告與 Screaming Frog 交叉驗證
實作完成後,必須透過第三方爬蟲工具與 Google Search Console 進行雙重驗證,確保語法正確且被搜尋引擎正確讀取。SEO 是一項需要反覆驗證的工作,基礎概念可參考 SEO 三大支柱。
(一)排查 GSC 國際定位報表的無回傳標籤錯誤
在 Google Search Console 中,若發現「無回傳標籤(No return tags)」錯誤,排查步驟如下:
- 點擊錯誤報表,檢視是哪一個來源 URL 報錯。
- 檢查該來源 URL 宣告的目標語言 URL 是否正確且存在。
- 直接開啟目標語言 URL 的原始碼,檢查是否真的漏寫了指回來源 URL 的 hreflang 標籤。
- 確認目標語言 URL 的 Canonical 標籤是否正確指向自己。
(二)快速看懂 Screaming Frog 的 Hreflang 報告
根據 Screaming Frog Hreflang 教學,使用 SEO Spider 爬取全站後,切換到頂部的「Hreflang」頁籤。這裡提供了極為詳細的診斷過濾器:
- Missing Return Links:直接列出缺乏雙向確認的頁面。
- Inconsistent Language Confirmation:找出宣告的語言碼與頁面實際 HTML lang 屬性不一致的網頁。
- Non-200 Hreflang URLs:揪出所有指向 301、404 或 500 狀態碼的無效 hreflang 連結。
(三)公開的 Hreflang 驗證工具清單
在網頁剛上線,還未被大型爬蟲抓取前,可以使用以下免費工具進行單頁抽查:
- Merkle Hreflang Tags Testing Tool:輸入單一 URL,能快速檢查該頁面的所有 Hreflang 標籤是否有效且具備雙向確認。
- Ahrefs SEO Toolbar:透過瀏覽器擴充功能,在瀏覽網頁時即時檢視當前頁面的 Hreflang 狀態。
- Hreflang Checker by Sitechecker:適合用來快速驗證語言碼與地區碼的 ISO 格式是否正確。
七、FAQ
(一)Q1: Hreflang 標籤會影響網頁的排名權重嗎?
不會直接影響排名權重。Hreflang 的作用是「流量分發」與「URL 替換」。它能確保搜尋引擎將正確的語言版本呈現給對應地區的使用者,從而降低跳出率並提升點擊率(CTR),這些良好的使用者行為訊號才會間接對 SEO 產生正面幫助。
(二)Q2: 可以同時混用 Sitemap 和 HTML head 實作 hreflang 嗎?
技術上可以,但實務上強烈不建議。混用多種實作方式極易導致人為疏失,例如 HTML 原始碼與 Sitemap 中的 URL 對應關係不一致,這會讓搜尋引擎收到混亂的訊號,最終導致所有 Hreflang 設定被忽略。請選擇一種方式並全站貫徹執行。
(三)Q3: 找不到對應的 ISO 國家代碼時該怎麼辦?
Hreflang 只能使用 ISO 3166-1 規範中的國家代碼。如果你想針對某個特定的地理區域(例如歐盟、拉丁美洲),由於它們不是單一國家,因此沒有對應的代碼。在這種情況下,你只能指定「語言碼」(如 es 代表西班牙語),並利用 x-default 來涵蓋其他未指定的地區流量。
張家偉 Albert Chang
行銷領域工作五年,其中四年幾乎每天都在想 SEO 的事。這裡寫我的筆記——不追流量、不堆關鍵字,只寫自己想讀的文章。
- JUL 20, 2026
SEO 健檢完整流程,用 GSC 和 Screaming Frog 免費做完網站體檢
三層健檢架構加 20 項檢查清單,從抓取索引、站內結構到內容成效,一套可重複執行的 SEO 健檢 SOP。全程只用 GSC、Screaming Frog 免費版與 PageSpeed Insights,不用付費工具。附本站實際健檢案例:孤兒站權重斷鏈、177 個薄弱標籤頁、AI 爬蟲誤封——三個問題都是照這套流程抓出來的。
- JUL 20, 2026
子網域還是子目錄,用我自己網站的三個月教訓給你答案
子網域與子目錄的 SEO 差異拆解加一份完整的第一手案例:本站選了子網域,三個月後確診孤兒站——零跨域連結、舊文章 404、權重從零累積。整理 Google 官方立場、業界遷移數據、決策框架,以及已經選了子網域的四步補救清單。想省三個月學費,看這篇就好。
- JUL 20, 2026
網站速度優化實戰,拿自己 LCP 11.5 秒的網站開刀
寫這篇之前先用 Lighthouse 測了本站:行動版效能 64 分、LCP 11.5 秒——靜態網站不等於快。用這份真實診斷示範網站速度優化的完整流程:從指標判讀、抓出三大元凶(中文字型多字重全載、肥大 CSS、第三方腳本),到 LCP、INP、CLS 各自的修法與中文網站專屬的字型策略。