Hreflang 多語系 SEO 手冊：設定、常見錯誤與解法
hreflang 不是排名開關，而是多語系網站的版本對應契約。本指南從語言碼格式、三種網址架構、三種實作方式到五大常見錯誤與 WordPress 實務，帶你正確設定多語系 SEO，把每個版本送到對的訪客眼前。
作者：褚崇名（Sliven）
本頁目錄
- 看懂 Hreflang：要不要做、怎麼做、做錯會怎樣
- Hreflang 不是排名因素，那到底為什麼還要做
- 語言代碼與地區代碼：一個連老手都會搞混的細節
- 三種實作方法，哪一種適合你的網站
- 雙向回連是必要條件，x-default 是建議的預設值
- Hreflang 與 Canonical 的致命搭配
- 五個會讓 hreflang 靜默失效的常見錯誤
- 多語系網站架構怎麼選，才不會被 hreflang 拖垮
- 新增語系、改版、換網域：hreflang 的維護生命週期
- 用網址檢查與爬取工具驗證 hreflang
- JavaScript 渲染的 hreflang：Google 真的看得見嗎
- 行動優先索引下，行動版也要保留 hreflang
- 六步行動方案：從今天開始把多語系路由顧好
看懂 Hreflang：要不要做、怎麼做、做錯會怎樣
想像一下：你花了一年把網站翻成英文、日文、簡體中文，準備進攻海外市場。三個月過去，英國的搜尋結果頁面上出現的，居然是你的日文版頁面。使用者點進去看不懂，兩秒就跳出；你在 Google Analytics 上看到的，是一條持續往下掉、怎麼救都救不回來的流量線。
這種錯版可能來自 hreflang、canonical、語言內容、重新導向或索引選擇，不能一開始就把責任全推給 hreflang。Hreflang 不是排名加分題，而是向 Google 說明各語言或地區版本關係的標記。
這篇我把關鍵判斷邏輯濃縮成可以直接套用的流程。先給你三句話的重點摘述：
- hreflang 解決的是「版本提示」，不是「排名」。它不會讓你排名變高，而是協助 Google 在搜尋結果中顯示較合適的語言或地區版本。
- 它是一個雙向承諾。頁面 A 標記指向 B，B 必須標記指回 A；缺少回連時，Google 可能忽略或無法正確解讀該對應關係，不代表必然忽略整組。
- 它不會在瀏覽器直接報錯。因此要在部署時驗證回應、回指與代碼，不要等流量變化才檢查。
如果網站只有一個語言、只服務一個在地市場，通常不需要 hreflang；重點會放在 Google 商家檔案等本地 SEO。只要有一種以上的語言版本，或同一語言要區分台灣、香港、新加坡等地區，就應評估 hreflang。這也是本地 SEO 與國際化 SEO 的分水嶺：前者把單一市場的在地能見度顧好，後者要處理多語言、多市場版本的分工與路由。
Hreflang 不是排名因素，那到底為什麼還要做
很多人對 hreflang 的第一個誤解是：以為加了它排名就會進步。老實說，這是把因果搞反了。
Google 在官方的本地化版本文件（2026 年 6 月）裡講得很白：hreflang 的目的，是讓搜尋引擎根據使用者的語言和所在地區，回傳最合適的頁面版本。它管的是「哪一版要出現在哪一個市場」，不是「這一版要排第幾名」。
換個方式想。假設你開了一家連鎖咖啡館，台北店、東京店、首爾店都賣同一款招牌拿鐵。一位東京客人走進台北店，他不是不會喝，只是體驗很差：看不懂菜單、店員聽不懂他點什麼。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 代碼，例如
zh（中文）、en（英文）、ja（日文）、ko（韓文）。 - 後半段是地區（可選），採用 ISO 3166-1 Alpha-2 代碼，例如
TW（台灣）、HK（香港）、GB（英國）、US（美國）。
這裡有幾個一踩就中招的地雷。第一，地區碼大小寫不影響判讀，但業界慣例是語言小寫、地區大寫（zh-TW 而非 ZH-tw），建議統一風格以免自己維護時眼花。第二，地區碼只能用國家，不能用「亞洲」這種區域名稱，Google 不認得自創代碼。第三，zh-TW 與 zh-Hant 是兩種不同的指定邏輯，前者鎖地區（台灣），後者鎖文字書寫系統（繁體中文，不限地區），兩者可以並存但意義不同，不要混用。
台灣繁中跟香港繁中都寫 zh-Hant，技術上可以，但會失去地區層級的指定。兩地用詞、幣別與聯絡方式可能不同；內容若確實做了在地化，可用 zh-TW 與 zh-HK 分開標記；若只有繁中通用版，zh-Hant 較符合內容範圍。這不是強迫拆分頁面的規則，仍要依實際內容差異判斷。
華語市場常用的代碼組合整理如下，設定時直接對照就不會寫錯：
| 代碼 | 意義 | 典型適用場景 |
|---|---|---|
zh-TW |
中文，台灣地區 | 針對台灣市場做在地化的繁中內容 |
zh-HK |
中文，香港地區 | 港式用語、港幣計價的繁中內容 |
zh-Hant |
繁體中文，不限地區 | 不分台港的通用繁中版本 |
zh-Hans |
簡體中文，不限地區 | 針對中國大陸、新加坡等簡中市場 |
zh-CN |
中文，中國大陸 | 專做中國大陸市場的簡中版本 |
有個常見的迷思要打破：zh-TW 並不等於「繁體中文」。它嚴格意思是「中文這個語言，在台灣這個地區的版本」。如果你的繁中內容同時要服務台灣與香港、又沒有做地區差異，用 zh-Hant 反而比同時放 zh-TW 與 zh-HK 更誠實，也省下維護兩份幾乎相同頁面的力氣。
三種實作方法，哪一種適合你的網站
Google 接受三種把 hreflang 告訴它的方式（見 Google Search Central 說明）。三種都有效，差別在於維護成本與適用場景。下面這張表幫你快速判斷：
| 方法 | 做法 | 最適合 | 主要風險 |
|---|---|---|---|
| HTML link 標籤 | 在每個頁面的 <head> 放 <link rel="alternate" hreflang="..."> |
頁面數量少、手改可控的小站 | 每加一個語系就得改全部頁面，擴充性差 |
| HTTP 標頭 | 在伺服器回應的 HTTP header 帶上 Link 欄位 | 非 HTML 文件，例如 PDF 的多語版本 | 設定在伺服器層，除錯不直覺 |
| XML Sitemap | 在 XML sitemap 裡用 xhtml:link 宣告每組對應關係 |
頁面量大、語系多、版面由 CMS 動態生成 | sitemap 體積膨脹，需要自動化產生流程 |
換句話說，選哪一種取決於兩件事：你的網站多大、你的工程資源多深。十幾頁的公司官網，HTML link 標籤手貼一遍就收工，簡單直接。但如果是動輒幾千頁的電商站，每加一個語系就要回頭改幾千個頁面的 head，這種事交給 sitemap 自動產生才合理。
三種方法的長相，我直接給你看實際寫法，這樣你才知道自己手上拿到的是哪一種。以一個同時有繁中、英文、日文三個版本的頁面為例：
方法一：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>
注意每一組 <url> 區塊都要為每一個語系版本各寫一次，也就是三個版本會產生三組結構幾乎相同的區塊。這就是為什麼 sitemap 方法一定要靠程式自動產生，手寫在幾百頁的站點上完全不現實。好處是它跟頁面內容完全解耦，將來改 hreflang 對應不用動到任何一頁 HTML，只改 sitemap 重新產生就好。
WordPress 的 hreflang 通常由多語系外掛或客製程式產生，不能假設一般 SEO 外掛會自動處理。依 W3Techs 至 2026 年 6 月的公開統計，WordPress 在全球內容管理系統的佔有率超過四成。可參考 WordPress SEO 指南了解整體設定方向，並實際驗收外掛輸出的完整 URL、自我參照與雙向回指。
雙向回連是必要條件，x-default 是建議的預設值
這一節有兩個容易混淆的規則：雙向回連是必要條件，x-default 則是可依網站架構採用的建議值。
第一條：雙向回連（bidirectional return tags）。假設你有英文版 /en/ 與日文版 /ja/。英文版指向日文版時，日文版也必須指回英文版。缺少回連時，Google 可能忽略或無法正確解讀受影響的對應關係，不宜寫成必然整組作廢。
把這件事放大到六個語系、每頁要互相指六個方向，你就會理解為什麼手改 HTML link 標籤在中大型網站是惡夢。一個語系下架、一個網址改動，所有相關頁面都要同步更新，漏一個就破壞一整條鏈。
第二條：x-default。這是一個特殊的 hreflang 值，用來標示未匹配其他語言或地區時的通用版本，例如語言選擇頁。它提供搜尋結果版本提示，不會替網站執行瀏覽器重新導向；重新導向仍由伺服器或前端邏輯控制。
x-default 是 Google 建議用於未匹配語言或語言選擇頁的值，不是必填。沒有它不會讓其他 hreflang 失效；若網站有通用首頁或語言選擇器，再加上合適的 x-default 即可。
怎麼決定 x-default 指向哪裡？若網站有語言選擇頁，通常由它擔任通用版本；沒有選擇頁時，也可評估內容最通用的版本。單一語言網站沒有本地化版本對應問題，通常不需要 x-default。
Hreflang 與 Canonical 的致命搭配
講到這裡，要把另一個會跟 hreflang 打架的標記請出場：canonical。
Canonical 的作用是告訴 Google「這幾個長得很像的頁面，請以這一個為準」。它的設計目的是解決重複內容。問題來了：hreflang 是在說「這幾個頁面是不同語言版本，請分別呈現」，canonical 是在說「這幾個頁面是重複的，請合併」。一個叫 Google 分開看，一個叫 Google 合起來看，方向剛好相反。
常見錯誤是：不同語系頁面各放了 hreflang，canonical 卻全部指向英文版。這會向 Google 傳遞互相衝突的訊號，可能讓其他語言網址不被選為代表網址，也削弱 hreflang 的作用；實際結果仍由 Google 判定，不宜寫成必然全部合併或流量一定下跌。
正確的做法是：每一個語系頁面的 canonical 應該指向自己（self-referential canonical），表示「我是一個獨立、有效的版本」，再讓 hreflang 去處理跨語系的對應關係。例外狀況是：如果兩個頁面真的是百分之百相同內容（例如只是網址參數不同），這時才用 canonical 合併，而且這種情況根本不需要 hreflang，因為沒有語言差異可言。
記住一個判斷原則：hreflang 與 canonical 不要打架。如果兩個頁面有實質內容差異（語言就是實質差異），canonical 各自指向自己，交給 hreflang 做路由；如果沒有差異，用 canonical 合併就好，別再放 hreflang 製造矛盾訊號。
把錯誤與正確的寫法擺在一起看最清楚。假設有繁中與英文兩個版本：
錯誤寫法（兩者打架）：
/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/
每一頁都堂堂正正地宣稱「我就是標準版本」，再透過 hreflang 把彼此的對應關係講清楚。這樣 Google 才會把兩個版本當作各自獨立、值得分別收錄與排名的頁面。
五個會讓 hreflang 靜默失效的常見錯誤
把上面學到的東西整理成一份除錯清單。以下依照常見的實際情境，列出最容易讓 hreflang 默默失效的五個錯誤，以及對應的修法。
| 錯誤 | 發生情境 | 正確修法 |
|---|---|---|
| 缺少回連標記 | A 指向 B，B 沒有指回 A | 補齊所有雙向對應，或改用 sitemap 集中管理 |
| 用了不存在的語言代碼 | 寫成 zh-Taiwan 或自創 asian |
只用 ISO 639-1 語言碼配 ISO 3166-1 地區碼 |
| 指向被 canonical 合併的頁面 | hreflang 指向一個 canonical 指向他處的網址 | 讓每個語系頁面 self-canonical，移除矛盾 |
| 把 x-default 當成重新導向規則 | 期待它在瀏覽器自動切換語言或地區 | 把 x-default 當搜尋版本提示；重新導向另行實作 |
| 網址本身回不來 | hreflang 指向的網址回傳 404 或被轉址到別處 | 定期檢查所有目標網址可正常回應 200 |
第五項特別值得點出來。很多人以為 hreflang 寫對就沒事，卻忘了它指向的是一個真實的網址。如果那個網址後來被搬走、回傳錯誤、或被連鎖轉址到另一個地方，整組標記就會失效，而且不會有任何系統跳出來警告你。正因如此，我會建議把 hreflang 的健康度排進定期健檢流程，而不是上線設定一次就放著不管。
多語系網站架構怎麼選，才不會被 hreflang 拖垮
hreflang 的複雜度，其實跟你選的網站架構高度綁定。架構選錯，hreflang 的維護成本會被放大好幾倍。常見的三種多語系架構各有取捨，這裡從「對 hreflang 友善程度」的角度快速比較，架構本身的深入分析可以參考我們另一篇 多語系網站架構設計。
子網域（sub-domain），例如 tw.example.com、jp.example.com。每個語系是獨立的子網域，技術上各自獨立部署。優點是各市場可以完全獨立營運，缺點是 子網域與子目錄 在 SEO 權重傳遞上一直有爭論，hreflang 的跨網域設定也相對容易出錯。
子目錄（sub-directory），例如 /tw/、/jp/。所有語系共用同一個主網域，只是路徑不同。這是我個人偏好的架構，因為主網域累積的權重會自然分沾到各語系目錄，hreflang 也因為都在同一網域內而相對好管理。
以一個經營台、港、日三地的旅行社網站為例，採用子目錄架構時，這個選擇最大的好處是在 hreflang 層級：三個市場的頁面共吃同一組 sitemap 產生流程，新增一個行程頁時，三個語系版本的對應關係可以由後台一次性生成，不用各自維護。代價是 URL 結構要設計得很乾淨，否則隨著市場增加，路徑會越疊越亂。老實說，沒有一種架構是萬靈丹，但子目錄把 hreflang 的維護成本壓到最低，對資源有限的團隊是比較務實的選擇。
國家級頂級網域（ccTLD），例如 .tw、.jp。這對使用者最有地域信任感（日本人看到 .jp 直覺信任度高），但每個網域是從零開始累積權重，hreflang 還是要做，等於維護多個獨立站點。除非你是大型跨國品牌、每個市場都有足夠資源獨立作戰，否則這個架構的負擔通常壓垮效益。
新增語系、改版、換網域：hreflang 的維護生命週期
hreflang 不是一次性的設定專案，它有完整生命週期。最容易出事的不是上線那一刻，而是後續每一次結構變動。我把三個高風險場景拆開講。
場景一：新增一個語系。假設你原本有繁中與英文，現在要加日文。直覺做法是建好日文頁面、把日文的 hreflang 加上去。但這只做了一半。你現有的繁中與英文頁面，它們的 head 或 sitemap 裡也必須同步補上指向日文的標記，否則日文版永遠收不到來自其他語系的回連，等於孤兒頁面。真正的工夫落在回頭更新所有既有語系的對應表，新語系本身的頁面反倒是最簡單的一塊。這也是子目錄架構搭配自動化 sitemap 最大的價值：一個設定改動，全站對應關係自動重算。
場景二：移除或下架一個語系。某個市場決定收掉，對應語系頁面要下架。這時候不能只把頁面刪掉，你要回頭把所有還在線上的語系版本裡、指向已下架語系的 hreflang 全部移除。留著指向 404 頁面的 hreflang，會讓 Google 判定這組標記有問題而降低信任。移除語系的清理動作，比新增時更容易被忽略，因為大家都急著關掉、沒人記得回頭收尾。
場景三：網址結構大改或換網域。這是最危險的場景。當你重新規劃 URL 結構，或整個網站搬移到新網域，hreflang 的所有指向網址都會失效。你必須在 301 轉址 落地的同時，把所有 hreflang 的目標網址一次更新到位，兩者不能有時間差。常見的失誤是這樣：轉址先上線，hreflang 更新晚了一週，這一週內 Google 看到的是一堆指向舊網址、再被轉到新網址的鏈，中間多了一跳，整組標記的可信度大打折扣。正確順序是：新網址的 hreflang 先備妥，轉址與 hreflang 更新同一批部署上線。
這三個場景的共同教訓是：hreflang 的健康度取決於你的變更紀律，初始設定再完美都只是起點。一個上線時只有八十分、但每次變更都確實同步更新的 hreflang 系統，長期表現會勝過一個上線時一百分、卻再也沒人維護的系統。把「任何牽動網址的變更，都要同步檢查 hreflang」寫進你的發布流程文件裡，這一條紀律比任何工具都管用。
用網址檢查與爬取工具驗證 hreflang
Google Search Console 的「國際指定目標」報告已停用，現行 GSC 沒有專門列出 hreflang 錯誤的報表。驗證要結合網址檢查、原始 HTML／HTTP 標頭、sitemap 與可檢查雙向回指的爬取工具。
網址檢查工具可協助確認索引狀態、Google 選擇的 canonical 與測試時取得的 HTML；實際能否直接看到 hreflang 取決於呈現內容，因此仍應自行檢查原始碼、回應標頭或 sitemap。
檢索統計與伺服器日誌可補充觀察某語系目錄是否被爬取，但低爬取頻率不能直接歸因於 hreflang，還可能與內部連結、sitemap、內容更新、回應速度或索引需求有關。
實務上我會建議一個月至少完整跑一次這三項檢查。hreflang 的問題不會自己好，而且會隨著你持續新增內容而累積，定期清理比累積到爆才救要輕鬆得多。
把這些檢查點串成一條診斷流程，當你懷疑某個語系流量異常時，可以照著走一遍：
- 先確認該語系的網址本身回應正常（回傳 200，沒有被轉址到別處）。
- 用 GSC 網址檢查看 Google 抓到的 HTML 裡，hreflang 與 canonical 各是什麼。
- 用爬取工具或程式比對每頁自我參照、完整 URL、語言代碼與雙向回指。
- 檢查該頁面的所有 hreflang 目標，逐一確認它們都存在且雙向回連完整。
- 如果以上都正常，再看是不是內容本身與其他語系重複度過高，導致 Google 自行判斷合併。
這個流程的重點是由外往內排查：先排除回應與標記問題，再檢查 canonical、內部連結與內容。定位時間取決於頁面量與實作方法，不保證十分鐘內完成。
JavaScript 渲染的 hreflang：Google 真的看得見嗎
這是一個近年越來越多人踩、卻很少被講清楚的坑。現代網站大量使用前端框架，hreflang 標記常常不是寫死在伺服器回傳的 HTML 裡，而是由 JavaScript 在瀏覽器端動態插入 <head>。問題來了：Google 抓取你的頁面時，會執行 JavaScript 沒錯，但這個執行是有延遲的、而且排在一個獨立的渲染佇列裡。
Google 搜尋會分階段爬取與渲染 JavaScript，但沒有提供每頁固定的幾小時或幾天時程。若 hreflang 只在執行 JavaScript 後出現，驗證與除錯會更困難，也會受渲染錯誤影響。
對大量頁面，JavaScript 錯誤與渲染成本會增加維護風險。不要假設 Google「遲早一定會看到」，也不要把所有問題都歸因於檢索預算；最穩定的做法仍是把標記放在初始 HTML、HTTP 標頭或 sitemap。
我的建議很直接：hreflang 盡可能由伺服器端直接輸出在原始 HTML 裡，不要依賴 JavaScript 動態注入。如果你的網站架構使得這點做不到（例如單頁應用 SPA），至少要確認伺服器端渲染（SSR）或預渲染有把 hreflang 烘焙進初始 HTML。驗證方法很簡單：用 curl 或瀏覽器「檢視原始碼」（不是開發者工具的 Elements 面板），看你能不能在原始 HTML 裡直接找到 hreflang 標記。看得到，代表伺服器就給了；看不到、只有在 Elements 面板才出現，那就是 JavaScript 動態產出的，Google 有可能讀不到。
這個細節之所以重要，是因為它造成的失效是隱形且不穩定的。今天 Google 渲染到了所以有效，明天因為預算吃緊沒渲染到就失效，流量會呈現一種難以解釋的波動。把 hreflang 固化在伺服器端，是把這個不確定性從根上拔掉。
行動優先索引下，行動版也要保留 hreflang
Google 已全面採用行動優先索引，意思是主要使用行動版內容進行爬取與索引，不是額外的行動版排名加分（見 2023 年 10 月的 Mobile-first indexing is here 官方公告）。若桌機與行動版 HTML 不同，行動版也必須保留一致的 hreflang 與 canonical。
官方文件沒有把 SIM 國家碼或 GPS 列為 hreflang 的判定依據，也不應假設搜尋能取得精確定位。這一節真正要檢查的是行動版 HTML 是否仍輸出完整標記，並用行動版網址檢查測試渲染結果。
Google 表示 AI Overviews 與 AI Mode 不需要特殊技術優化；一般搜尋資格與既有 SEO 基本功仍適用。Hreflang 的官方用途仍是說明本地化頁面關係，沒有證據顯示它會提高 AI 引用或語音答案機率。可延伸看 AI 搜尋 與 AEO，但不要把 hreflang 包裝成特殊入場券。
六步行動方案：從今天開始把多語系路由顧好
看完原理，接下來是落地。我把 hreflang 從零到穩的流程拆成六個可執行的步驟，你可以在一兩週內分批完成。
- 盤點所有語系版本與對應網址。列一張表，每一個頁面、每一種語言版本、它的完整 URL，先把現況看清楚，不要憑記憶。這一步很多人嫌麻煩跳過，結果後面每一步都建立在錯誤的前提上。
- 決定代碼策略。逐一確認每個版本的 hreflang 值：用
zh-TW、zh-HK鎖地區，還是zh-Hant鎖書寫系統，全站統一一套邏輯，不要這頁鎖地區、那頁鎖書寫系統混著來。 - 選定實作方法。頁面量小用 HTML link，量大或 CMS 動態生成就用 sitemap，PDF 等非 HTML 檔用 HTTP 標頭。選定後全站一致，不要不同區塊用不同方法，徒增維護負擔。
- 補齊雙向回連，視需要加入 x-default。逐頁檢查每組對應關係都是雙向的；有語言選擇頁或通用預設頁時，再加入 x-default。
- 讓 canonical 與 hreflang 不打架。每個語系頁面 self-canonical，確認沒有把不同語言版本合併到單一主版本的矛盾設定。同時確認 hreflang 指向的網址都回傳 200。
- 上線後重新驗證。提交更新後的 sitemap，使用網址檢查、原始碼／回應標頭與爬取工具確認標記；GSC 已沒有國際指定目標報告。
多語系 SEO 不是一個做完就結束的專案，它是一套需要持續維護的路由系統。每新增一個語系、每改動一次網址結構，hreflang 都要跟著更新。把它想成網站的地基：平日看不出存在，但一旦鬆動，整棟多語系流量大樓都會跟著晃。
回頭看這篇的核心訊息，其實只有一句話：hreflang 是你跟 Google 之間關於「誰該看到什麼」的合約，而合約的效力建立在雙向、完整、不矛盾這三個條件上。把這三件事顧好，剩下的細節都是在這個骨架上添肉。別執著於一次到位的完美，把每次變更都當成重新驗證這份合約的機會，這才是多語系網站能長期穩定收成的真正原因。
如果你正在規劃進軍多個市場，卻不確定從架構到標記該怎麼一次到位，這正是 Whoops 擅長協助的範疇。卡關時隨時來談，我們陪你把這套多語系地基一次打好。
常見問題
geo-redirect 會影響 hreflang 嗎？
設了 hreflang 為什麼排名沒變？
新增語言版本後，舊頁面要怎麼補標記？
機器翻譯的頁面需要設 hreflang 嗎？
zh-TW 和 zh-Hant 有什麼差別，該用哪一個？
操作步驟
- 盤點版本：列出所有語言與地區版本，建立對應表，明確標示每頁的目標市場。
- 選定方式：依網站架構與維護便利性，從 HTML 標記、HTTP Header、XML Sitemap 三選一，不要混用。
- 製作清單：產出 URL 對應清單，製作清單：產出 URL 對應清單，每頁都要包含自我參照（self-referencing）與完整對應，並視需要加入 x-default，確保每頁都能正確回指。，確保每頁都能正確回指。
- 同步上線：分批上傳、同步上線避免新舊版本不一致，並用網址檢查、原始碼檢視與可驗證雙向回指的爬取工具確認標註與代碼正確性。
- 追蹤成效：在 Search Console 成效報表依國家與語言篩選，觀察各語言版本在對應地區的曝光與點擊，定期回頭修正。