Sitemap 是给搜尋蜘蛛的一份候選清單，但它的作用不止于列 URL。当站点規模上萬以後，單個文件很快就會撞上协议規定的上限，分片和索引文件就成了必须處理的结构問题。组织得好，抓取能顺着清單較快铺開；组织得乱，蜘蛛拿到的是過期、重复、甚至指向错誤地址的入口，反而拖慢 URL 發現。
單文件的硬性上限
协议對 Sitemap 文件有明确约束，超過就得切分：
- 單個文件最多 50000 條 URL；
- 未压缩体积不超過 50MB；
- 只能是同一個域名（含协议與端口）下的 URL；
- 建议 gzip 压缩後传輸，减少带宽與讀取耗时。
很多站点不是败在數量上，而是败在体积上：一頁塞進几萬條带參數的長 URL，未压缩体积先超了，蜘蛛讀到一半就中断。
索引文件：只列分片，不列内容
Sitemap 索引文件本身不包含具体 URL，它只指向其他 Sitemap 文件，最多 50000 個分片，同样受 50MB 限制。常见错誤是把索引文件当普通 Sitemap 提交，里面混寫了頁面地址，结果蜘蛛按分片規則解析失敗，整份清單被跳過。
分片粒度怎么切
切分方式直接影响回訪效率。比較實用的做法是按更新节奏分组，而不是按數量硬切：
- 高频更新的栏目單獨成片，蜘蛛回訪时只需要重新拉這一小份；
- 歷史归档、低频内容合並成大片，控制文件數量；
- 内容類型差异大的（商品、文章、标簽頁）分開，便于單獨观察抓取效果；
- 分頁與篩選參數頁通常不该出現在清單里，避免稀释清單的有效性。
提交渠道與發現路径
索引文件要被發現，需要顯式入口。robots.txt 里的 Sitemap 指令是最稳定的一條，寫完整的绝對地址，包含协议。後台提交属于辅助手段，不能替代 robots.txt 中的声明。過去流行的主動 ping 接口已逐步關閉，不建议再把它当作推動抓取的主要方式。
清單只是候選，不是抓取保證。蜘蛛仍會按自身策略决定抓什么、抓多少，提交後没有任何數量上的承诺。
核對顺序：提交與抓取能不能對上
發現抓取量長期低于预期时，按下面的顺序排查，能省掉很多来回：
- 直接訪問索引文件地址，確認返回 200 且内容是 XML；
- 確認索引中的每個分片地址都能打開，没有 404、301 或登入跳轉；
- 抽查分片内的 URL，狀態碼正常、canonical 指向自身、不存在重复；
- 核對 robots.txt 是否誤屏蔽了 Sitemap 路径或其中涉及的目錄；
- 對比分片條數與站点實际可索引頁面數，差距過大說明分片内容陈舊；
- 观察日誌中蜘蛛對 Sitemap 文件的抓取频率，長期不抓說明入口没被识別。
三類常见偏差
lastmod 全站同一天。批量生成时把時間戳统一寫成目前時間，蜘蛛很快會判定该字段不可信，之後即使内容真的更新，也不再提高回訪優先級。
分片内容與實际頁面脱节。頁面已下线、改版換了路径，但分片還在推舊地址，蜘蛛拿到的是無效入口，等于用抓取投入去換 404。
索引层級套太多。索引指向索引、再指向分片，解析鏈路變長，出错概率上升。一层索引加一层分片基本够用。
把 Sitemap 当作需要長期维護的结构，而不是上线时生成一次的产物。分片跟着内容节奏走，索引保持简洁，入口声明放在 robots.txt 里，剩下的交给抓取策略本身去消化。