Sitemap 是 URL 發現里最直接的一條通路，但站点一大，把所有地址塞進一個文件就行不通了。搜尋引擎對單個 Sitemap 文件有明确的條數和体积上限，超過之後要么提交失敗，要么抓取器只讀到前面一部分。稍具規模的站点最後都會走到分片加索引文件這一步，問题只在于怎么拆、怎么维護。
單文件的上限與拆分的理由
目前主流搜尋引擎通用的限制是：單個 Sitemap 最多 50,000 條 URL，解压後不超過 50MB。看着很宽松，但對电商、内容站来说，商品加标簽頁很容易就冲過這條线。拆分不只是為了绕過限制，還有几個實际考虑：
- 文件過大时解析變慢，抓取器可能中途放弃，後面的地址等于没交；
- 一次提交全站地址，很难判断到底哪一批 URL 被處理了；
- 不同栏目更新频率差別大，混在一個文件里，每次都要整份重讀；
- 新開栏目时，無法單獨拿出一批地址做提交和观察。
常见的分片方式
拆分维度没有唯一答案，按自己最想观察的口径来定就行：
- 按内容類型拆：文章、商品、分類、标簽各一個文件；
- 按目錄或频道拆：新闻、商城、帮助中心分別成文件；
- 按更新频率拆：日更内容一個，歷史归档一個；
- 按語言或地区拆：多語言站点按語言分层；
- 结构扁平、没有明顯分類时，按每两萬條左右纯數量切分。
需要提醒的是別拆得太碎。几百個只含几十條地址的小文件，抓取器逐個請求的開销反而更大，後期维護也容易出错。單文件放几千條，是比較舒服的区間。
索引文件本身怎么寫
Sitemap 索引文件里只放各個 Sitemap 的地址，不要再混入普通頁面 URL。几個容易踩的点：
- 地址寫绝對路径，协议和域名补全，不要用相對地址；
- XML 特殊字符要轉义，URL 里的连接符不能直接寫；
- 每個节点可以带一個 lastmod，表示该文件整体的更新時間；
- 文件用 UTF-8 编碼，開头保留 XML 声明；
- 若提交的是压缩文件，索引里引用的也要是压缩後的地址。
索引文件是目錄，不是清單。把頁面 URL 直接寫進索引里，多數抓取器不會把它当成有效入口。
提交之後该看什么
提交 Sitemap 只是告诉搜尋引擎有這批地址，既不保證抓取，更不保證收錄。真正值得盯的是這几項：
- 提交數量與已處理數量的差值，長期悬殊通常說明頁面本身存在問题；
- 各個 Sitemap 的抓取次數，能看出抓取器更愿意走哪個目錄；
- lastmod 是否被參考，頁面内容没變却天天改時間，這個信号會逐渐失效；
- 服務器日誌里 Sitemap 地址的訪問节奏，判断抓取器有没有定期回来取。
它解决不了的問题
Sitemap 只负责把地址交出去，不负责让蜘蛛爬到，也不决定谁排前面。頁面之間的内鏈關系、從入口到詳情頁的点击深度、頁面本身是否值得抓，仍然是抓取路径的主干。一個只被 Sitemap 引用、没有任何内鏈指向的地址，即使被發現，回訪频率通常也很低。
比較稳妥的配合方式是：内鏈保證常規路径通畅，Sitemap 作為新頁面和深层地址的补充通道，服務器保持稳定响應，別在抓取时掉鏈子。三者對齐之後，URL 發現的节奏才會稳下来。