--- title: 多語網站 SEO 與 Hreflang 最佳實務 description: 如何用 hreflang、網址結構與在地化選擇設定多語 SEO，避免重複內容與浪費爬取預算。 url: https://mighil.com/work/zh-tw/blog/multilingual-website-seo-hreflang pubDate: 2026-09-25 updated: 2026-09-25 relatedService: website-internationalization --- # 多語網站 SEO 與 Hreflang 最佳實務 第二語言上線感覺像勝利，直到 Search Console 塞滿「錯誤的傳回標記」，Google 仍把英文頁推給德國購物者。多語 SEO 比較不是翻譯字串，而是給每個市場穩定網址、清楚的語言或語系訊號，以及符合當地實際購買的內容。 本指南涵蓋網址結構選擇、hreflang 如何運作（含雙向與 x-default）、語言對比語系、翻譯對比在地化、常見失敗模式、爬取預算、CMS 陷阱、實作情境，以及上線清單。 ## 加任何註解前先選網址結構 Hreflang 只指向網址。若那些網址雜亂、參數化或半遷移，註解救不了專案。Google 關於 [管理多地區與多語網站](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) 的指引列出常見模式。你選一個主要模式並堅持。 | 模式 | 範例 | 優勢 | 成本 | | --- | --- | --- | --- | | ccTLD | `example.de`、`example.fr` | 強國家訊號、在地信任 | 分站、更多營運、連結權益拆分 | | 子網域 | `de.example.com` | 清楚分離、彈性主機 | 國家訊號弱於 ccTLD | | 子目錄 | `example.com/de/` | 單一網域、共享權威、較簡 CMS | 國家訊號更仰賴內容與 hreflang | 多數仍在單一品牌網域累積權威的產品與內容站，子目錄勝出。ccTLD 在法律實體、定價或合規真因國家而異、且你能為每站配置人力時合理。子網域居中，例如需要不同堆疊（面向中國的來源）又不想買每個 TLD。 避免語言當查詢字串（`?lang=de`）。那些網址易重複、難分享、分析彆扭。註解正確時 Google 仍能理解，但活在參數語系的營運者，通常在篩選與活動碰撞時後悔。 把選定模式寫在工程師與譯者都讀的一處。之後從 `/de/` 改到 `de.example.com` 代表完整轉址地圖與 hreflang 重寫。遷移稅就是網址決策該在第一個翻譯頁上線前的原因。 ![多語站三種網址模式：ccTLD、子網域與子目錄](/work/assets/blog/hreflang-01-url-structures.webp) *圖 1：同一品牌並排的 ccTLD、子網域與子目錄配置。* ## Hreflang 實際如何運作 [Hreflang](https://developers.google.com/search/docs/specialty/international/localized-versions) 告訴 Google，哪個網址是給定語言或語言－地區組合的預期版本。它本身不創造排名。它幫 Google 在幾個近乎相符頁存在時選對替代，讓德文使用者在該網址是英文頁有效替代時，更可能看到德文網址。 你可用 Google 文件記載的三種方式宣告替代： 1. 頁面 `` 中的 HTML `` 2. 非 HTML 檔（PDF 等）的 HTTP 標頭 3. 大型型錄的 XML sitemap 註解 多數行銷站用 HTML 標籤或 sitemap 條目。大型電商型錄常偏好 sitemap，讓範本保持精薄。對一組網址選一種主要方法並保持一致。同一組頁部分 HTML、部分 sitemap 註解是常見漂移來源。 代碼遵循 Google 接受的 BCP 47 風格值：語言代碼如 `en` 或 `de`，可選加地區如 `en-GB` 或 `pt-BR`。用 ISO 639-1 語言代碼；需要地區時用 ISO 3166-1 Alpha 2 國家代碼。不要發明像用 `uk` 代表英國英文的簡寫（通常選 `en-GB`）。不要只用地區代碼。 集合中每一頁應列出每個替代，包括自我參照。若 `https://example.com/pricing/` 是英文、`https://example.com/de/pricing/` 是德文，兩頁（或其 sitemap 列）都需要指向最終、可索引網址的 `en` 與 `de` 條目。 ### 替代之間的雙向確認 Google 在地化版本文件明確寫註解必須從另一側確認。若頁 A 把頁 B 標為 `de`，頁 B 必須把頁 A 標回 `en`（或 A 的語言）。單向連結對該關係被忽略。 雙向安靜失敗在：CMS 只在「主要」語系產生標籤、譯者發新語言卻未更新舊頁，或 CDN 快取舊 head 而線上頁已搬。Search Console 的國際指定／hreflang 報告（若你的資源有）與擷取 `link[rel=alternate][hreflang]` 的爬取，都比用眼睛看 HTML 更快抓到。 ![英文與德文頁之間的雙向 hreflang 箭頭](/work/assets/blog/hreflang-02-reciprocal.webp) *圖 2：每個替代必須指回。單向箭頭不算已確認配對。* ## x-default 與未匹配訪客 `x-default` 標記當沒有其他 hreflang 值符合使用者語言或地區設定時，你想要的網址。Google 在同一份 [在地化版本](https://developers.google.com/search/docs/specialty/international/localized-versions) 文件中把它描述為未匹配語言的後備。 典型用途： - 語言選擇器或全球入口頁 - 你沒另開選擇器時的主要英文（或其他樞紐）網址 - 謹慎選定的「世界其餘」店面 `x-default` 不是「給說英文的人的頁」。英文仍需要自己的 `hreflang="en"`（或 `en-US`、`en-GB` 等）。誠實時 `x-default` 可與 `en` 指向同一網址。也可指向可索引且有用的選擇器。它不該指向軟 404、永不落定的 geo-IP 轉址中介，或隨機部落格文。 若在使用者（或 Googlebot）看到穩定網址前就依 IP 自動轉址，你同時對抗可用性與爬取。Google 多地區指引警告不要只靠 IP 顯示內容。偏好每個語系穩定網址加可見語言切換器，讓 hreflang 做匹配工作。 ![語言不符合 en、de 或 fr 時，x-default 作為後備](/work/assets/blog/hreflang-03-x-default.webp) *圖 3：x-default 接住語言在註解集合外的訪客。* ## 語言代碼對比語系代碼 `de` 代表德文，不論國家。`de-DE` 代表德國使用的德文。`de-AT` 代表奧地利使用的德文。當貨幣、運送、法律文案或拼寫分歧時，意圖不同。 當一個網址誠實服務該語言所有說話者時，用僅語言代碼。當頁面因市場而異、即使語言字串看起來相同時，用語言－地區代碼。給全球讀者的單一英文頁常是 `en` 加 `x-default`。價格與拼寫不同的英國與美國店面通常是 `en-GB` 與 `en-US`，各有自己的網址。 不要建立只差國旗圖示與 CDN 邊緣的 `en-US` 與 `en-GB` 重複。Hreflang 無法發明有意義差異。若頁面近乎相同，合併或正確在地化。 簡繁中文需要小心。對中國大陸受眾的簡體與對台灣或香港的繁體是不同閱讀體驗。偏好不同網址與精確代碼（`zh-Hans`、`zh-Hant`，或你堆疊一致支援的地區形式），而不是一個混用字體的 `zh` 頁。無論選什麼，在 HTML、sitemap 與語言切換器保持同一代碼族。 ![僅語言標籤對比語言－地區語系標籤](/work/assets/blog/hreflang-04-lang-vs-locale.webp) *圖 4：語言代碼廣泛涵蓋說話者。內容真的不同時，語系代碼釘住市場。* ## 翻譯止於何處、在地化起於何處 機器或人工翻譯只換詞，卻留下美元、美國運送矩陣、美國案例與美國法律頁尾，即使 hreflang 完美也會表現不佳。在地化改變商業表面。貨幣、稅顯示、付款方式、支援時段、信任訊號、例子與法規文字都需要市場遍歷。 對 SEO 而言，在地化也包括： - 依該語言人們如何搜尋撰寫的 title 與 meta description，而非英文關鍵字的逐字借譯 - 有對等時，內部連結留在同語言樞紐內 - 重要處有在地 UI 或說明的圖片與截圖 - 跳過仍被註解為完整替代的稀薄「即將推出」語系殼層 若市場未就緒，在頁面真正對等前不要放進 hreflang。把佔位標為 `fr` 會教 Google 法文替代很弱。 > **最佳實務：** 先交付較少、商業上完整的語系，再在 sitemap 灑十個半翻譯資料夾。 ![超越原文翻譯的在地化層：貨幣、法律、例子、搜尋措辭](/work/assets/blog/hreflang-05-localize.webp) *圖 5：超越換詞。貨幣、證明點與法律表面也要市場遍歷。* ## 常見 hreflang 與國際 SEO 失敗 這些幾乎出現在每次多語爬取審查。 **雙向壞掉。** 新語系上線標籤列出舊語言，舊語言從未更新。用單一事實來源（建置步驟或 CMS 欄位）在每個語系重新產生完整替代集來修。 **錯誤代碼。** `eng`、`uk`、`zh-CN` 與 `zh-Hans` 不一致混用，或該用語言處用了地區代碼。對照你在網址文件標準化的代碼清單驗證。 **註解非正規或不可索引網址。** Hreflang 必須指向最終偏好網址。若德文頁 canonical 到英文，或回 noindex，替代集在說謊。先修 canonical 與索引。 **HTTP 與 HTTPS 混用，或 www 與非 www 混用。** 替代集中每個 `href` 應使用你選為正規的同一主機與協定。 **部分涵蓋。** 只有首頁有 hreflang，產品範本沒有。或只有 sitemap 有條目而 HTML 矛盾。端到端涵蓋賺流量的範本。 **語言切換器製造參數重複。** 切換器在 `/de/` 上加 `?currency=EUR` 而無 canonical 紀律，會倍增近重複並浪費爬取。 **自動轉址迴圈。** 偵測語言、302 到另一資料夾，另一規則再把機器人送走。給 Googlebot 在穩定語系網址上的 200。 > **警告：** Hreflang 錯誤很少拋可見頁面錯誤。使用者仍可瀏覽，而 Google 忽略替代地圖。把 Search Console 與爬取差異當監控面。 ![常見失敗圖示：單向標籤、錯誤代碼、noindex 目標、混用主機](/work/assets/blog/hreflang-06-common-failures.webp) *圖 6：常見斷裂是雙向、代碼、可索引性與主機不一致。* ## 多語站的爬取預算 每個新語系倍增網址數。頁面獨特且有連結時可以。當你複製稀薄範本、每種語言的分面篩選，以及沒人想翻譯的標籤彙整時就受傷。 爬取預算不是神秘分數。實務上你在意 Googlebot 把時間花在營收網址還是垃圾。多語垃圾長這樣： - 翻譯篩選組合製造上千近乎空白列表 - 每種語言稀薄文章的分頁彙整 - 頁尾仍連結的測試或預覽語系 - CMS 發布失敗後 404 或軟 404 的替代 每個語系用與單語稽核相同方式合併或 noindex 低價值表面。Sitemap 限於屬於替代地圖的正規、200、可索引網址。加語言時只加你能維護的範本。 內部連結應偏好同語系路徑。德文文章只連到英文分類樞紐，會強迫額外跳轉並稀釋語言叢集。 ![爬取路徑偏好營收語系網址而非稀薄翻譯篩選](/work/assets/blog/hreflang-07-crawl-budget.webp) *圖 7：更多語言代表更多網址。偏好商業範本的爬取，而非翻譯篩選雜訊。* ## CMS 與外掛陷阱 WordPress、Shopify、Webflow、自訂 Next.js 應用與企業 CMS 以不同方式長出 hreflang 錯誤。底下模式相同：渲染頁面的系統不是唯一自認擁有替代的系統。 留意： - 兩個外掛都印 `link rel="alternate"` 且不一致 - Headless CMS 存語系 slug，前端在正式環境以不同方式改寫路徑 - Sitemap 外掛列每個語系，HTML 標籤只列子集 - 「Hreflang」模組省略自我參照 - 複製到新語系工作流複製了 `noindex` 或測試站 canonical - CDN 或反向代理層給機器人與使用者不同 HTML（刻意時少見，意外時混亂） 對 [網站國際化](/work/website-internationalization) 工作，把 hreflang 當每次重大變更都要再驗證的上線清單項。尤其 WordPress 多語堆疊，每次重大外掛或佈景更新後，驗證每個語系營收頁的線上 HTML。 若在應用中產生標籤，加 CI 檢查或爬取斷言，計算每個範本預期替代數。手動抽樣會漏第十種語言。 ![CMS 層在 hreflang 輸出上衝突：佈景、外掛、sitemap、CDN](/work/assets/blog/hreflang-08-cms-pitfalls.webp) *圖 8：佈景、外掛、sitemap 與 CDN HTML 各可能發出不同替代故事。* ## 撐過上線日的實作路徑 耐久上線長這樣。 1. **凍結網址模式**與商業就緒的語系列表。 2. **對應對等**於試算表或資料庫。每列一個內容單位。欄是語系網址。空格表示「尚無替代」（填滿前省略 hreflang）。 3. **選擇 HTML、HTTP 或 sitemap**作為該範本類別的事實來源。 4. **產生含自我參照的雙向標籤**，並在有刻意後備處含 `x-default`。 5. **對齊 canonical**，讓每個應索引的語系網址自我正規化。 6. **更新語言切換器**，讓每個語系連到對應對等，而非猜首頁。 7. **提交或重新整理 sitemap**於你管理的每個 Search Console 資源。 8. **部署後爬取並比對。** 若營收範本雙向或代碼驗證失敗，讓釋出失敗。 9. **監控** Search Console 的 hreflang 問題，以及成效報告中意外的國家或語言落地模式。 Google 的 [在地化頁面版本](https://developers.google.com/search/docs/specialty/international/localized-versions) 文件是標籤語法與雙向的規範參考。第三方驗證器有幫助，官方規則仍決定 Google 接受什麼。 ![從凍結網址到爬取驗證的實作步驟](/work/assets/blog/hreflang-09-implementation.webp) *圖 9：先對應對等、產生雙向標籤，再以部署後爬取驗證。* ## SaaS 站加德文與法文的實作情境 Acme 在 `https://www.acme.example/` 出貨 B2B 分析產品，部落格與定價為英文。行銷要德文與法文做歐盟擴張。工程偏好單一網域。他們選子目錄：`/de/` 與 `/fr/`。 他們 **不** 翻譯每個舊部落格標籤彙整。他們在地化首頁、定價、產品概覽、文件入口，以及仍帶來管線的二十篇文章。法務寫歐盟就緒隱私附錄。定價在需要處顯示歐元與 VAT 註記。案例換成他們真有授權的歐盟 logo。 對等地圖（簡化）： | 單位 | en | de | fr | | --- | --- | --- | --- | | 首頁 | `/` | `/de/` | `/fr/` | | 定價 | `/pricing/` | `/de/pricing/` | `/fr/pricing/` | | 產品 | `/product/` | `/de/product/` | `/fr/product/` | 那六個網址各自（含自我）發出 `en`、`de`、`fr`，以及指向英文首頁或他們決定保持可索引的小地區選擇器的 `x-default`。只存在英文的部落格文省略 `de`／`fr` 直到翻譯。他們從不把德文首頁指到法文定價網址。 上線後第一週，爬取發現英文定價仍缺新替代，因為快取層送了舊 head。他們清除、再爬，確認雙向。Search Console 處理後停止在那些網址回報傳回標記錯誤。 他們把成功衡量為德文與法文查詢落到 `/de/` 與 `/fr/` 營收頁。僅已索引網址數在此是弱成功指標。 ![SaaS 站加 /de/ 與 /fr/，對應首頁、定價與產品網址](/work/assets/blog/hreflang-10-worked-scenario.webp) *圖 10：Acme 對應少數完整對等、交付雙向標籤，並跳過稀薄彙整翻譯。* ## 多語 SEO 清單 專案說完成前用這份。 - [ ] 一份文件化、一致使用的網址模式（ccTLD、子網域或子目錄） - [ ] 只有商業就緒語系上線並註解 - [ ] 每個註解網址回 200、可索引，且應排名時自我正規化 - [ ] Hreflang 代碼符合你的語言 vs 語系政策（`de` vs `de-DE` 等） - [ ] 每個成員頁或 sitemap 列有完整替代集，含自我參照 - [ ] 集合間雙向確認 - [ ] `x-default` 指向刻意後備 - [ ] 語言切換器連到真實對等，不產生參數重複 - [ ] Sitemap 只列你要爬的正規語系網址 - [ ] 稀薄翻譯篩選、標籤與測試語系在替代地圖外 - [ ] 部署後爬取驗證營收範本標籤 - [ ] 你管理的主機已更新 Search Console 資源與 sitemap ![多語 SEO 與 hreflang 上線就緒核對夾板](/work/assets/blog/hreflang-11-checklist.webp) *圖 11：上線就緒涵蓋網址、代碼、雙向、可索引性與部署後驗證。* ## 常見問題 ### 只有一種語言需要 hreflang 嗎？ 不需要。Hreflang 用於同一內容的替代語言或語系版本。單語站應專注乾淨 canonical 與爬取存取。加指向無處有用的裝飾 hreflang 只製造監控雜訊。 ### Hreflang 能單獨修復重複內容嗎？ 它幫 Google 在有效版本間選對替代。它不取代 canonical 紀律，也不會救稀薄複製頁。先修重複與品質，再註解真實對等。 ### 每篇部落格都該有每種語言嗎？ 只有你會維護它們時。部分涵蓋沒問題。註解該單位存在的語言，其餘等上線再放進替代清單。 ### 國際 SEO 永遠 ccTLD 比較好嗎？ 不。ccTLD 是強國家訊號，對在地使用者常也是信任訊號，但營運成本更高，除非你投資每個資產否則拆分權威。許多全球品牌用子目錄加正確 hreflang 表現良好。從法律、主機與資源限制選擇，而不是論壇串的經驗法則。 ### 大型型錄該把 hreflang 放哪？ 有數萬 SKU 時 XML sitemap 較好擴展。保持 sitemap 條目與正規產品網址同步。若堆疊也印 head 標籤就抽樣 HTML，並移除衝突。 ### Hreflang 與 content-language meta 標籤有何不同？ Hreflang 為 Google 搜尋對應語言與地區的替代網址。`content-language` meta 標籤不是該地圖的替代。替代請遵循 Google 的 [在地化版本](https://developers.google.com/search/docs/specialty/international/localized-versions) 機制。 ## 結語 多語 SEO 在網址穩定、語系是真實產品、hreflang 是那些網址的雙向地圖時才站得住。掙扎的團隊通常先註解後在地化，或讓外掛在第三語言上線後發出無人再驗證的標籤。 若你在規劃語系上線或清理既有替代地圖，可[透過聯絡表單](https://form.ms/ja5zic)聯繫我。