多語言站点的收錄問题，很多时候不是内容本身不行，而是同一份内容被拆成多個語言版本之後，版本之間的關系没有讲清楚。搜尋引擎看到一個頁面，需要先判断它是哪個語言、面向哪個地区、和哪些頁面属于同一组，然後才决定這個地址值不值得留在索引里。這三件事只要有一件含糊，收錄表現就會出現某個語言版本收得很全、另一個語言版本几乎不動的落差。
先确定每個語言版本只有一個規范地址
收錄归属混乱的第一来源，是同一語言内容存在多個可訪問地址。常见的重复来源有：
- 語言參數形式與語言目錄同时可訪問，例如 ?lang=en 與 /en/ 打開的是同一内容
- 子域名和子目錄混用，en.example.com 與 example.com/en 都能正常返回
- 預設語言版本同时暴露在根路径和語言路径下，两套 URL 都返回 200
- 大小寫、末尾斜杠、index.html 等造成的地址變体
處理原則並不复杂：每個語言版本保留一個主地址，其余形式用 301 指向它。不要一邊让某個地址正常訪問、還被内鏈大量指向，一邊用 canonical 去“纠正”它，那等于两套信号互相打架，最後谁生效要看运气。
三種 URL 结构，各有取舍
子目錄（example.com/en/）
權重集中、维護成本低，适合大多數中小站点。缺点是服務器位置單一，本地化深度有限，語言版本的獨立品牌感也弱一些。
子域名（en.example.com）
可以按地区部署、按团队分工维護，但權重相對分散，每個語言版本都要單獨积累信任，新站初期容易出現小语種子域名長期不被抓的情况。
獨立域名（example-en.com）
本地化最彻底，需要處理的事情也最多：跨域 hreflang、跨域 sitemap、跨域内鏈，任何一环漏掉都會让版本之間失去联系。
结构本身没有绝對優劣，真正容易出問题的是中途更換结构。上线一段時間後再從子目錄迁到子域名，等于把已经积累的收錄信号重新洗一遍，通常需要几個月才能回到原有水平。
hreflang 解决的是對應關系，不是收錄
這是最常被誤解的一点。hreflang 表達的是“這几個頁面是同一内容的不同語言版本，請给對應用戶展示合适的那個”，它不保證任何一個版本被收錄，也不阻止某個版本被收錄。一個頁面即使 hreflang 配得完全正确，只要内容薄、加载慢、缺少入口，照样可能長期停在已發現未抓取的狀態。
反過来，如果 hreflang 指向了一個 404、一個被 robots.txt 屏蔽的地址，或者一個會跳轉到別處的 URL，這组關系就是無效的。搜尋引擎會自己尝试判断，判断结果往往和你的预期不一致，表現出来就是收錄归属忽左忽右。
使用 hreflang 之前先確認三件事：目标地址可正常訪問、狀態碼是 200、返回内容的語言與 hreflang 声明的語言一致。三條都做不到，配置再多也起不到作用。
抓取预算不會在各語言版本之間平均分配
多語言站点的常见現象是：主語言版本抓得很勤，小语種版本几周才来一次。原因通常不在内容，而在入口和内鏈的權重不均。如果某個語言版本只放在語言切換器里，而切換器又是 JS 動態渲染、預設不加载，那這個版本對爬虫来说几乎等于不存在。
可以着手調整的方向：
- 把各語言版本的入口直接寫進 HTML 輸出的頁头或頁脚，而不是只藏在切換菜單里
- 每個語言版本有獨立的 sitemap，並在 sitemap 索引里分別列出
- 站内連結尽量指向同語言版本，避免大量跨語言互鏈稀释信号
- 各語言版本的目錄层級保持一致，不要让小语種凭空多出两三层
收錄归属出問题时的自查顺序
- 抽样几個語言版本，確認都能直接訪問、返回 200，頁面語言與声明一致
- 检查同一語言是否存在多個可訪問地址，是否做了 301 收敛
- 检查 hreflang 是否自引用、是否双向對應、是否全部指向可訪問頁面
- 在站点索引报告里按語言目錄分別看覆盖率，判断是全局問题還是某個版本的問题
- 看抓取日誌中各語言版本的抓取频次，区分是没被發現還是發現了不抓
- 核對内鏈和 sitemap，確認每個語言版本都有獨立入口
小结
多語言收錄的核心不是堆砌技術标簽，而是让每個語言版本都能被單獨识別、單獨訪問、單獨被發現。URL 结构决定地址的唯一性，hreflang 决定版本之間的對應關系，内鏈和 sitemap 决定能不能被抓到。三者都清楚，收錄归属就不會互相牵扯；任何一环含糊，都會表現為各語言版本收錄差距悬殊，而且很难靠調整正文内容解决。