先把 URL 结构定下来

多语言、多地区站点在 URL 发现上最容易吃亏的地方，不是蜘蛛不来，而是同一个内容有太多入口，或者根本没有稳定的入口。语言切换靠 cookie、靠脚本渲染、靠一个下拉框，蜘蛛顺着链接走一圈，可能连第二种语言的页面地址都拿不到。

所以在讨论抓取之前，先确认一件事：每个语言版本是否都有一个不依赖用户操作、可点击、可解析的 URL。

三种常见结构，各自的发现特点

• 子目录（example.com/en/、example.com/de/）：继承主域已积累的信号，内链好铺，Sitemap 好拆，中小站点通常优先考虑。
• 子域名（en.example.com）：部署和团队边界清晰，但抓取和权重需要各自积累，robots.txt 与站点地图一般都要单独准备一份。
• 独立域名（example.de）：地区信号最明确，代价是每个域名都要重新走一遍发现流程，维护成本最高。

选哪种没有绝对答案，关键是不要中途反复更换。结构一改，之前被发现的地址就成了另一套入口，过渡期的处理成本往往高于一开始多花的时间。

语言切换入口必须能被抓到

很多站点的语言切换是一个按钮，点击后由脚本改写页面内容，地址栏 URL 不变。这种做法下，蜘蛛通常只能看到默认语言版本，其他语言只能等 Sitemap 或外链把它们带出来，发现节奏完全被动。

更稳妥的做法是把切换做成真实链接：

• 指向对应语言的实际 URL，而不是空 hash 或脚本调用；
• 在首页、主导航或页脚都留出入口；
• 页脚的全站语言列表对发现帮助最大，因为它出现在几乎每个页面上。

hreflang 与 Sitemap 的分工

hreflang 解决的是“这几个地址属于同一内容的不同语言版本”，它本身不负责把地址送进发现队列；Sitemap 解决的是“这些地址存在，可以来看”。两者配合使用效果更好：在一份 Sitemap 里列出各语言版本，并标注彼此的对应关系。

需要注意的是，Sitemap 中的地址应与页面上的 hreflang 标注保持一致，包括协议、主机名和末尾斜杠。对不上时，蜘蛛要多花一轮去判断哪个才是正主。

几个容易踩的坑

• 按 IP 或浏览器语言自动 302 跳转，蜘蛛看到的是跳转而不是内容。
• 只提交默认语言的 Sitemap，其他语言版本靠运气被发现。
• 机器翻译页面批量生成，内容质量低，被抓到也难有稳定的再抓取节奏。
• 多地区共用一套 URL，只换货币和价格，等于给蜘蛛一堆高度相似的入口。

上线后的自查顺序

1. 确认每个语言版本都有独立、稳定、可直达的 URL。
2. 检查 robots.txt 是否误屏蔽了某个语言目录。
3. 确认语言切换是真实链接，且在页脚等全站位置可见。
4. 为每种语言准备对应的 Sitemap，或在同一份 Sitemap 中做 hreflang 标注。
5. 用服务器日志观察各语言目录的抓取量是否均衡，长期为零的目录优先排查入口问题。

多语言站点的 URL 发现，本质上不是技术难题，而是要不要给每个语言版本留一条明确路径的取舍问题。

结构定得越早，后面要处理的过渡和修补就越少。先把路径铺清楚，再谈抓取效率，顺序反了就会一直在收拾残局。