Hreflang 多語系 SEO 手冊：設定、常見錯誤與解法

看懂 Hreflang：要不要做、怎麼做、做錯會怎樣

想像一下：你花了一年把網站翻成英文、日文、簡體中文，準備進攻海外市場。三個月過去，英國的搜尋結果頁面上出現的，居然是你的日文版頁面。使用者點進去看不懂，兩秒就跳出；你在 Google Analytics 上看到的，是一條持續往下掉、怎麼救都救不回來的流量線。

這種錯版可能來自 hreflang、canonical、語言內容、重新導向或索引選擇，不能一開始就把責任全推給 hreflang。Hreflang 不是排名加分題，而是向 Google 說明各語言或地區版本關係的標記。

這篇我把關鍵判斷邏輯濃縮成可以直接套用的流程。先給你三句話的重點摘述：

• hreflang 解決的是「版本提示」，不是「排名」。它不會讓你排名變高，而是協助 Google 在搜尋結果中顯示較合適的語言或地區版本。
• 它是一個雙向承諾。頁面 A 標記指向 B，B 必須標記指回 A；缺少回連時，Google 可能忽略或無法正確解讀該對應關係，不代表必然忽略整組。
• 它不會在瀏覽器直接報錯。因此要在部署時驗證回應、回指與代碼，不要等流量變化才檢查。

如果網站只有一個語言、只服務一個在地市場，通常不需要 hreflang；重點會放在 Google 商家檔案等本地 SEO。只要有一種以上的語言版本，或同一語言要區分台灣、香港、新加坡等地區，就應評估 hreflang。這也是本地 SEO 與國際化 SEO 的分水嶺：前者把單一市場的在地能見度顧好，後者要處理多語言、多市場版本的分工與路由。

Hreflang 不是排名因素，那到底為什麼還要做

很多人對 hreflang 的第一個誤解是：以為加了它排名就會進步。老實說，這是把因果搞反了。

Google 的本地化版本文件說明：hreflang 用來提供同一內容的語言或地區版本關係，協助 Google 在搜尋結果中指向較合適的版本。它不是強制路由，也不會保證某一版在特定市場顯示或提高排名。

換個方式想。假設你開了一家連鎖咖啡館，台北店、東京店、首爾店都賣同一款招牌拿鐵。一位東京客人走進台北店，他不是不會喝，只是體驗很差：看不懂菜單、店員聽不懂他點什麼。Hreflang 做的事，就是在門口擺一個超醒目的告示牌，把這位東京客人引導到東京店去。

錯誤語言版本會傷害閱讀與轉換，但不能直接推論跳出率或停留時間會侵蝕網址可信度或造成排名下降。hreflang 的直接用途是協助 Google 在搜尋結果中顯示較合適的本地化版本。

正確的期待是：hreflang 向 Google 說明本地化版本關係，協助搜尋結果顯示較合適的網址。完整翻譯的主要內容通常不會被 Google 視為重複頁面；只有主要內容仍相同的地區版本，才更接近重複內容與 canonical 的議題，而且重複內容本身不是「處罰」。

沒有 hreflang 時，Google 仍可能自行發現與判定不同語言版本，因為它會用演算法偵測頁面語言；完整翻譯的頁面不會只因互為翻譯就被合併或降權。不過搜尋結果仍可能顯示不符合使用者語言或地區偏好的版本，這才是 hreflang 要處理的錯版問題。

hreflang 不是在說哪一版比較好，而是說明這些頁面是不同語言或地區的本地化版本。Google 仍會自行判定語言與索引，不存在公開的「各市場索引池」機制，也不能保證每次都顯示指定版本。

沒有 hreflang，多語系頁面仍可能進入索引。Google 明確說明不使用 hreflang 或 HTML lang 屬性偵測頁面語言，而是靠演算法判定；hreflang 只是明確提供本地化對應，不會把主導權完全交給站長。

Hreflang 更新後，要等 Google 重新爬取並處理相關頁面；官方沒有保證生效時間，也不能把搜尋流量變化直接歸因為「版本重新累積權重」。部署後應持續驗證標記與實際搜尋結果，不要期待立即變化。

語言代碼與地區代碼：一個連老手都會搞混的細節

hreflang 的值長得像 zh-TW、en-GB、ja-JP，但語言與地區代碼很容易混淆。這不是吹毛求疵；不支援或無效的值可能被 Google 忽略，但不宜一概說整組標記都會作廢。

一般先寫 ISO 639-1 語言碼，可再加 ISO 3166-1 Alpha-2 地區碼。Google 也支援部分 ISO 15924 書寫系統標記，例如 zh-Hant 與 zh-Hans；不一定只有兩段，更不能只填地區而沒有語言。

• 前半段是語言，採用 ISO 639-1 代碼，例如 zh（中文）、en（英文）、ja（日文）、ko（韓文）。
• 後半段是地區（可選），採用 ISO 3166-1 Alpha-2 代碼，例如 TW（台灣）、HK（香港）、GB（英國）、US（美國）。

這裡有幾個一踩就中招的地雷。第一，地區碼大小寫不影響判讀，但業界慣例是語言小寫、地區大寫（zh-TW 而非 ZH-tw），建議統一風格以免自己維護時眼花。第二，地區碼只能用國家，不能用「亞洲」這種區域名稱，Google 不認得自創代碼。第三，zh-TW 與 zh-Hant 是兩種不同的指定邏輯，前者鎖地區（台灣），後者鎖文字書寫系統（繁體中文，不限地區），兩者可以並存但意義不同，不要混用。

若不同網址分別服務台灣與香港，使用 zh-TW 與 zh-HK 較能表達地區差異；不要讓兩個不同版本都只宣告同一個 zh-Hant，卻期待 Google 因此分辨地區。只有一份通用繁中內容時，可依受眾使用 zh-Hant，不必為標記而硬拆頁面。

華語市場常用的代碼組合整理如下，設定時直接對照就不會寫錯：

zh-TW 指中文的台灣地區版本；Google 也可由地區推導書寫系統。zh-Hant 明確表示繁體書寫系統、不限定地區。對應應反映真實頁面用途，同一網址也可代表多個適用市場，不需要為每個值建立重複頁面。

三種實作方法，哪一種適合你的網站

Google 接受三種把 hreflang 告訴它的方式（見 Google Search Central 說明）。三種都有效，差別在於維護成本與適用場景。下面這張表幫你快速判斷：

三種方法對 Google 等效，可選最便於維護的一種。HTML 也能由 CMS 自動產生，並非只能手貼；Sitemap 適合集中管理，HTTP 標頭也適用 PDF。可以同時使用多種方法，但沒有額外搜尋好處，且必須避免相互矛盾。

三種方法的長相，我直接給你看實際寫法，這樣你才知道自己手上拿到的是哪一種。以一個同時有繁中、英文、日文三個版本的頁面為例：

方法一：HTML link 標籤。放在每一頁的 <head> 裡，三個版本都要寫完整：

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

每一頁的 head 裡，要列出包含自己在內的全部語言或地區版本。繁中頁面要列自己（zh-TW）、英文與日文；英文頁面也要列同樣三條。若網站選擇使用 x-default，各版本也應維持一致。自我參照與完整對應都不能漏掉。

方法二：HTTP 標頭。當你回傳 PDF 等非 HTML 文件的多語版本時，HTML head 用不上，就把 Link 資訊放到伺服器回應標頭：

Link: <https://example.com/tw/brochure.pdf>; rel="alternate"; hreflang="zh-TW",
<https://example.com/en/brochure.pdf>; rel="alternate"; hreflang="en"

這個方法很少被一般站長碰到，但在提供多語系 PDF 型錄、白皮書下載的 B2B 網站很常見。它的缺點是設定藏在伺服器層，前端開發者通常看不到，除錯要靠瀏覽器開發者工具的 Network 面板檢視回應標頭。

方法三：XML Sitemap。把所有對應關係集中寫進 sitemap，頁面本身的 HTML 完全不動：

<url>
  <loc>https://example.com/tw/</loc>
  <xhtml:link rel="alternate" hreflang="zh-TW" href="https://example.com/tw/" />
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/" />
  <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
</url>

XML 範例只示意單一 url 區塊。實際 sitemap 須有完整 urlset 根元素，宣告 xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" 與 xmlns:xhtml="http://www.w3.org/1999/xhtml"；每個版本各有 loc，並列出相同的本地化對應。頁面多時宜自動產生，另需遵守 sitemap 的主機與提交規則。

WordPress 可由多語系外掛或客製程式產生 hreflang，一般 SEO 外掛不一定知道哪些頁面互為翻譯。設定後仍需驗證完整網址、自我參照與雙向回指，並與WordPress SEO 指南中的索引及 canonical 設定一起檢查。

雙向回連是必要條件，x-default 是建議的預設值

這一節有兩個容易混淆的規則：雙向回連是必要條件，x-default 則是可依網站架構採用的建議值。

第一條：雙向回連（bidirectional return tags）。假設你有英文版 /en/ 與日文版 /ja/。英文版指向日文版時，日文版也必須指回英文版。缺少回連時，Google 可能忽略或無法正確解讀受影響的對應關係，不宜寫成必然整組作廢。

語系越多，人工更新越容易漏掉對應。建議由一份頁面關係資料產生標記；Google 可處理仍有雙向回指的部分，不是少一個版本就必然整組作廢。

第二條：x-default。這是一個特殊的 hreflang 值，用來標示未匹配其他語言或地區時的通用版本，例如語言選擇頁。它提供搜尋結果版本提示，不會替網站執行瀏覽器重新導向；重新導向仍由伺服器或前端邏輯控制。

x-default 是 Google 建議用於未匹配語言或語言選擇頁的值，不是必填。沒有它不會讓其他 hreflang 失效；若網站有通用首頁或語言選擇器，再加上合適的 x-default 即可。

怎麼決定 x-default 指向哪裡？若網站有語言選擇頁，通常由它擔任通用版本；沒有選擇頁時，也可評估內容最通用的版本。單一語言網站沒有本地化版本對應問題，通常不需要 x-default。

Hreflang 與 canonical 如何配合

講到這裡，要把另一個會跟 hreflang 打架的標記請出場：canonical。

Canonical 用來提示重複或近似內容的代表網址；hreflang 說明本地化版本關係，兩者可以配合，不是方向必然相反。Google 仍會綜合訊號選擇 canonical。

常見錯誤是：不同語系頁面各放了 hreflang，canonical 卻全部指向英文版。這會向 Google 傳遞互相衝突的訊號，可能讓其他語言網址不被選為代表網址，也削弱 hreflang 的作用；實際結果仍由 Google 判定，不宜寫成必然全部合併或流量一定下跌。

完整翻譯、內容獨立的語言版本，通常各自指定合適的同語言 canonical。若同一語言有近似地區版本，Google 建議選定偏好的 canonical，並搭配 hreflang 說明地區關係；不能說相同內容就一定不需要 hreflang。

先判斷主要內容是否完整翻譯、是否只是同語言地區差異，再設計 canonical 與 hreflang。使用 hreflang 時，canonical 應優先指向同語言頁；沒有同語言 canonical 時，官方才容許最適合的替代語言。

把錯誤與正確的寫法擺在一起看最清楚。假設有繁中與英文兩個版本：

錯誤寫法（兩者打架）：

/tw/ 頁面 → canonical 指向 /en/
/tw/ 頁面 → hreflang 指向 /en/ 與自己 /tw/
/en/ 頁面 → canonical 指向自己 /en/

這組設定的矛盾在於：繁中頁面一邊用 hreflang 說明本地化關係，一邊又用 canonical 提示英文版是代表網址。Google 可能因此不採用繁中網址作為 canonical，也讓該版本的 hreflang 對應失去作用；實際選擇仍由 Google 綜合其他訊號判定。

正確寫法（各自獨立）：

/tw/ 頁面 → canonical 指向自己 /tw/
/tw/ 頁面 → hreflang 指向 /en/ 與自己 /tw/
/en/ 頁面 → canonical 指向自己 /en/
/en/ 頁面 → hreflang 指向 /tw/ 與自己 /en/

上例適用於內容各自完整翻譯的繁中與英文頁。Self-canonical 可表達偏好，但不保證 Google 一定獨立收錄或排名；仍須確認正文、索引資格與整體訊號一致。

五個會讓 hreflang 靜默失效的常見錯誤

把上面學到的東西整理成一份除錯清單。以下依照常見的實際情境，列出最容易讓 hreflang 默默失效的五個錯誤，以及對應的修法。

除了標記，也要檢查目標 URL 的回應、抓取與索引資格。404、意外轉址或 noindex 可能使該版本無法正常參與搜尋；受影響的對應不等於整組必然失效。把網址異動納入部署檢查，比只等流量變化容易定位。

多語系網站架構怎麼選，才不會被 hreflang 拖垮

hreflang 的複雜度，其實跟你選的網站架構高度綁定。架構選錯，hreflang 的維護成本會被放大好幾倍。常見的三種多語系架構各有取捨，這裡從「對 hreflang 友善程度」的角度快速比較，架構本身的深入分析可以參考我們另一篇 多語系網站架構設計。

子網域如 tw.example.com 與 jp.example.com，便於技術或權限分工；hreflang 允許跨網域對應。實際維護難度取決於 CMS 與部署方式，不能把子網域與子目錄直接換算成固定排名權重。

子目錄如 /tw/ 與 /jp/，常便於共用 CMS、導覽和版本關係資料。這是維護上的優點，不代表主網域有一份固定權重自動平均分給各語系。

例如台、港、日旅遊網站若共用 CMS，可從同一資料表產生各版本對應，減少手動更新。子網域也可做到相同自動化；應按團隊、權限和部署需求選擇，沒有哪種架構必然維護成本最低。

國家級頂級網域（ccTLD）如 .tw、.jp，可提供明確國家訊號，但通常需要管理更多網域與部署。不能保證訪客因網域就更信任，也沒有各站固定從零分重新累積的官方權重制度。

新增語系、改版、換網域：hreflang 的維護生命週期

hreflang 不是一次性的設定專案，它有完整生命週期。最容易出事的不是上線那一刻，而是後續每一次結構變動。我把三個高風險場景拆開講。

新增語言版本：將新頁加入對應表並更新既有版本，確認雙向回指，尤其與原有主要語言頁的關係。同時提供可爬導覽或語言切換連結；缺少 hreflang 回指與沒有一般內鏈的孤兒頁，是不同問題。

移除語言版本：清除仍指向已下架頁面的 hreflang，按內容是否有合理替代決定轉址或 404／410。留下失效目標會影響對應判讀，但不能稱為可量測的整組信任扣分。

改網址或換網域：部署前準備新 URL、canonical、hreflang 與 sitemap，並同步設定合適的301 轉址。驗收最終網址和回指，避免長期仍指向舊址；不存在可量化的「晚一週就整組扣信任」規則。

網址與語言版本異動時，應同步更新關係資料並執行驗證。這能降低設定不一致，但無法用八十分、一百分或維護頻率預測長期排名。

用網址檢查與爬取工具驗證 hreflang

Google Search Console 的「國際指定目標」報告已停用，現行 GSC 沒有專門列出 hreflang 錯誤的報表。驗證要結合網址檢查、原始 HTML／HTTP 標頭、sitemap 與可檢查雙向回指的爬取工具。

網址檢查工具可協助確認索引狀態、Google 選擇的 canonical 與測試時取得的 HTML；實際能否直接看到 hreflang 取決於呈現內容，因此仍應自行檢查原始碼、回應標頭或 sitemap。

檢索統計與伺服器日誌可補充觀察某語系目錄是否被爬取，但低爬取頻率不能直接歸因於 hreflang，還可能與內部連結、sitemap、內容更新、回應速度或索引需求有關。

檢查頻率依內容更新與部署風險決定，重大語系或網址變更後應立即驗證。每月完整檢查可作某些團隊的工作安排，不是 Google 的要求或普遍最佳頻率。

把這些檢查點串成一條診斷流程，當你懷疑某個語系流量異常時，可以照著走一遍：

1. 先確認該語系的網址本身回應正常（回傳 200，沒有被轉址到別處）。
2. 用 GSC 網址檢查看 Google 抓到的 HTML 裡，hreflang 與 canonical 各是什麼。
3. 用爬取工具或程式比對每頁自我參照、完整 URL、語言代碼與雙向回指。
4. 檢查該頁面的所有 hreflang 目標，逐一確認它們都存在且雙向回連完整。
5. 標記正常時，再核對 Google 選擇的 canonical、主要內容語言、意圖與其他索引原因；完整翻譯不會只因意思相同就被當成重複內容。

這個流程的重點是由外往內排查：先排除回應與標記問題，再檢查 canonical、內部連結與內容。定位時間取決於頁面量與實作方法，不保證十分鐘內完成。

JavaScript 渲染的 hreflang：Google 真的看得見嗎

前端框架可能由 JavaScript 在瀏覽器端把 hreflang 插入 <head>。Google 的 JavaScript SEO 文件說明，搜尋處理包含抓取、渲染與索引階段；渲染需等待佇列與資源，也可能受程式錯誤影響。因此若只依賴客戶端注入，應檢查 Google 可取得的渲染結果，不能只看自己瀏覽器的 Elements 面板。

Google 搜尋會分階段爬取與渲染 JavaScript，但沒有提供每頁固定的幾小時或幾天時程。若 hreflang 只在執行 JavaScript 後出現，驗證與除錯會更困難，也會受渲染錯誤影響。

對大量頁面，JavaScript 錯誤與渲染成本會增加維護風險。不要假設 Google「遲早一定會看到」，也不要把所有問題都歸因於檢索預算；最穩定的做法仍是把標記放在初始 HTML、HTTP 標頭或 sitemap。

建議優先在初始 HTML 的 <head> 輸出 hreflang，或按網站架構使用官方支援的 HTTP 標頭、XML Sitemap 方法；避免把客戶端 JavaScript 注入當成唯一來源。若採 HTML 方法，可用 curl 或「檢視原始碼」確認初始回應是否有標記；若採標頭或 Sitemap，則應查對相應輸出，不能只因 HTML 原始碼沒有標記就判定遺漏。若必須由 JavaScript 輸出，再用網址檢查工具的渲染 HTML 與實際回應交叉驗證。

把標記放在初始 HTML、HTTP 標頭或 sitemap，可減少對前端執行的依賴。但只看某日流量不能斷定當天 Google 因渲染預算跳過 hreflang；仍應用實際抓取結果與回應資料診斷。

行動優先索引下，行動版也要保留 hreflang

Google 已全面採用行動優先索引，意思是主要使用行動版內容進行爬取與索引，不是額外的行動版排名加分（見 2023 年 10 月的 Mobile-first indexing is here 官方公告）。若採獨立桌機與行動版網址，桌機 hreflang 指向桌機版本，行動版 hreflang 指向行動版版本；canonical 與 alternate 再按行動版網址規範配置。響應式共用網址則維護同一組對應。

官方文件沒有把 SIM 國家碼或 GPS 列為 hreflang 的判定依據，也不應假設搜尋能取得精確定位。這一節真正要檢查的是行動版 HTML 是否仍輸出完整標記，並用行動版網址檢查測試渲染結果。

Google 表示 AI Overviews 與 AI Mode 不需要特殊技術優化；一般搜尋資格與既有 SEO 基本功仍適用。Hreflang 的官方用途仍是說明本地化頁面關係，沒有證據顯示它會提高 AI 引用或語音答案機率。可延伸看 AI 搜尋 與 AEO，但不要把 hreflang 包裝成特殊入場券。

六步行動方案：從今天開始把多語系路由顧好

看完原理，接下來是落地。我把 hreflang 從零到穩的流程拆成六個可執行的步驟，你可以在一兩週內分批完成。

1. 盤點所有語系版本與對應網址。列一張表，每一個頁面、每一種語言版本、它的完整 URL，先把現況看清楚，不要憑記憶。這一步很多人嫌麻煩跳過，結果後面每一步都建立在錯誤的前提上。
2. 依實際受眾決定代碼。區分語言、書寫系統與地區；不同內容可以有不同適用範圍，不必為了全站一致而標錯受眾。
3. 選擇可維護的輸出方式。HTML、HTTP Link 標頭與 XML sitemap 等效；可依內容類型使用不同方式，避免重複且矛盾的資料。
4. 補齊雙向回連，視需要加入 x-default。逐頁檢查每組對應關係都是雙向的；有語言選擇頁或通用預設頁時，再加入 x-default。
5. 核對 canonical 與索引資格。完整翻譯頁通常選同語言 canonical；同語言近似地區頁依代表網址策略配合 hreflang，並確認目標正常回應與可索引。
6. 上線後重新驗證。提交更新後的 sitemap，使用網址檢查、原始碼／回應標頭與爬取工具確認標記；GSC 已沒有國際指定目標報告。

多語系 SEO 不是一個做完就結束的專案，它是一套需要持續維護的路由系統。每新增一個語系、每改動一次網址結構，hreflang 都要跟著更新。把它想成網站的地基：平日看不出存在，但一旦鬆動，整棟多語系流量大樓都會跟著晃。

hreflang 是本地化版本的提示，不是站長與 Google 的顯示保證。維護時核對支援代碼、完整 URL、自我參照、雙向回指及 canonical，並在每次版本變更後重新驗證。

如果你正在規劃進軍多個市場，卻不確定從架構到標記該怎麼一次到位，這正是 Whoops 擅長協助的範疇。卡關時隨時來談，我們陪你把這套多語系地基一次打好。