做多語言或多地区站点时，最容易出問题的往往不是翻译质量，而是“谁是谁”没讲清楚。搜尋引擎需要知道：這几個地址其實是同一内容的不同語言版本，而不是互相抄袭的重复頁面。這個声明主要靠 hreflang、canonical 和語言版本之間的互相連結来完成。配错不會立刻报错，通常表現為某個語言版本長期不被收錄，或者搜尋结果里给出的版本跟用戶所在地不匹配。
先理清三種關系
動手之前，先把站点里的地址分成三類，混在一起是最常见的错誤来源：
- 語言版本：同一份内容的不同語言，例如 /zh/ 與 /en/，它們互為替代版本。
- 地区版本：同一種語言面向不同地区，例如 en-US 與 en-GB，差別可能只在货幣、联系方式、配送說明。
- 真正不同的頁面：主题不一样，只是長得像，這類頁面之間不應该声明替代關系。
hreflang 的几個硬性要求
規則本身不复杂，但容错很低：
- 双向声明：A 頁面指向 B，B 頁面也必须指回 A。只寫一邊等于没寫。
- 自引用：每個頁面要把自己也列進去。少了這一條，整套声明容易整体失效。
- 語言代碼規范：語言用 ISO 639-1 代碼，地区用 ISO 3166-1 Alpha-2，中間用连字符，例如 zh-Hans、en-US、pt-BR。
- 地址可直接訪問：指向 404、重定向或需要登入才能打開的地址，等于在给蜘蛛指错路。
- x-default 兜底：没有明确語言匹配时展示哪個版本，建议指向主語言版本或語言選擇頁，不要让它本身變成一條断鏈。
URL 结构怎么選
三種常见做法各有取舍，重点是一旦定了就別频繁改：
- 子目錄（example.com/en/）：维護最简單，權重集中，适合大多數站点。
- 子域名（en.example.com）：适合不同語言由不同团队獨立运营的情况，但權重是分開积累的。
- 獨立域名：一般用于业務目标差异較大的地区站点，成本和管理复杂度最高。
不建议用參數区分語言，例如 ?lang=en。參數地址容易被当成同一頁面的變体處理，也會给抓取预算增加不必要的负担。
自查清單
按下面的顺序過一遍，通常十分钟能發現大部分問题：
- 列出所有語言版本，確認每個版本都有對應的一套 URL。
- 随机抽 5 到 10 個頁面，检查 hreflang 是否双向、是否包含自引用。
- 检查 x-default 是否指向一個真實可訪問的頁面。
- 確認每個語言版本的 canonical 指向自己，而不是都指向主語言版本。把所有版本的 canonical 都寫成英文頁是高频错誤，等于主動放弃其他語言版本的收錄。
- 检查語言切換器的連結是否正确。切換器是訪客和蜘蛛發現其他版本的主要入口，如果它用的是脚本跳轉或拼错的地址，其他語言版本就很难被找到。
- 看一遍 Sitemap，確認語言版本之間的對應關系與頁面上的声明一致，不要出現两套互相矛盾的說明。
- 抽查渲染後的源代碼，確認 hreflang 不是只在執行时由前端脚本插入。
内容本身也要经得起看
技術声明只是告诉搜尋引擎“這些是替代版本”，並不能决定哪個版本被展示。如果某個語言版本只是机器翻译的产物，讀起来磕磕绊绊，或者产品參數、联系方式還停留在原文，那它在任何场景下都不會有好的表現。
把多語言站点当成几個獨立站点来运营：每個版本都需要自己的内容更新节奏、關鍵詞梳理和内部連結，而不是主站内容的镜像目錄。
上线之後怎么驗證
改完不要只靠感觉。用抓取工具跑一遍代表性地址，观察返回的狀態碼、canonical 和 hreflang 是否與预期一致；再對照服務器日誌，看不同語言版本的蜘蛛訪問频率是否明顯失衡。如果某個版本長期几乎没有抓取记錄，通常說明它在站内缺少入口，或者被某條規則挡住了。
多語言站点的维護成本主要不在搭建阶段，而在後續每一次内容更新时能否让几個版本保持同步。把語言版本的對應關系整理成一張表，新增和下线頁面时都過一次這張表，比事後排查省力得多。