语言版本的 URL 结构决定抓取起点

多语言站点在抓取上最常见的情况是：默认语言版本被反复抓，其他语言版本长期只有零星几次访问，除了首页之外几乎没有被抓过。这类问题往往不是 hreflang 写错了，而是语言版本本身的发现路径没搭起来。

先看 URL 结构，常见三种做法：子目录、子域名、独立国家域名。从蜘蛛的角度看，这三者的起点并不一样。

• 子目录：与主站共享域名和大部分内链，语言页可以通过首页、导航、面包屑被带到，发现成本最低。
• 子域名：会被当作相对独立的站点处理，主站内链需要明确指向，并且要单独提交 Sitemap、单独确认 robots.txt。
• 独立域名：抓取几乎从零开始，新域名前期能分到的抓取量有限，需要靠外链和站内互链慢慢带。

选哪种结构有业务和合规上的考量，但一旦选定，就要接受对应的抓取成本，不要指望子域名和独立域名能像子目录那样很快被带到。

hreflang 管对应关系，不管抓取入口

hreflang 的作用是告诉搜索引擎这几条 URL 是同一内容的不同语言版本，它本身不负责把蜘蛛带到那个页面。一个语言版本如果没有任何内链指向、也没有出现在 Sitemap 里，即使被别的页面用 hreflang 引用过，它依然可能长期不被抓取。

比较稳的分工是：内链和 Sitemap 负责发现，hreflang 负责对应关系，两者都要做，不能用其中一个替代另一个。另外，hreflang 指向的地址必须是能正常返回内容的页面，指向 404、重定向目标或 noindex 的页面，等于给出错误信号，久而久之这个语言版本的可信度会下降。

语言切换器别只做成一排按钮

不少站点的语言切换是下拉框加 JS 跳转，可点击的地址是 javascript 调用，或者干脆挂在按钮上。用户能用，蜘蛛拿不到。改法很直接：每个语言版本至少有一个真实可爬的链接，href 指向具体地址，可以放在页头、页脚或侧边。如果设计上必须是下拉菜单，也要保证菜单里的条目是链接而不是按钮。

判断标准很简单：把页面 HTML 抓下来、不执行 JS，看能不能从中找到指向其他语言版本的链接。找不到，就等于这条发现路径不存在。

Sitemap 按语言拆开更实用

语言版本多起来之后，把所有 URL 塞进一个 Sitemap 会带来两个问题：文件太大不好维护，以及从数据上看不出哪个语言被抓得多、哪个几乎没被抓。

建议用 sitemap index，按语言或按目录分片。这样在搜索后台或日志里按分片对照，能比较快判断某个语言版本是“没被发现”还是“发现了但抓取少”。同时注意各语言分片只列本语言实际可访问的 URL，不要把带参数的语言切换地址写进去。

子域名和独立域名要单独确认服务器与 robots.txt

子目录方案下，robots.txt 和服务器是同一套，改一次全站生效。子域名和独立域名则是各自独立的：

• 每个域名下都要有自己的 robots.txt，主站的规则不会自动继承。
• 各语言站如果部署在不同服务器或 CDN，要确认响应速度和状态码一致，避免某个语言站长期超时导致抓取减少。
• HTTPS 证书、重定向规则（是否强制 https、是否强制 www）要逐域名检查一遍，避免出现多跳或循环。

这类问题平时不容易浮现，往往是某个语言版本的抓取量突然下降才被注意到，按域名定期巡检一次会省很多事。

用日志确认每个语言目录都被走到

最后是观察环节。把抓取日志按语言目录或子域名分组，看几个指标：每个语言版本被抓的 URL 数量与去重后的数量、抓取集中在哪些目录、有没有整块目录长期没有访问记录。

如果发现某个语言只有首页被抓，通常不是 hreflang 的问题，而是那个语言版本缺少可爬的内链入口。排查顺序建议是：语言切换器是否有真实链接 → 首页与导航是否指向该语言 → 该语言的 Sitemap 是否被正确引用 → 服务器与 robots.txt 是否正常。按这个顺序走，比反复调整 hreflang 有效得多。