Hreflang 怎麼做：多語言網站配置、錯誤與排查（2026）

很多人一提多語言 SEO，先想到的就是 hreflang。這個方向沒錯，但也最容易做偏。因為 hreflang 不是“裝了就能讓不同國家都排好”，它只是告訴 Google：這些 URL 是同一內容的不同語言或地區版本，請儘量把合適的版本給合適的人。

如果站點本身的語言版本沒拆清、URL 結構混亂、頁面主要內容並沒有真的翻譯，只是在頁頭頁尾換了語言，那 hreflang 寫得再工整，效果也很有限。Google 在 Managing multi-regional and multilingual sites 和 Localized versions of your pages 裡其實講得很清楚：先把不同語言版本做成不同 URL，再用 hreflang 或 sitemap 告訴 Google 這些頁面之間的關係。

這篇文章重點放在一件事上：hreflang 到底該怎麼做，什麼時候該上，什麼時候沒必要上，HTML、HTTP Header、Sitemap 三種實現怎麼選，常見錯誤怎麼排查。更適合外貿獨立站、多語言企業站和已經開始做國際 SEO 的團隊看。

核心判斷：hreflang 解決的是“版本對映”，不是“語言識別”

很多團隊把 hreflang 當成一種“讓 Google 識別頁面語言”的方法。這個理解不對。Google 官方寫得很明白：Google 不靠 hreflang，也不靠 HTML 的 `lang` 屬性來判斷頁面語言，而是主要看頁面的可見內容。

這意味著兩件事：

• 第一，頁面的主要內容還是要真的翻譯清楚，不能只翻導航和頁尾。
• 第二，hreflang 的作用更像“版本說明書”，告訴 Google 哪些 URL 是相互對應的語言或地區版本。

什麼時候需要 hreflang，什麼時候其實不急

不是所有站都必須急著配 hreflang。更準確的判斷方式是看：你的網站是不是已經存在多套語言或地區頁面，而且這些頁面應該互相對應。

下面這些場景，通常值得配：

• 同一產品頁有英文、德文、法文版本。
• 同一英文頁又拆成美國、英國、澳洲三個版本。
• 同一資料頁、案例頁、服務頁在不同國家市場有穩定對應頁面。
• 站點已經有多語言目錄，但 Google 經常把使用者帶到錯誤語言頁。

下面這些場景，反而不一定要急著上：

• 站點只有一個英文站，沒有第二套對應版本。
• 只有首頁做了多語言切換，正文頁並沒有成套翻譯。
• 頁面只是用外掛臨時機器翻譯，內容質量和結構並不穩定。
• 你現在真正的問題還在收錄、模板、站點結構，不在多語言對映。

換句話說，hreflang 更適合“多版本已經存在，但版本關係沒有講清”的站，而不適合“站點基礎還沒搭好”的站。

hreflang 和國際 SEO 的關係，不要混成一件事

站內已經有 國際SEO完整指南 這類更上層的主題。那篇更像總論，講的是多語言市場、URL 結構、國家站和內容佈局。hreflang 這篇文章要更聚焦。

你可以把它們理解成兩層：

1. 國際 SEO 決定你要不要做多語言、多地區，以及站點結構怎麼拆。
2. hreflang 決定已經拆出來的版本，怎麼正確對應起來。

所以很多專案裡，真正的順序不該是“先寫 hreflang 程式碼”，而應該是：

1. 先定市場和語言策略。
2. 再定 URL 結構。
3. 再保證每個版本頁面真的存在。
4. 最後才是 hreflang 標註。

Google 官方其實給了三種做法，選一種就夠了

Google 支援三種給出語言 / 地區版本關係的方法：

• HTML 裡的 ``
• HTTP Header
• Sitemap

這裡有個很重要的點，很多團隊忽略了。Google 官方明確說，這三種方法從搜尋的角度看是等價的。你不需要三個一起上。三個一起做，管理成本往往更高，錯一處反而更麻煩。

對多數外貿獨立站、WordPress 企業站來說，如果頁面量不算太大，HTML 或 Sitemap 就夠了。PDF 白皮書、產品手冊這類非 HTML 檔案，才更適合考慮 HTTP Header。

正式寫 hreflang 之前，先把版本對映表列出來

很多 hreflang 專案之所以越做越亂，不是程式碼不會寫，而是團隊從一開始就沒有一張乾淨的“版本對映表”。沒有這張表，開發、SEO、內容、翻譯團隊看到的都不是同一套頁面關係。

更合適的做法，是在上線前先整理一張最簡單的對應表，至少包含這些欄位：

• 頁面型別，例如首頁、服務頁、產品頁、部落格頁。
• 主語言版本 URL。
• 其他語言或地區版本 URL。
• 是否真的完成翻譯。
• 是否允許進入 hreflang 集合。

這一步聽起來笨，但非常值錢。因為它能提前暴露兩個最常見的問題：哪些頁面其實沒有成套版本，哪些頁面雖然有 URL，但內容根本還沒翻完。很多 hreflang 報錯，本質上不是“標籤錯了”，而是被錯誤地拉進了同一版本集合。

最常見的第一類錯誤：只有語言切換，沒有獨立 URL

Google 官方建議，不同語言版本最好有不同 URL，而不是靠 cookie、瀏覽器語言、或者 JavaScript 動態切換同一個 URL 的內容。原因也不復雜：如果只有一個 URL，Google 很難穩定抓到全部變化版本。

這一點對外貿站特別重要。很多站看起來有中英切換，實際是同一個 URL 根據瀏覽器或地區切換內容。使用者看著好像沒問題，但對搜尋引擎來說，版本邊界非常模糊。

更穩妥的做法通常是下面幾種：

• `example.com/en/`、`example.com/de/` 這種目錄型。
• `en.example.com`、`de.example.com` 這種子域型。
• `example.de`、`example.fr` 這種國家域名型。

至於哪種最好，不是 hreflang 決定的，而是你的運維和市場策略決定的。hreflang 只負責把這些已經存在的版本說明白。

第二類錯誤：頁面主要內容沒翻，只有模板翻了

Google 還特別提到一種情況：如果頁面主要內容沒有翻譯，只是導航、頁尾、按鈕這些模板文字變了，這類頁面會帶來很差的使用者體驗。很多站就是這樣，正文仍是英文，只把選單換成了法語、西語。

這時你即使配了 hreflang，也很難說這是“高質量的法語頁”或“真正的西語頁”。更現實的結果通常是：

• 使用者進來後立刻退出。
• Google 仍然更信任原始語言頁。
• 多套頁面互相稀釋，站點結構更亂。

所以做 hreflang 之前，建議先問一句：這些版本頁，是真的本地化頁面，還是隻有外殼翻了？這個判斷，比程式碼本身更關鍵。

語言程式碼怎麼寫，很多錯誤都死在這裡

hreflang 的值不是隨便寫的。Google 官方支援的是語言程式碼，加可選的地區程式碼。語言一般用 ISO 639-1，地區一般用 ISO 3166-1 Alpha 2。

最容易出錯的點有三個：

• 只寫國家，不寫語言。
• 把不受支援的地區寫法當標準程式碼。
• 語言和地區順序寫反。

這類問題最麻煩的地方在於，頁面表面看不出來，程式碼也“像是寫了”，但 Google 可能直接忽略。

x-default 什麼時候該用，什麼時候沒必要濫用

`x-default` 是 hreflang 裡一個很實用但經常被亂用的值。它的作用不是“給預設市場排名”，而是告訴 Google：如果使用者語言設定和現有版本都不匹配，把他送到這個應急頁面。

最適合 `x-default` 的場景通常是：

• 語言選擇頁。
• 國家選擇頁。
• 一個不明確面向單一語言 / 地區的全球入口頁。

如果你本身沒有選擇頁，也沒有全球入口頁，只是想隨便挑一個英文頁當預設頁，也不是不能做，但要想清楚：這個版本是不是能承接那些“不在現有語言列表裡”的使用者。

更實際的經驗是，`x-default` 不是必加項。只有你真的存在一個合理的應急入口，它才有意義。

HTML 方式怎麼做，最適合大多數企業站

如果你做的是普通頁面，最常見也最直觀的做法，是把 hreflang 標籤到 HTML 的 `` 裡。Google 官方要求也很明確：要放在一個結構正確的 `` 段裡，而且每個版本都要列出全部版本，包括自己。

一個最基礎的思路大概是這樣：

<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/product/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/global/product/" />

要注意三點：

• 每個版本頁面都要帶同一組完整連結。
• URL 要寫全，帶協議和完整路徑。
• 不要把 hreflang 和別的 `link` 用法混在一起寫得很怪。

如果你的網站是 WordPress、多語言外掛、或模板站，這類邏輯通常會落在主題頭部、SEO 外掛、或者語言外掛的輸出層。這裡就要特別小心模板級錯誤。因為一旦邏輯寫錯，不是一頁錯，是整類頁面一起錯。你可以把它和 技術SEO指南 裡的模板級排查思路一起看。

HTTP Header 方式，不是主流，但處理 PDF 很有用

很多企業站會忽略一個場景：白皮書、規格書、產品手冊、報價 PDF 也可能有不同語言版本。PDF 不能像普通 HTML 頁面那樣在 `` 裡寫標籤，這時 HTTP Header 方式就有價值了。

Google 官方也專門提到這一點。你可以在 GET 響應頭裡返回類似這樣的 `Link` 關係：

Link: <https://example.com/file-en.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/file-de.pdf>; rel="alternate"; hreflang="de",
      <https://example.com/file-fr.pdf>; rel="alternate"; hreflang="fr"

這種方式不一定適合所有團隊，因為它往往要改伺服器、CDN、或應用層響應邏輯。但如果你的多語言資源裡 PDF 很多，這個方法值得知道。

Sitemap 方式更適合頁面量大、模板複雜的站

如果一個站點有很多語言版本、很多目錄、很多模板，讓每個頁面頭部都穩定輸出 hreflang，維護成本可能不低。這時用 XML Sitemap 集中管理，會更容易控制。

Google 官方支援在 sitemap 裡給每個 URL 加上一組 `` 子節點，列出這個頁面的所有語言 / 地區對應頁。它的核心邏輯和 HTML 方式一樣，本質還是“每個版本列出完整版本集”。

這種方式更適合：

• 產品頁很多的獨立站。
• 目錄結構穩定，但模板層難改的站。
• 已經有程式化生成 sitemap 的團隊。

但它也有明顯風險：一旦生成邏輯錯了，錯的不是一個頁面，而是整批頁面。所以 sitemap 方式省的是單頁維護，不是省校驗。

最常見的致命錯誤：缺少雙向返回

Google 官方反覆強調一個點：如果頁面 A 指向頁面 B，但頁面 B 沒有回指頁面 A，這組標註可能會被忽略。這個規則非常關鍵。

這條規則到底有多容易踩？看一組多語言站的真實體檢資料就知道了——hreflang 的坑，大多數站都在踩：

來源：SearchEngineLand：31% 國際站含 hreflang 錯誤、Ahrefs hreflang 研究

這幾個數字合起來說明一件最該記住的事：hreflang 是”全有或全無”的機制。它不像別的最佳化項能”做了七成拿七成分”——只要集合裡有一個 URL 返回 301/404，或者有一頁忘了回指，Google 就可能把這一整組標註當作無效直接丟掉，你前面寫的全白費。所以對 hreflang 來說，上線後的校驗比當初怎麼寫更重要，這也是為什麼下面要專門花篇幅講怎麼驗證。

很多多語言站的問題就出在這裡。比如英文頁列出了德文頁、法文頁，但德文頁那邊只列了自己和法文，沒有回到英文。或者新加的西語目錄，只在西語頁內部互相連，沒有補回主英文版本。

這種問題為什麼常見？因為團隊往往是分批擴語言站的。老版本先上線，新版本後補，結果 hreflang 集合沒有同步補齊。Google 官方甚至專門提到，如果你沒法維護所有語言之間的完整雙向集合，至少要優先保證新語言頁和原始主語言頁之間的雙向關係。

自動跳轉、按 IP 或瀏覽器語言強制改版，是另一個大坑

很多站點覺得使用者體驗更好，就在首頁或全站做強制跳轉。比如識別到瀏覽器是德語，就自動把使用者推去 `/de/`；識別到 IP 在美國，就直接跳去美區版本。對真實使用者來說，有時確實省一步，但對搜尋引擎抓取來說，這類策略經常出問題。

Google 官方的態度也很明確：

• 不要依賴你“猜測的使用者語言”強制重定向。
• Googlebot 通常從美國發起抓取，而且不會設定 `Accept-Language`。
• 如果你按這些訊號改版，Google 可能抓不到全部版本。

更穩妥的做法通常是：

• 允許所有版本 URL 獨立訪問。
• 頁面上提供清晰的語言切換入口。
• 必要時提示使用者是否切換，但不要直接強制鎖死。

這一點和 網站改版與遷移排查 的思路很像。搜尋引擎最怕的不是你做了選擇，而是你把所有路徑都擋住了。

hreflang 不等於 canonical，兩個訊號不能互相打架

多語言站裡另一個常見錯誤，是把 canonical 和 hreflang 攪在一起。比如德文頁存在，但 canonical 卻統一指向英文主頁面；同時你又在頭部寫了 `hreflang=”de”`。這就是典型的自相矛盾。

更穩妥的原則通常是：

• 如果這些頁面是有效的語言版本，各自應該 canonical 到自己。
• hreflang 負責說明“它們互為版本”。
• canonical 負責說明“這頁自己的規範 URL 是誰”。

一邊告訴 Google “這是獨立德語版本”，一邊又告訴 Google “真正該認的是英文主頁”，訊號自然會打架。多語言站的規範化問題，最好和 SEO審計 裡的 canonical 排查一起看。

多語言 URL 結構怎麼選，hreflang 不會替你做這個決定

很多企業問的是“hreflang 應該寫目錄、子域還是獨立域名？”這個問題本身就有點混了。hreflang 不決定 URL 結構，它只適配你已經選好的結構。

站點結構還沒定清時，先看整體國際 SEO 策略，再決定 hreflang 怎麼掛。不要倒過來。

WordPress 和常見企業站，最現實的排查順序是什麼

對大多數實際專案來說，最需要的不是“知道語法”，而是知道怎麼排。尤其是 WordPress、多語言外掛、定製主題、企業站 CMS 這類環境，問題通常不是單頁，而是輸出邏輯。

更實用的排查順序，我建議這樣看：

1. 先確認不同語言版本是否真的有獨立 URL。
2. 再確認主要內容是否真的翻譯，而不只是模板翻譯。
3. 再確認 canonical 是否各自指向自己。
4. 再看 hreflang 是否完整列出自己和全部對應版本。
5. 再看新語言目錄有沒有回指主語言版本。
6. 最後再查是否有強制跳轉、自動識別語言、快取串頁等問題。

如果你一上來只盯程式碼片段，反而會漏掉真正更底層的問題。

上線後怎麼驗證，不要只看原始碼裡“像是有了”

hreflang 很容易出現一種假象：原始碼裡看得到標籤，於是團隊就預設“已經做好了”。這一步遠遠不夠。更靠譜的驗證，至少要做三層。

1. 先抽樣看原始碼，確認頭部、header 或 sitemap 裡確實有正確輸出。
2. 再看 URL 是否都能返回正常狀態碼，沒有被跳走、被 noindex、被 canonical 指到別處。
3. 最後再看 Google 側的反饋，例如 Search Console、抓取結果和實際展示頁。

Google 的 URL Inspection tool 和 Performance report 雖然不會替你直接“修好” hreflang，但很適合確認：目標 URL 有沒有被正常抓取、索引，以及不同語言目錄有沒有開始更穩定地承接自己的頁面。

如果你用的是 sitemap 方式，還要順手看 Build and submit a sitemap 相關要求，確認 sitemap 本身沒有生成錯誤、路徑錯誤、或更新延遲。

更實際的抽樣方法可以這樣做：

• 首頁抽 1 組。
• 核心服務頁抽 2 組。
• 核心產品頁抽 2 到 3 組。
• 部落格頁抽 2 組。
• 最近新增語言頁再單獨抽 2 組。

只要這些樣本頁裡已經發現成片問題，比如新語言頁都沒有回指、法文頁 canonical 全指向英文、PDF 版本沒返回對應 Header，那就不要再逐頁手看了。先修生成邏輯，效率更高。

適合企業站的 hreflang 上線清單

如果你準備上線一套多語言版本，可以先按這份清單過一輪：

1. 明確哪些頁面真的有對應翻譯版本。
2. 保證每個語言版本都有獨立可訪問 URL。
3. 保證各語言頁主要內容確實完成翻譯。
4. 確認 canonical 沒有統一指回主語言頁。
5. 選擇一種實現方式：HTML、HTTP Header 或 Sitemap。
6. 確保每個版本列出自己和全部版本。
7. 如果有全域性入口頁，再決定是否加 `x-default`。
8. 確認沒有按 IP 或瀏覽器語言強制重定向全部使用者。
9. 上線後抽樣檢查首頁、服務頁、產品頁、部落格頁各一組。
10. 後續新增語言版本時，記得回補舊版本的對應關係。

最常見的 10 個 hreflang 錯誤

1. 只有語言切換，沒有獨立 URL。
2. 主要內容沒翻，只翻了模板文字。
3. 語言程式碼和地區程式碼寫錯。
4. 只寫國家，不寫語言。
5. 沒有雙向返回關係。
6. 新語言版本沒補回主語言頁。
7. hreflang 和 canonical 互相打架。
8. 同一站同時混用三種實現方式，沒人維護一致性。
9. 把所有使用者都強制跳到系統猜測的語言版本。
10. 加了 hreflang 以後就不再抽樣檢查。

什麼時候不用急著修 hreflang，先修別的更值錢

並不是每個國際站當前最該做的事都是 hreflang。很多專案裡，真正更急的是這些問題：

• 多語言目錄大量未收錄。
• 模板輸出混亂，標題和 canonical 同時異常。
• 服務頁內容太空，本身沒法承接商業詞。
• 語言頁很多，但沒有任何國家 / 語言對應的詢盤策略。

如果基礎問題還沒穩，hreflang 往往不是最先帶來結果的動作。它更像“關係修正器”，不是“根本起量器”。這也是為什麼它更適合放在 整站審計 或 國際SEO策略 的框架裡看，而不是單獨神化。

企業站怎麼判斷 hreflang 有沒有發揮作用

hreflang 生效之後，不一定會給你一種“流量立刻暴漲”的感受。它更常見的價值，是減少錯頁、減少語言版本串位，讓不同市場的頁面更穩定地各自承接自己的搜尋需求。

更實際的觀察角度有這些：

• 不同語言目錄的落地頁是否更穩定。
• 某個國家使用者是否不再頻繁落到錯誤語言頁。
• Search Console 中不同目錄的展示頁是否更清晰。
• 新增語言頁是否更容易和原有主語言頁形成對應關係。

如果上線後還是經常出現英文市場進德文頁、法文使用者進英文頁，那就說明版本對映、URL 可訪問性、頁面內容本身，至少還有一層沒做好。

如果你們正在做多語言或多地區站點，這篇文章最好和 國際 SEO、Technical SEO、網站遷移 SEO、SEO 審計 和 谷歌 SEO 最佳化服務 放在一起看。hreflang 本身只是版本對映，真正決定效果的還是 URL 結構、版本完整度和整站國際化策略。

常見問題 FAQ

只有英文和德文兩個版本，也需要 hreflang 嗎？

如果這兩個版本是相互對應的頁面，通常值得加。頁面不多時實現成本並不高，而且能減少版本錯配。

hreflang 和 HTML lang 是一回事嗎？

不是。`lang` 更偏頁面語言屬性；hreflang 更偏不同版本之間的對映關係。Google 官方也明確說，不靠這兩個值本身來判斷頁面語言，而是主要看可見內容。

一定要同時做 HTML、Sitemap 和 HTTP Header 三種實現嗎？

不用。Google 官方說三種方式從搜尋角度看是等價的。一般選一種最容易長期維護的就夠了。

為什麼配了 hreflang，Google 還是可能顯示錯語言頁面？

因為 hreflang 不是唯一訊號。頁面內容質量、URL 可訪問性、canonical、跳轉策略、語言版本完整度，都會一起影響最終結果。

如果你的網站正在做多語言或多地區佈局，但現在最頭疼的是版本頁經常串頁、語言頁互相打架、使用者老是進錯頁面，那 hreflang 值得認真做。但前提還是一樣：先把不同版本真正建出來，再把它們之間的關係講清楚。程式碼只是最後一步，不是第一步。