多語言網站 hreflang 技術 SEO：繁中／簡中／英文站的正確標記與踩坑

香港公司做出海網站，常見路線是先有繁中站，面向香港、台灣及海外華語客戶；再做英文站，承接國際與東南亞市場；之後視需要加入簡中版本，覆蓋中國大陸、星馬或其他華語搜尋需求。真正麻煩的地方，是同一批內容有了多個語言版本後，hreflang 一旦標錯，Google Search Console 未必會亮紅燈提醒。很多時候，Google 只是靜默忽略錯誤標記，結果錯誤版本出現在錯誤市場。

本文是技術 SEO 教學，屬於出海企業會遇到的網站基建延伸脈絡，並非任何自家代辦服務。讀完後，你應能判斷語言碼怎樣填、三種實作方式如何選，以及 canonical 衝突為何會令整個 hreflang cluster 失效。

1. 什麼是 hreflang？為何香港出海站一定會遇到

hreflang 是一組給搜尋引擎看的替代版本訊號，用來說明同一內容有哪些語言或地區版本，以及搜尋結果應該向哪類使用者顯示哪一版。假設同一篇文章有香港繁中版、英文版與簡中版，內容主題相近，Google 需要知道它們不是互相抄襲，而是同一頁面的不同語言版本。

這裡有三個常見誤解。第一，hreflang 不是排名因子。它不會因為頁面加了標記，就直接讓排名升高；它是在頁面本身已有排名訊號時，協助 Google 選出較適合使用者的語言或地區版本。第二，Google 不靠 hreflang 判斷頁面語言。Google 官方文件明確表示，它不使用 hreflang 或 HTML lang 屬性來偵測頁面語言，而是使用演算法判斷。第三，hreflang 不是指令。John Mueller 在 2025 年仍重申，hreflang 是 hint，不是 directive；就算標記正確，也可能被 canonical、索引狀態、站點結構或內容相似度覆蓋。

對香港出海站來說，港澳台與多數海外市場仍以 Google SEO 為主，所以標準 Google hreflang 做法是基礎功。若要進入中國大陸，還會牽涉 Baidu、ICP 備案與本地主機等問題，不能假設 Google 的 hreflang 機制可以處理所有市場。

2. 繁中／簡中／英文：語言碼到底怎麼填

多語言 SEO 的第一個技術關卡通常不是工具，而是語言碼。標準做法是使用 ISO 639-1 語言碼，例如 en、zh、ja；如需地區，再加 ISO 3166-1 Alpha-2 地區碼，例如 en-US。整體格式遵循 IETF BCP 47，語言碼通常小寫，地區碼通常大寫，中間用連字號，不用底線。

中文站特別容易出錯，因為中文同時有 script 與 region 兩個維度。script 是字體變體，例如繁體與簡體；region 是地區，例如香港、台灣、中國大陸。Google 官方文件列明 zh-Hant 可代表繁體中文，zh-Hans 可代表簡體中文；如果需要更精準，才加入地區碼，例如 zh-Hant-HK、zh-Hant-TW、zh-Hans-CN。ICU 相關建議亦採用語言、script、region 的順序，也就是把 script 放在中間。

香港站的實務判斷可以簡化成一句話：內容差異不夠大，不要急著拆 region。如果繁中內容主要覆蓋香港、台灣及海外繁中讀者，可先用 zh-Hant。如果香港與台灣頁面在法規、幣別、用語或服務流程上真的不同，才拆成 zh-Hant-HK 與 zh-Hant-TW。英文站可先用 en；只有英美港內容明顯不同，才使用 en-HK、en-US 或其他地區版本。

常見錯碼表

以下錯碼很常見，而且 Google 多數不會主動報錯，只會忽略或弱化標記：us 是地區，不是語言；en-UK 應改為 en-GB，因為 uk 是烏克蘭語語言碼；en_US 應改為 en-US；jp 應改為 ja；cn 應改為 zh；kr 應改為 ko。裸 zh 雖然可表示中文，但對繁簡場景過於模糊，通常不適合用作香港繁中與簡中站的主要標記。

3. 三種實作方式與如何擇一

Google 官方列出三種 hreflang 實作方式：HTML head 內的 <link rel='alternate'>、HTTP Link header，以及 XML sitemap 內的 xhtml:link。從 Google Search 角度看，三者是等價的，選一種即可；同時使用多種方式沒有額外搜尋好處，反而會增加維護成本。

HTML head

HTML head 是最直觀的方法，工程師與 SEO 顧問可以透過 view-source 直接檢查。對繁中、簡中、英文三語站來說，這通常已經足夠。缺點是標記量會隨語系數量快速增加；語系接近或超過十個時，頁面模板與 QA 成本會明顯上升。

XML sitemap

XML sitemap 適合大型企業站、商品站或內容量很大的站點，因為 hreflang 關係可集中在 sitemap 管理，不必塞進每頁 HTML。代價是更新與抓取可能較慢反映，除非 sitemap 產生與提交流程本身已經很成熟。

HTTP Link header

HTTP Link header 最適合 PDF、圖片、文件或其他非 HTML 資源，因為它們沒有 head 區塊可放 link tag。注意每個語言變體都要回傳完全相同的一組 Link header，否則 return tag 關係會斷裂。

這裡的鐵律是：不要混用兩種 emission。若 HTML 與 sitemap 同時輸出，而其中一邊漏頁、URL 不一致或 canonical 狀態不同，就很容易製造 hreflang 衝突。香港三語站通常用 HTML head 即可。

4. 四條鐵律：self-reference、雙向互指、絕對 URL、200 狀態

第一，每個語言版本都要列出自己。Google 官方寫法是，每個語言版本必須列出自己以及所有其他語言版本。第二，所有版本必須雙向互指；如果 A 指向 B，但 B 不指回 A，這組標記會被忽略。第三，URL 必須是完整絕對 URL，包含 https:// 或 http://，不能使用 /path 或 //example.com/path。第四，目標頁必須回 200、可抓取、可索引；如果目標頁 404、redirect chain 太長、noindex，或被 robots 阻擋，hreflang cluster 就不可靠。

最致命的坑：hreflang × canonical 衝突

多語站最常見的高風險錯誤，是所有語言頁 canonical 都指向同一個主語言頁。例如英文頁與簡中頁的 canonical 都指向繁中頁，頁面又用 hreflang 表示三頁互為替代版本。這對 Google 來說是矛盾訊號：canonical 說只有繁中頁應被視為正本，hreflang 又說英文與簡中頁應在不同市場出現。實務上，Google 可能直接忽略整個 hreflang cluster，非主語言頁在相關語言 SERP 中變得很弱。

正確做法是：每個語言頁 canonical 指向自己，再用 hreflang 互相連結。處理順序亦應先修 canonical，再修 hreflang；否則你可能是在一組已被 canonical 否定的頁面上反覆修標記。canonical、hreflang 與 html lang 三個訊號應保持一致。

5. x-default：語言選擇頁與 fallback 怎麼設

x-default 不是語言碼，而是 fallback 指示。Google 官方用途包括語言或國家選擇頁、會依地理位置自動導向的首頁，以及沒有對應語系時應顯示的 catch-all 頁面。它不會自動替使用者轉址，只是告訴搜尋引擎在 SERP 沒有更精準匹配時，應該顯示哪一版。

每個頁組通常只設一個 x-default。對繁中、簡中、英文三語站而言，x-default 可指向英文版，或指向一個真正存在的語言選擇頁。重要的是，x-default 頁本身也要含有指向所有語言變體的 return tags。當網站已有三個或以上語言變體，把 x-default 納入檢查清單會比較穩妥。

6. 香港站的實戰決策樹

第一步，先決定你是在分 script 還是分 region。只分繁簡，就用 zh-Hant 與 zh-Hans；如果香港、台灣、中國大陸頁面因法律、稅務、幣別、交付流程或搜尋詞真的不同，才使用 zh-Hant-HK、zh-Hant-TW、zh-Hans-CN。

第二步，決定是否要進入簡中與大陸市場。大陸市場牽涉的不只是翻譯，還包括 .cn、ICP 備案、本地主機與 Baidu 生態。研究筆記所列資料指出，hreflang 對 Baidu 並非有效機制，因此不能用 Google hreflang 取代中國 SEO 策略。

第三步，不要把繁簡轉換當成本地化。機械轉字可以讓內容可讀，卻未必讓內容被正確搜尋到。香港、台灣與中國大陸在商業詞彙、技術詞彙與搜尋習慣上可能不同，直接轉字有機會鎖定到當地買家不會搜尋的詞。

每頁上線前，最少檢查六件事：self-reference、雙向互指、絕對 URL、目標回 200、canonical 指向自己、同一頁組只有一個 x-default。驗證順序可先看 return tags，再看 self-reference、x-default、canonical，最後才查語言碼細節。

7. 2024–2026 變了什麼

截至研究筆記所列資料，Google 仍支援並使用頁面上的 hreflang tags，但仍視為 hint。真正改變較大的，是驗證工具與監控方式。Search Console 的 International Targeting 報表已於 2022 年 9 月移除，過去可看到的 hreflang 錯誤監控不再存在。2024 年亦有資料指 Google 官方 hreflang validator 已不再提供，官方較多建議站長使用第三方工具。

因此，現行驗證更依賴外部市場工具與自家爬蟲流程，例如 Screaming Frog、Sitebulb、Ahrefs Site Audit 等可爬完整 hreflang graph 的工具；免費工具則可用作單頁或小型 cluster 檢查，例如 reciprocity checker 類工具。這些均屬市場外部工具，不是本文品牌的自家產品或官方服務。

8. 常見錯誤 checklist 與如何驗證

hreflang 最麻煩之處，是錯誤常常靜默失敗。Google 不一定為 hreflang mistakes 產生 crawl error；如果沒有主動爬完整語系關係圖，很容易以為標記已經存在，實際上卻被忽略。

WordPress 多外掛脈絡

WordPress 原生不會自動輸出完整 hreflang，常見做法是選用 WPML、Polylang、TranslatePress、Weglot 等多語外掛。這些是市場常見方案與可整合的外部工具，不是本文品牌提供的自家 offering。實務上要避免兩個外掛同時輸出 hreflang；例如一個 SEO 外掛與一個多語外掛各自輸出不同 URL，就會令 Google 收到互相矛盾的訊號。

TranslatePress 等外掛可透過 filter 客製 hreflang localization；部分站點亦曾遇到 Cloudflare 安全規則阻擋 trp-ajax.php，導致動態翻譯或 AJAX 請求出現 520。這類問題應從外掛設定、Cloudflare rule 與實際 HTTP response 一併檢查，不應只看頁面表面是否有 link tag。

效益數字要保守理解

研究筆記提到 Ahrefs 的 Patrick Stox 曾掃描 374,756 個網域，發現使用 hreflang 的站點中，67% 至少有一項實作問題。另有二手研究提及正確 hreflang 可能帶來非主要市場自然流量提升 47%，或曝光提升 20% 至 300%。這些數字只能作為風險與潛在機會參考，因站而異，並非保證排名、保證流量或保證轉換。

9. 結語與下一步

hreflang 是出海技術基建的一環，不是排名魔法。對繁中、簡中、英文站而言，先把 canonical、語言碼、單一 emission 方式、雙向互指與 x-default 做對，再談內容擴張與流量增長，會比盲目加頁面更穩妥。

多語站亦可能連帶影響稅務、公司架構、收款、資料流與合規安排；相關判斷須按個案處理，宜諮詢專業稅務、法律或合規意見。本文不構成保證節稅、保證排名、保證流量或任何一刀切安排建議。如涉香港公司秘書、信託或公司服務等受規管 TCSP 範疇，相關服務由 Intelligent Services Limited（TCSP 牌照號 TC010349）提供，非 Chan & Chung Consultancy Services Limited 本身。

若你正在規劃繁中、簡中與英文網站，並希望把網站技術、合規節點與出海路線放在同一張檢查表上，可透過 Chan & Chung 服務頁了解顧問支援入口。本文提及的 Screaming Frog、Sitebulb、Ahrefs、WPML、Polylang、TranslatePress、Weglot、Cloudflare、Google Search Console、Baidu 與 ICP 備案，均為外部工具、市場方案或延伸脈絡，並非本公司提供的自家產品或服務。