語言版本的 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 有效得多。