先把 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 發現，本质上不是技術难题，而是要不要给每個語言版本留一條明确路径的取舍問题。

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