多语言站点的收录问题，很多时候不是内容本身不行，而是同一份内容被拆成多个语言版本之后，版本之间的关系没有讲清楚。搜索引擎看到一个页面，需要先判断它是哪个语言、面向哪个地区、和哪些页面属于同一组，然后才决定这个地址值不值得留在索引里。这三件事只要有一件含糊，收录表现就会出现某个语言版本收得很全、另一个语言版本几乎不动的落差。
先确定每个语言版本只有一个规范地址
收录归属混乱的第一来源，是同一语言内容存在多个可访问地址。常见的重复来源有：
- 语言参数形式与语言目录同时可访问，例如 ?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 决定能不能被抓到。三者都清楚，收录归属就不会互相牵扯；任何一环含糊，都会表现为各语言版本收录差距悬殊，而且很难靠调整正文内容解决。