Sitemap 的入门用法很简單：把 URL 一行行列出来，提交到搜尋平台即可。但当站点從几百個 URL 增長到几萬、几十萬個时，單文件方案會迅速失效——文件体积超标、每次更新都要全量重寫、出错後难以定位范围。這时就需要用 Sitemap 索引把 URL 拆成多個分片来管理。
索引文件解决的是什么問题
Sitemap 索引本身不包含頁面 URL，它只列出各個子 Sitemap 的地址。搜尋引擎先讀索引，再按分片逐個抓取。這样做的好處主要有三点：
- 绕開單文件限制：單個 Sitemap 在 URL 數量與文件体积上都有上限，索引可以把總量拆到多個文件里。
- 降低维護成本：只更新發生變化的那一個分片，不必全量重寫。
- 便于定位問题：某個分片返回異常或整体失效时，影响范围可控，排查路径也更清晰。
需要注意的是，索引的嵌套层級通常只支持一层，不要试图用索引去套索引。
分片按什么维度切
分片方式没有标准答案，但應尽量让同一個分片内的 URL 具有相似属性，方便後續核對。
按内容類型切
文章、商品、专题、标簽頁各自成片。不同類型頁面的更新频率和數量級差异很大，混在一起會让 lastmod 失去參考意义。
按更新频率切
高频更新的栏目單獨成片，低频或归档頁面放在另一片。日常只需重寫高频分片，低频分片可以長時間保持稳定，减少無意义的變動。
按語言或站点切
多語言、多子域站点按站点维度切分，每個分片只包含同一站点下的 URL。跨站混放會让抓取范围难以界定，也不利于分站点排查。
分片文件的书寫要点
- 使用绝對地址，包含协议與域名，便于蜘蛛直接解析。
- 每個分片控制在合理規模内，不要把上限顶满，留出增長空間。
- 整個分片的 lastmod 應反映分片内 URL 的真實變化，而不是每次生成都刷新成目前時間。
- 文件較大时啟用 gzip 压缩，减少传輸開销。
- 分片之間的 URL 不要重复，重复會带来額外的規范化判断成本。
维護节奏與核對顺序
索引不是一次生成就不用管了，建议按固定节奏检查：
- 確認索引文件可訪問，返回正常狀態碼，内容為有效 XML。
- 逐個訪問分片地址，检查是否有空分片、失效分片或歷史遗留的舊分片。
- 抽查分片内 URL 能否正常打開，是否存在跳轉、noindex 或已下线的頁面。
- 對照服務器日誌，看各分片是否被周期性讀取，频率是否與预期相符。
- 對長期不被讀取的分片，检查它是否被正确声明在索引中，或者是否已经失去维護價值。
用日誌驗證分片是否有效
日誌是检驗 Sitemap 是否真正發挥作用的直接依據。可以在日誌中篩選對 Sitemap 文件本身的請求，观察索引與各分片的訪問频次、時間間隔，以及是否出現大量 4xx、5xx。如果索引被频繁讀取，而分片長期無人訪問，通常說明索引声明存在問题，或者分片内容長期没有變化，已不再被優先處理。
提交 Sitemap 只是提供一條發現线索，並不等于頁面一定會被抓取或收錄。真正决定抓取量的，仍是頁面價值、内鏈结构與站点整体质量。
Sitemap 索引與分片管理属于基础设施层面的工作，做得好不會带来額外收益，做得差却會在站点規模扩大後不断制造麻烦。把分片划分、字段书寫與日誌核對固定成常規流程，URL 發現這件事會稳定很多。