多语言页面成功上线之后, 域名的整体收录进程速度出现了明显减慢的状况, 并且有一部分特定的语言表达版本会长期处于那种被搜索系统接收了内容但还没将其正式存入自身数据库的状态, 这种困境是当前在多语言网站进行日常运营管理工作时最为经常遭遇的收录障碍环节。
究其根本原因来讲, 并不是说带有多种语言属性的网站设计本身存在什么问题, 而是因为处理统一资源定位符的具体结构布局、指定不同语言版本对应关系的特定标签标注工作, 以及向搜索引擎提交站点地图文件的具体方式这三项关键操作要素当中, 确实存在着某些不当的配置错误或者疏漏之处, 所以才导致了上述问题的发生。
当三项配置全部设置得都对的时候, 那么多语言页面就能够开始积累加速域名的权威度了。只要是有任意一项出现了错误的话, 搜索引擎就会把这个语言的版本给判定为是重复的内容。并且还会压制对它的收录情况。
影响收录的三个核心机制：
1. URL架构: 如果采用子目录方案, 比如在example.com/加上/en/或者/ja/这样的地址结构, 那么各个语言版本就和主站共享权重的表现, 这时候被搜索引擎收录的速度会更快一些；而如果采用子域名方案, 像en.example.com这种形式, 那每一个语言版本都需要重新慢慢积累爬虫的信任关系, 在最初阶段, 其收录所需的时间周期基本上会是主站的2至3倍左右。
2. 这个Hreflang标签要是缺失了, 又或者指向错误, 就会导致搜索引擎无法建立起不同语言版本之间的对应关系。在这种情况下, 就会触发重复内容的去重机制。于是, 部分语言版本会直接被跳过, 从而导致不被收录。
3. Sitemap覆盖: 对于那些没有被包含在XML Sitemap中的语言版本, 主要依赖于爬虫去自动发现它们。所以, 网站的收录周期就从原来的以天来计算, 一下子被拉长到了以月来计算的程度。
实操策略（按优先级排序）：
架构选择: 对于语言种类不超过五种的多语言网站, 建议优先选择使用子目录进行搭建。这样做的好处是能够集中网站的权重, 同时也可以降低后期的维护成本。
如果是属于集团规模的多语言业务, 涉及的语种超过十种, 并且拥有各自独立的品牌形象，那么可以考虑采用子域名的方案。只是需要注意的一点是, 必须为每一个设置好的子域名单独配置相对应的Sitemap文件。
需要去做hreflang的配置工作, 具体的做法是在每一个语言版本的页面的头部区域里面, 去把全部都有的语言版本都给声明出来, 这里面也包括了它自己指向自己的那个情况, 它的编写格式是。, 所有指向URL必须返回200状态码。
提交节奏: 每当增加了新的语言版本之后, 必须在48小时之内更新XML Sitemap文件, 然后通过Search Console这个工具去手动提交索引请求。
站长可以借由gname.xin里的多语言收录监控模块, 来实时查看各个不同语言版本的抓取状态、还有索引覆盖率是多少, 以及异常页面上面到底有哪些内容, 这样做就可以保证不会发生遗漏的情况。
高频踩坑点：
因为只是对语言进行了代码标注, 没有对地区进行标注, 这就好比只写了en-US却遗漏了en-GB这种情况, 进而就导致了同一个语言在不同地区的版本之间发生了冲突。
各个语言版本之间存在大段的机器翻译留下的痕迹, 从而触发了针对低质量重复内容的那个判定规则。
各个语言版本的页面相互之间的内部链接设置得并不完整, 这就产生了被描述为“孤岛”情况的页面结构, 导致网络爬虫没法仅仅依靠网站内部的链接去顺利访问到这类型的页面。
结论: 多语言网页, 它不会天然地伤害域名的收录量。真正拖慢收录速度的, 是架构混乱, 还有Hearthlang标签缺漏, 以及Sitemap没有覆盖全面这些情况。按照上面说的那些策略, 你去逐项核查, 然后逐一修正, 这样就可以在多语言扩展的时候, 还能保持主域名的收录效率。
