Hreflang 介紹：多語言的網站架構應該要如何設計？ | 白話文商學院
多語系網站的成敗，最關鍵的兩層技術決策是網址架構與 hreflang 訊號：網址架構用子目錄、子網域、還是獨立網域，hreflang 訊號要怎麼寫。SEO 累積性的排序是子目錄最佳…
多語系網站的成敗，最關鍵的兩層技術決策是網址架構與 hreflang 訊號：網址架構用子目錄、子網域、還是獨立網域，hreflang 訊號要怎麼寫。SEO 累積性的排序是子目錄最佳、子網域折衷、獨立網域最差，差別在於權重是否集中在同一個根網域底下；hreflang 則是 Google 官方唯一用來逐頁指定「這頁要給哪個語言、哪個地區看」的訊號，寫錯會直接把日文頁面送到英文搜尋者眼前。根據 Google Search Central 在《向 Google 說明網頁的本地化版本》的說明，hreflang 是多語言網站的標準做法 [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。而權重能不能集中累積，又與 高品質反向連結的取得 息息相關，架構選錯等於讓這些連結效益分散。
權重累積為何這麼關鍵，背後是有數據支撐的。反向連結被列為 Google 前三大排名因素之一，連結到某個頁面的網站數量與該頁面的流量之間存在明確的正相關 [來源：Ahrefs〈96.55% of Content Gets No Traffic From Google. Here's How to Be in the Other 3.45% [New Research for 2023]〉 https://ahrefs.com/blog/search-traffic-study/ 2023-12-01]。換句話說，外部連結帶來的權重是排名的核心驅動力，而子目錄架構讓所有語言版本的這份權重累積在同一個根網域上，這正是它在 SEO 累積性上勝過獨立網域的根本原因。
重點先看： 三種多語系網址架構的 SEO 累積性排序是子目錄大於子網域大於獨立網域，獨立網域的權重分散是不可逆的單向門；hreflang 寫錯真正的代價在於把錯的語言版本送到錯的人眼前、流量無聲蒸發，而排名下滑反倒不是主要風險 [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。
多語系網站的第一個決策：三種網址架構怎麼選
多語系網站的網址架構有三種主流做法：子目錄（example.com/tw/）、子網域（tw.example.com）、獨立網域（example.tw）。三者 SEO 累積性的排序很明確，子目錄最佳、子網域折衷、獨立網域最差，差別只在於權重是否集中在同一個根網域底下。這個差異在網站流量成長期會被放大成數倍的外部連結效益，不是「都可以，看習慣」那麼輕鬆。
子目錄的做法是所有語言版本共用同一個網域，外部連結與內容權重全部累積在同一個根網域上，分析資料也集中在同一個 GA 與 GSC 資源。對一個已經有單一語言網站、第一次要加日文與英文版本的站長來說，子目錄是 SEO 預設最穩的選擇，不用額外煩惱 反向連結與網域權重的累積 要拆成好幾份。想知道子網域與子目錄在搜尋引擎眼裡到底差在哪，可以對照 子網域 vs 子目錄的 SEO 差異解析。子網域的權重累積介於子目錄與獨立網域之間，Google 視為相關但非完全同一站，這幾年使用比例明顯下降。要先弄懂 網址（URL）是什麼 與 HTTPS 網站安全性 的基本結構，才不會把這三種架構的差別搞混。獨立網域（ccTLD，例如.jp、.co.uk）每個地區都是全新網域，權重從零開始累積，只有地區法規差異極大的電商才有理由承擔這個成本。
| 架構類型 | 網址形式 | 權重累積 | 地區訊號強度 | 適合情境 |
|---|---|---|---|---|
| 子目錄 | example.com/tw/ | 集中在同一根網域（最佳） | 中等，需靠 hreflang 補強 | 多數品牌、內容站、無強烈法規差異 |
| 子網域 | tw.example.com | 折衷，Google 視為相關但非同站 | 中等 | 大型多語系社群、歷史結構沿用 |
| 獨立網域（ccTLD） | example.jp | 各自從零累積（最差） | 強，.jp 直接被視為日本網站 | 各國商品物流金流獨立的大型電商 |
用兩個維度做決策：營運差異度與權重預算
把三種架構放進同一張表只是入門，真正能幫你決定的是一張二維矩陣。橫軸是各語言版本的營運差異度，縱軸是品牌累積權重的預算壓力。營運差異度指的是商品線、價格、庫存、金流、稅務、法規在不同國家之間分岔的程度；權重預算壓力指的是你有多少本錢把一個全新網域從零養起。把這兩個維度交叉，會得出四個象限，每個象限都對應一個明確的架構選擇。
| 象限 | 營運差異度 | 權重預算壓力 | 建議架構 |
|---|---|---|---|
| 第一象限 | 低（各國幾乎相同） | 高（資源有限） | 子目錄，預設選項 |
| 第二象限 | 低 | 低（資源充裕） | 子目錄，仍有累積性優勢 |
| 第三象限 | 高（各國各自獨立） | 低（可承擔多網域） | 獨立網域，如 Amazon 模式 |
| 第四象限 | 高 | 高（無力養多網域） | 子網域折衷，先求營運可分、權重盡量不散 |
多數品牌會落在第一象限：各國賣的內容或商品差不多，行銷資源又不足以同時養好幾個網域，子目錄幾乎是唯一理性的答案。真正需要往第三象限移動的，是像 Amazon 這種每個國家幾乎是獨立公司在運作的跨國電商，它的營運複雜度讓獨立網域反而更合理。第四象限是最尷尬的處境，營運確實需要分開，權重預算卻不夠，這時子網域是一個把傷害降到中間值的折衷，至少主網域還能分到一部分關聯性。這張矩陣的價值在於，它讓你根據自己的營運現實做選擇，避免被「獨立網域地區訊號最強」這類單點說法帶偏方向。
判斷關鍵其實很簡單：沒有強烈的地區法規或品牌授權需求，就一律選子目錄。這也是單向門的問題，從獨立網域併回子目錄要面對大量 301 與權重移轉風險，一開始選對，比做省下後續整個改版工程。這段風險與 SEO 網站搬家與改版的風險 是同一回事，差別只在多語系搬家還多了一層語言版本的對應要處理。講到這裡，不免要提醒一個常被忽略的點：架構選完不是終點，SEO 網址結構的命名原則 在每個語言版本內部都要一致，否則後面 hreflang 對應會全亂。
說到底，這三個選項是一道有預設答案的題目。多數中小品牌根本沒有選獨立網域的理由，權重分散的代價遠大於地區訊號的收益。如果你連網站都還沒架好，先從 沒有網站如何開始做 SEO 把基礎弄起來，再來談多語系擴張會務實很多。先把 網域跟子網域的差別 與 網域與網址的區分 搞清楚，再回來看這張表會更有感覺。
為什麼 Apple 用子目錄、Amazon 卻用獨立網域
Apple 與 Amazon 是兩個跨國大品牌，多語系架構卻選了完全相反的路。Apple 用子目錄，因為各國賣的是同一套產品線、品牌一致、不需要各地獨立定價與供應鏈；Amazon 用獨立網域，因為每個國家的商品、庫存、會員、金流、稅務都各自獨立，把網站拆開反而符合營運現實。架構選擇的背後是商業模式，不是 SEO 偏好。對還在用主題架站的品牌來說，先挑一套適合形象呈現的版型，例如 用 Astra 主題打造專業形象網站，再回頭處理多語系擴張會更從容。
Apple 官網的各國版本全部掛在同一個網域底下，例如 apple.com/tw、apple.com/jp、apple.com/sg，產品線全球一致，權重集中對品牌搜尋最有利。Amazon 則反過來，amazon.com、amazon.co.jp、amazon.co.uk 是三個獨立的 ccTLD，因為商品、庫存、會員系統、稅務各自獨立，技術上幾乎是三家公司在運作。維基百科則用子網域，zh.wikipedia.org、ja.wikipedia.org、en.wikipedia.org 主網域相同、語言用子網域區分。
- ccTLD（國碼頂級網域）本身帶有強烈地區訊號，Google 會把.jp 直接視為日本網站 [來源：〈Manage multi-regional and multilingual sites〉〈https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites〉〈2026〉]
- 子目錄的地區訊號較弱，需要額外用 hreflang 補強，這是子目錄唯一的技術代價
- 選擇邏輯只有一個問題：各語言版本的商品、價格、營運是否真的不同？差很大才考慮獨立網域，幾乎相同就一律用子目錄
- 中小品牌幾乎沒有選獨立網域的理由，權重分散的代價遠大於地區訊號收益
退一步看，Apple 與 Amazon 的例子其實在講同一件事：架構要服務營運，不是服務 SEO 教學裡的「最佳實踐」。如果你的各國版本只是同一份內容換語言，硬學 Amazon 拆成獨立網域，等於把權重重新歸零再慢慢養，這在 SEO 自然流量的成長公式 上是純粹的損失。反之，如果你的日本站真的有獨立供應鏈與定價，硬塞進子目錄反而會讓使用者與搜尋引擎都搞混 SEO 友善網站架構 的層級。判斷的依據是營運現實，不是哪個架構聽起來比較高級。架構之外，各語言版本的權重還得靠 站外 SEO 的反向連結與品牌聲量 慢慢撐起來。
這裡要承認一個不確定性：地區訊號的強度沒有公開的量化數據。Google 官方只說 ccTLD 會被當作地區訊號，子目錄則需要 hreflang 補強，但到底強多少、換算成多少排名影響，沒有人能給出精確數字 [來源：〈Manage multi-regional and multilingual sites〉〈https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites〉〈2026〉]。所以心力該擺在你能完全控制的事上，也就是 hreflang 訊號。能控制的還包括整體的 SEO 友善網站結構設計，底層骨架扎實，多語系訊號才掛得住。
hreflang 的角色與原理
hreflang 是一個註解標籤，用來告訴搜尋引擎「這個網頁是用什麼語言、給什麼地區看」。它的作用不是提升排名，而是讓 Google 把對的語言版本送到對的使用者眼前，漏掉或寫錯，日文頁面就會出現在英文搜尋者面前。對多語言網站來說，hreflang 是不能省的訊號，不是可有可無的裝飾。想把 hreflang 從格式到常見錯誤一次看懂，這份 Hreflang 多語系 SEO 完整手冊 值得一起讀。
hreflang 由 href（超連結目標 URL）與 lang（語言代碼）兩個部分組成，本質是標註同一份內容的各語言對應版本彼此的關係。它解決的是版本匹配問題，不是排名問題，Google 靠它決定在德國搜尋時要回傳德文版還是英文版。這與地區訊號是分工的關係：ccTLD 與子目錄路徑提供的是地區暗示，hreflang 則是明確、可逐頁指定的官方訊號 [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。想理解 Google 整體怎麼處理一個網址，可以先看過 Google 搜尋引擎運作原理 的爬取、索引、排名三個階段，hreflang 主要作用在索引與回傳階段；而 Retrieval 檢索環節 與 網頁索引是什麼 決定了語言版本能不能被正確收錄。
沒設 hreflang 會發生什麼事？最常見的後果有三種：兩個語言版本互相搶同一組關鍵字的排名、使用者點進去看不懂而立刻跳出、或 Google 自動猜錯版本把英文頁面回傳給日文搜尋者。這些問題的核心是對的內容沒送到對的人眼前，流量會在不知不覺中流失。正因如此，hreflang 跟 canonical 標準網址設定 是兩件不同的事，canonical 解決的是「同一份內容多個網址選哪個」，hreflang 解決的是「不同語言版本彼此怎麼對應」，職責完全不同，不能互相取代。
換個角度想，hreflang 之於多語言網站，就像 Title Tag 之於單一頁面，是一個小到容易被忽略、卻直接決定搜尋結果呈現的訊號。差別在於 Title Tag 寫錯最多影響一頁的點閱率，hreflang 寫錯會讓整個語言版本的流量錯置，這也跟 搜尋意圖與高排名、SEO 關鍵字的重要性 的契合度有關，版本錯置等於把對的意見送給錯的受眾。所以它的重要性，不該用「只是一行 HTML」來衡量。
hreflang 代碼格式與真實範例
hreflang 的值採「語言-地區」格式，例如 en（英文）、zh-Hant（繁體中文）、ja-JP（日本日文）。每個語言版本都要用 link rel=alternate 標註彼此，並建議加上 x-default 作為沒有對應版本時的預設頁。代碼格式看似簡單，但出錯率極高，下面把格式規則與硬性要求一次講清楚。
格式為 ISO 639-1 語言碼，可選擇性接區域碼：en、fr、zh-Hant、zh-Hans、ja-JP、es-ES 都是合法寫法。語言碼單獨用（en）會涵蓋所有英文版本，加地區碼（en-GB）則只針對英國地區，兩者可以並存，Google 會優先比對精確的版本 [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。這裡要特別注意一個常見錯誤：舊式的 zh-TW 已經不建議使用，語言碼應優先使用 zh-Hant（繁體）或 zh-Hans（簡體），地區碼才用 -TW、-HK 這類國碼。
<!-- 英文頁的 head 內要列出全部語言對應，包含自己 -->
<link rel="alternate" hreflang="en" href="https://example.com/en/page" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page" />- 雙向互指是硬規則：英文頁要指向法文頁，法文頁也要回指英文頁，任何一方漏指都會被 Google 視為訊號不完整而部分忽略
- 每個版本必須自我引用：英文頁的 hreflang 清單裡也要包含自己 en 的那一行，這是最常被漏掉的
- x-default 用來指定沒有任何語言版本匹配時的預設頁，通常是英文版或語言選擇頁
- 格式錯誤的代價在於整組 hreflang 訊號失效，版本匹配會退回到 Google 的自動猜測，排名本身反而不會明顯下滑
光看規則會覺得 hreflang 沒什麼，但實際操作過就知道，頁面一多、語言一多，互指清單的維護成本會爆炸性上升。一個有五種語言、三百個頁面的網站，光 hreflang 標籤就有一千五百行要對。這也是為什麼大型站會選擇把 hreflang 放進 sitemap 集中管理，而不是逐頁寫在 HTML 裡。如果是用 JavaScript SEO 與收錄 動態渲染的頁面，還要額外確認 Googlebot 真的讀得到 hreflang，否則等於沒寫。在動手之前，先理解 四種連結類型的全面解析 與 內部連結與網站架構 的基本觀念，會發現 hreflang 本質上也是一種連結關係的聲明，只是宣告的對象是搜尋引擎。
這裡要承認一個限制：Apple 官網 (apple.com/tw/tv-home) 在原始碼裡確實可以看到完整的 hreflang 清單，例如 hreflang="ar-AE"、"es-ES"、"en-EG" 並列，可以當作真實範例參考。但 Apple 的做法是工程團隊自動化產生的，一般站長手寫很容易出錯，不要把它當成「照抄就能用」的範本。想用 AI 協助產生與檢查互指清單，可以參考 AI SEO 實戰心法，或直接套用 ChatGPT Atlas 的 SEO 工作流程 來半自動化處理大量語言版本。
hreflang 放在 HTML、HTTP header 還是 sitemap
hreflang 註解有三種放法：頁面 head 的 link 標籤、HTTP 回應標頭、XML sitemap 裡的 xhtml:link。小站用 HTML 最直觀，頁面數量大時用 sitemap 集中管理較不易出錯，關鍵是三種方式只能選一種主力，避免重複或衝突。混用是最危險的做法，因為一旦不同來源的 hreflang 互相矛盾，Google 會直接忽略一部分訊號。
| 放置方式 | 寫在哪裡 | 適合規模 | 優點 | 缺點 |
|---|---|---|---|---|
| HTML link | 頁面 <head> 內 | 數十到數百頁 | 最直觀、修改單頁即時生效 | 頁面量大時維護成本高 |
| HTTP header | 伺服器回應標頭 | 非 HTML 檔（如 PDF） | 可標註非網頁檔案 | 一般內容頁面很少需要 |
| XML sitemap | sitemap 內 xhtml:link | 頁面量大、模板化產生 | 集中管理、一次更新全部 | 除錯需要工具輔助 |
HTML link 是最常見的放法，每個頁面 head 內列出全部語言對應，適合頁面數量在數十到數百之間的網站。HTTP header 主要給非 HTML 檔用，例如多語系的 PDF 型錄，一般內容頁面很少需要。XML sitemap 則是在 sitemap 裡用 xhtml:link 列出每個 URL 的所有語言版本，適合頁面量大、由範本自動產生的網站。三種方式的訊號是等價的，Google 視為相同權重，但實務上建議以一種為主、其餘不重複聲明，這點與 XML Sitemap 對 SEO 的幫助 的整體管理邏輯一致。
驗證 hreflang 的第一線工具是 Google Search Console 的國際定位報告，它會列出 hreflang 錯誤，包括漏寫、格式錯、互指缺失等系統性問題 [來源：〈International targeting report〉〈https://support.google.com/webmasters/answer/6059209〉〈2026〉]。報表操作可以對照 Google Search Console 功能介紹、GSC 安裝與設定教學、Search Console 常用功能 來看。進階的逐頁除錯則要靠 Screaming Frog 爬蟲工具 或 Ahrefs SEO 工具 去爬整站，比對每個頁面 hreflang 清單的對稱性，這在頁面破千的站是唯一可行的方法。
老實說，sitemap 放 hreflang 是大型站最務實的選擇，但它有一個代價：當你臨時改了某一頁的語言版本，sitemap 不會自己更新，要等重新提交與 Google 重新爬取。所以頁面變動頻繁的站，HTML link 反而更即時。怎麼選，看你的站是「頁多但穩定」還是「頁少但常動」，沒有絕對答案。
hreflang 跟 canonical 怎麼搭配，重複內容會被罰嗎
同一份內容翻成多國語言不算重複內容，因為語言本身就是差異。每個語言版本的 canonical 應指向自己（self-canonical），再搭配 hreflang 互指，Google 就會把各版本視為獨立頁面，不會合併也不會懲罰。重複內容的認定標準是「實質內容相同」，不同語言的翻譯屬於本地化版本，根本不在重複內容的範疇裡。想理解 canonical 怎麼把重複網址收攏成一個標準版本，可參考 Canonical URL 解決重複內容的完整指南；而帶 www 與不帶 www 的版本該留哪一個，也是同一類問題，細節可見 www 與 non-www 網址的 SEO 差異。
重複內容指的是實質內容相同的情況，例如 http 與 https 兩個網址、帶 www 與不帶 www 的版本、或 網址查詢參數 造成的重複頁面。不同語言的翻譯不屬於這一類，因為對使用者與搜尋引擎來說，英文頁與日文頁服務的是完全不同的需求。這個區分在 SEO 重複內容處理 有完整說明，核心觀念是把「重複」與「本地化」分開看待。對搜尋引擎來說，這也牽涉到 Entity SEO 核心概念 與 資訊增益內容概念，不同語言版本若能各自補充該市場的獨特資訊，價值會更高。canonical 本身的運作講得更細，這裡只聚焦它跟 hreflang 的搭配。
- 正確做法：每個語言版本的 canonical 指向該版本自己（self-canonical），告訴 Google 這個 URL 是這個語言的標準版本
- 常見致命錯誤：把所有語言版本的 canonical 都指向英文版，等於告訴 Google 其他語言是副本，會導致非英文版本從索引消失
- hreflang 與 canonical 並用：hreflang 說明彼此關係，canonical 確認各自的標準網址，兩者職責不同且必須一致
- 地區相同但語言不同的版本（如 fr-FR 與 fr-CA）也靠 hreflang 區分，而非靠 canonical 合併
最常見、也最致命的錯誤，是把所有語言版本的 canonical 都指向英文版。這等於明明白白告訴 Google「日文、法文、德文頁都是英文頁的副本」，Google 收到後會把非英文版本從索引移除，結果就是辛苦翻譯的頁面直接從搜尋結果消失。這不是理論上的風險，而是實際會發生的硬錯誤，而且發生時往往沒有任何警示，要等到 GSC 網頁索引報表解讀 裡看到「已排除」數量暴增才會發現。這也是為什麼 hreflang 與 canonical 的設定一定要交叉檢查，不能分開交給不同人處理。
說實在的，canonical 跟 hreflang 的搭配，是多語系網站技術設定裡最容易出事、也最難自己除錯的一環。原因在於兩者寫在不同位置、改的時候容易只改一邊。一個穩妥的做法是把它們當成一組綁定檢查，每次改動都要同時確認對稱性，這跟 robots.txt 的 SEO 效果、noindex 對 SEO 的影響、robots.txt 與 noindex 的差別、不被索引的四個方法 這幾個索引控制訊號要一起看是同樣的道理。
翻譯、在地化與轉譯：三種內容深度決定市場穿透力
技術訊號搭好之後，真正決定每個語言版本能不能在當地市場站穩的，是內容本身。把同一份中文直接機翻成日文、英文、法文，hreflang 寫得再正確，也只是把一份在當地讀起來很生硬的內容精準送到當地使用者眼前。多語系內容的深度可以分成三個層次，每一層對市場穿透力的貢獻差很多。
- 翻譯（translation）：逐字把源語言換成目標語言，語法正確但語感生硬，常出現當地人不會用的說法與句型
- 在地化（localization）：在翻譯基礎上調整貨幣、日期格式、計量單位、顏色意涵、節慶、在地案例，讓內容讀起來像當地人寫的
- 轉譯（transcreation）：為目標市場重新創作，重新選題、重寫標題、替換整段敘事，只保留核心訊息與品牌調性，本質上是為當地市場量身打造的內容
三個層次的成本與報酬差距很大。翻譯成本最低，適合商品規格、技術文件這類只需準確、不需共鳴的內容；在地化是大多數頁面的合理水位，能避免最基本的文化誤觸與格式錯亂；轉譯成本最高，但對落地頁、行銷活動頁、品牌故事這類需要打動當地使用者的頁面，回報也最高。判斷某個頁面該用哪一層，問一個問題就夠：這個頁面是要「讓人讀懂」還是「讓人買單」？只要牽涉到說服與轉換，轉譯的投資就值得。
在地化的另一個面向是搜尋行為差異。同一個產品在不同市場的搜尋詞常常完全不同，例如台灣使用者搜的詞與日本使用者搜的詞，即使指涉的是同一個產品類別，用字、長度、甚至搜尋意圖都會分岔。如果各語言版本只做翻譯、沿用同一組關鍵字佈局，等於放棄了每個市場各自的高價值字。這也是為什麼每個語言版本都要獨立做 關鍵字研究，把當地使用者的實際搜尋詞挖出來，再回頭調整標題、章節與內文，而不是把主語言的關鍵字清單整批翻過去。各市場的關鍵字差異，也會回頭影響 hreflang 的設計，例如同一個產品在英國與美國的搜尋詞不同，對應的 en-GB 與 en-US 版本就值得拆開經營。
多語系內容品質檢核表
每個語言版本上線前，可以用一份檢核表確認內容深度到位。這份表單對應的是實際會被使用者與搜尋引擎同時檢驗的項目，逐項打勾能擋掉最常見的在地化疏漏。
- 貨幣、稅制、運費已換成當地格式與金額，沒有殘留主市場的符號
- 日期、時間、地址、電話格式符合當地慣例，避免造成混淆
- 圖片中的文字、旗幟、節慶、人物符合當地文化脈絡，沒有冒犯或錯置
- 標題與內文使用當地實際的搜尋詞，而非主語言關鍵字的直譯
- 連結、聯絡方式、客服管道指向當地可用的資源，沒有導回主市場頁面
- 結構化資料（如價格、庫存、評論）的語言與地區欄位已正確填入
- 法律但書、退換貨政策、隱私權聲明符合當地法規要求
hreflang 最常見的五種錯誤與檢查方法
hreflang 設定最容易踩的坑有五個：單向指向、漏掉自我引用、代碼格式錯、與 canonical 衝突、忘記 x-default。這些錯誤的共通點在於讓整組 hreflang 訊號失效，把版本匹配丟回給 Google 自動猜測，而排名訊號本身通常不會受影響。檢查靠 Google Search Console 國際定位報告抓系統性錯誤，再用爬蟲工具逐頁比對對稱性。
錯誤一：單向指向
Google 要求 hreflang 的互指必須雙向完整，英文頁指向法文頁，法文頁也要回指英文頁。任一方漏寫，Google 會把整組 hreflang 視為訊號不完整而部分忽略 [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。這個錯誤在新增語言版本時最容易發生，因為人通常只記得在舊頁加上新版本的指向，忘了回頭在新頁補上舊版本的回指。
錯誤二：漏掉自我引用
每個頁面的 hreflang 清單裡必須包含自己那一行。英文頁的清單裡要有 hreflang="en" 指向自己，否則訊號不完整。這條規則反直覺，多數人會想「我自己當然是我自己」，但 Google 要的是明確的宣告，不是預設值。漏掉自我引用是新手最常犯、也最難自己發現的錯誤，因為頁面看起來一切正常，只有爬蟲工具能抓出來。
錯誤三：代碼格式錯
舊式寫法 zh-TW 已不建議，語言碼應優先使用 zh-Hant（繁體中文）或 zh-Hans（簡體中文），地區碼才用 -TW、-HK [來源：〈Tell Google about localized versions of your page〉〈https://developers.google.com/search/docs/specialty/international/localized-versions〉〈2026〉]。常見的格式錯誤還包括用底線取代連字號（zh_TW 而非 zh-Hant）、大小寫不一致、或把語言碼與地區碼順序寫反。這些 Google 大多能容錯，但容錯不是保證，最穩的做法是照官方格式來。
錯誤四：與 canonical 衝突
hreflang 指向 A 頁，canonical 卻指向 B 頁，Google 會優先採信 canonical 而讓 hreflang 失效。這個衝突通常發生在套用範本時，canonical 預設指向某個標準網址，結果跟 hreflang 宣告的版本對不上。除錯時要把兩者放在一起看，確認每一頁的 canonical 與 hreflang 指向的版本一致，這也是前面強調 self-canonical 的原因。
錯誤五：忘記 x-default
x-default 用來指定沒有任何語言版本匹配時的預設頁。沒設的話，當使用者的語言不在你支援的清單裡，Google 就只能自行猜測要回傳哪一頁，結果常常是錯的。x-default 通常指向英文版或一個語言選擇頁，雖然不是強制，但少了它等於把最後一道保險交給運氣。
檢查流程建議分兩步。第一步用 GSC 國際定位報告抓系統性錯誤，這是國際訊號的第一線監控，操作細節對照 GSC 網址檢查工具。第二步用爬蟲工具逐頁比對 hreflang 清單的對稱性與格式，這一步在頁面量大的站是唯一能徹底清查的方法；至於 搜尋結果頁 SERP 元素 的呈現，也可以順便確認各語言版本是否如預期出現在對的市場。把這兩步當成上線前的固定流程，能擋掉絕大多數的 hreflang 災難。
症狀與根因對照表：hreflang 出問題時怎麼排查
hreflang 的除錯最難的地方在於，症狀往往很籠統，根因卻藏在好幾個可能的環節裡。症狀與根因的對照表把常見症狀對應到最可能的根因與第一個該檢查的位置，能縮短來回摸索的時間。
| 觀察到的症狀 | 最可能的根因 | 第一個該檢查的位置 |
|---|---|---|
| 某語言版本流量歸零 | canonical 跨語言指向主版本 | 該版本頁面的 canonical 標籤 |
| 日文頁面出現在英文搜尋結果 | hreflang 缺漏或單向指向 | GSC 國際定位報告的錯誤清單 |
| 兩個語言版本互相搶排名 | hreflang 互指不完整或格式錯 | 兩個版本彼此的 hreflang 清單對稱性 |
| GSC 顯示大量 hreflang 錯誤 | 範本產生邏輯有系統性缺陷 | 共同範本或外掛的 hreflang 輸出 |
| 特定地區版本不被收錄 | 地區導向把爬蟲擋住 | 伺服器日誌與 robots、轉址規則 |
| 改版後某語言訊號失效 | sitemap 未同步更新或快取舊版 | XML sitemap 與 CDN 快取狀態 |
這張表的用法是先讀症狀、再往根因收斂，避免一上來就逐頁翻原始碼。症狀籠統時，例如「流量怪怪的但說不上哪裡」，先回 GSC 國際定位報告看有沒有系統性錯誤訊號，再決定要不要動用爬蟲工具做全站比對。除錯的順序原則是從系統性、低成本的檢查先做，再進到逐頁、高成本的人工比對。
多語系網站上線前的檢查清單
多語系網站正式上線前，至少要驗八個項目：網址架構一致性、每頁 hreflang 雙向互指且含自我引用、x-default 已設、各版本 self-canonical、sitemap 含所有語言版本、GSC 已新增各語言資源、GA 能區分語言流量、地區導向不會擋住搜尋引擎。這八項任何一項漏掉，都可能讓某一個語言版本的流量悄悄歸零。如果你是用 WordPress 架站，WordPress 架站與 SEO 優化全攻略 與 WordPress SEO 必做的幾大設定 可以把底層先調好，多語系擴張才有穩固的基礎。
之所以把 WordPress 當作多語系擴張的預設底層，是因為它在市佔上的普及度讓多語系外掛與資源生態最完整。W3Techs 的調查顯示，WordPress 在所有網站的市佔率為 41.5%，在已知內容管理系統的網站中更高達 59.2% [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]。這意味著絕大多數多語系外掛（如 TranslatePress）都以 WordPress 為首要支援平台，從 hreflang 設定到語言切換器的整合都最成熟，這也是前面檢查清單能順利落地的前提。
- 網址架構一致性：所有語言版本遵循同一命名規則（/tw/、/jp/、/en/），避免混用大小寫或斜線，這與 網址路徑 與 網址組成結構 的規範一致，至於要用 中文網址或英文網址，建議路徑段統一用英文代碼以避免編碼問題
- hreflang 完整性：互指雙向、含自我引用、含 x-default、代碼格式正確（zh-Hant 而非 zh-TW）
- canonical 一致性：各版本指向自己，沒有跨語言指向
- sitemap 完整性：所有語言版本都列入 XML sitemap 並提交至對應的 GSC 資源
- GSC 資源設定：為每個子目錄或子網域新增獨立的 GSC 資源，方便分語言監控
- GA 流量區分：用自訂維度或篩選器區分語言版本流量，避免資料混在一起無法評估各市場表現；這也是 關鍵字研究終極指南 與 長尾關鍵字策略 能否落地的前提，沒有分語言的資料，根本看不出哪個市場該補什麼字，也談不上把各市場流量接進 行銷漏斗 做轉換
- 地區導向不擋爬蟲：自動轉址與語言偵測不能把 Googlebot 擋在門外，否則連 爬取與爬取預算 都會出問題
- 索引狀態確認：上線後定期查 GSC 網頁索引報表，確認各語言版本都被正常收錄
這份清單看起來繁瑣，但每一項都對應一個實際會發生的故障模式。網址架構不一致會讓 hreflang 對應全錯，canonical 跨語言指向會讓非主語言版本從索引消失，地區導向擋爬蟲會讓整個語言版本根本進不了索引。這些訊號要持續監控，與 SEO 內容年度更新 的維護節奏是同一個層級的工作。這類底層設定多半歸在 技術性 SEO 指南 的範疇，而跨語言的追蹤代碼部署，用 Google 代碼管理工具 GTM 統一管理會比逐頁塞 script 來得省事。
地區導向與爬蟲這一項之所以特別敏感，是因為 Google 已全面採用行動優先索引（mobile-first indexing），所有能在行動裝置上運作的網站，都會優先被行動爬蟲檢索 [來源：Google Search Central Blog〈Mobile-first indexing is here〉 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。對多語系網站來說，這代表語言偵測、自動轉址、hreflang 註解，通通都要以行動版為準。如果你的行動版與桌面版在語言切換器或轉址邏輯上不一致，行動爬蟲會以它看到的行動版為真相，桌面版即使寫對也會被忽略。再加上行動裝置在 2026 年第一季佔全球網站流量的 52.27% [來源：Statista〈Share of mobile web traffic worldwide quarterly 2015-2026〉 https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026-04-28]，每一個語言版本的使用者體驗都必須以行動為第一優先，否則即使索引正確，跳出率與停留時間也會拖垮排名訊號。
講了這麼多技術細節，回頭看整個多語系網站的成敗，其實就卡在開頭那兩個決策：網址架構選子目錄，hreflang 寫對、寫滿、寫對稱。翻譯品質、內容在地化、選詞精準度這些固然重要，但如果底層訊號沒搭好，再好的翻譯也送不到對的人眼前。所以重心該擺在架構與 hreflang。進階一點，還可以搭配 結構化資料的意義與用途 與 Open Graph 社群分享標籤，讓各語言版本在分享與被引用時也帶正確的語言標記，完整的標記寫法可對照 結構化資料 Schema 標記教學。把這兩層做對，多語系網站的 SEO 就站穩了一半，剩下的就是各語言版本各自的內容經營，跟單一語言網站的功課沒有兩樣。
給一個收尾的判斷標準：如果只能記一件事，就記住子目錄加 hreflang 雙向互指加 self-canonical 這個組合。它不是唯一解，但是容錯率最高、維護成本最低、也最符合多數品牌營運現實的選擇。偏離這個組合之前，先問自己有沒有足夠的技術理由與營運需求，否則老老實實走這條路，會省下後面無數的除錯心力。這條路的底層邏輯，其實跟 SEO 自學懶人包、AI 時代 SEO 趨勢建議、E-E-A-T 內容品質原則 講的是同一件事：把可控制的技術訊號做扎實，再談內容與品牌的累積。
多語系網站 hreflang 與網址架構常見問題
多語系網站要選子目錄、子網域還是獨立網域？
沒有強烈地區法規或品牌授權需求時，一律選子目錄。它的 SEO 累積性最佳，權重集中在同一個根網域，分析資料也整合在單一 GA 與 GSC 資源。獨立網域只在各國商品、物流、金流完全獨立時才考慮，且權重分散不可逆。要能自由用子目錄擴張語言版本，通常得先把網站搬到可完全自架的 WordPress，這一步可看 WordPress.com 搬家到 WordPress.org。
hreflang 標籤是什麼，為什麼一定要設？
hreflang 是標註網頁語言與地區的註解，作用是讓 Google 把對的語言版本送到對的使用者眼前。它不影響排名，但漏設會導致版本錯置，例如日文頁面出現在英文搜尋結果裡。多語言網站必設。如果是用 WordPress 架站，視覺化的 TranslatePress 多語系外掛教學 能幫你把翻譯與 hreflang 一起設定好。
hreflang 的語言代碼跟地區代碼怎麼組合？
格式為「語言-地區」，語言碼用 ISO 639-1，地區碼可選。en 涵蓋所有英文，en-GB 只針對英國，兩者可並存。繁體中文建議寫 zh-Hant 而非舊式 zh-TW，依 Google 採用的 IETF BCP 47 格式。
hreflang 要寫在 HTML 還是 sitemap？
小站寫在 HTML 的 head 內最直觀，頁面量大時改用 XML sitemap 的 xhtml:link 集中管理。兩者訊號等價，但建議擇一為主、不重複聲明，避免混用造成衝突。在動手整理 sitemap 之前，先用 ChatGPT 搭配工具畫出網站架構圖 把整體結構理清，多語系的對應會更容易規劃。
多語言版本會被當成重複內容嗎？
不會。不同語言屬於本地化版本，語言本身就是內容差異，不在重複內容範疇。重複內容指的是 http/https、帶不帶 www、或查詢參數造成的實質相同頁面。這類協定層的重複，正好也是 HTTP 換 HTTPS 該處理的問題 的一部分。
hreflang 跟 canonical 有什麼差別，可以同時用嗎？
兩者職責不同且必須同時用。hreflang 說明各語言版本的對應關係，canonical 確認每個版本的標準網址。正確做法是每個語言版本的 canonical 指向自己（self-canonical），再搭配 hreflang 互指，兩者指向必須一致。
hreflang 寫錯會出現什麼問題？
最常見的後果是版本錯置，日文頁面送到英文搜尋者眼前，或兩個語言版本互相搶排名。單向指向、漏掉自我引用、格式錯誤，都會讓整組 hreflang 失效，版本匹配回到 Google 自動猜測。
x-default 要設嗎，給誰用？
建議設。x-default 指定當使用者語言不在支援清單時要回傳的預設頁，通常指向英文版或語言選擇頁。少了它，這類使用者的版本就由 Google 自行猜測，常常猜錯。