当站点 URL 數量到几萬甚至几十萬时，單個 Sitemap 文件已经放不下，通常的做法是拆成多個子文件，再用一個索引文件（sitemapindex）把它們串起来。這一步做得好不好，會直接影响蜘蛛從 Sitemap 這條路径上能發現多少 URL。
先弄清几個硬性邊界
- 單個 Sitemap 文件：URL 數量上限 50000 條，未压缩体积不超過 50MB
- 索引文件：指向的子文件數量上限 50000 個，体积同样有上限
- 索引文件里不能再嵌套索引文件，只能指向普通 Sitemap
- 所有 URL 必须是同一域名（或已在站長平台驗證的同一站点）下的完整绝對地址
- 不支持相對路径，也不支持跨域名混放
這些邊界不是建议值，超出後文件會被判定為無效。
分片按什么维度切
分片方式没有唯一答案，但要考虑一個前提：同一分片里的内容，更新节奏是否一致。
- 按内容類型：文章、商品、分類、标簽頁各成一片，便于單獨排查
- 按更新频率：高频更新的内容單獨一片，可以配合更短的复查周期
- 按語言或地区：多語言站点按目錄拆分，與 hreflang 结构對齐
- 按時間：新增内容按月分片，老内容归档成固定片，减少整体變動
避免按随机平均的方式分片，那样每次更新都會让几乎所有分片的指纹發生變化，反而不利于稳定抓取。
lastmod 要寫得诚實
蜘蛛在安排抓取时會參考 lastmod，但它不會盲信。如果每個分片、每條 URL 的 lastmod 都寫成当天，這個信号很快會被当作噪音處理，參考價值下降。
與其让所有 URL 都顯示刚刚更新，不如只标记真實改動過的頁面。
建议使用带时区的時間格式，例如 2024-06-01T08:30:00+08:00。精度到秒或分钟都可以，但不要出現未来時間。
索引文件放哪里、怎么声明
索引文件一般放在站点根目錄，例如 /sitemap.xml，子文件放在 /sitemap/ 目錄下。声明入口通常有两個：
- robots.txt 中用 Sitemap 行指向索引文件的完整地址
- 站長平台里手動提交
只需要声明索引文件，不必把每個子文件的地址都寫進 robots.txt，蜘蛛會顺着索引文件自己去取子文件。這里有一個常见矛盾：文件提交了，但存放目錄被 Disallow 規則挡住，蜘蛛取不到，等于白交。
取不到分片时的排查顺序
- 用日誌篩選 Sitemap 相關請求，看狀態碼是 200、404 還是 403、500
- 確認服務器對 .xml.gz 的 Content-Type 與 gzip 压缩處理正常
- 检查索引文件里的子文件地址是否寫错、是否誤用了相對路径
- 確認 robots.txt 没有把 sitemap 目錄屏蔽
- 频繁出現 304 属正常現象，說明蜘蛛在按缓存策略做校驗
如果日誌里几乎看不到對子文件的請求，說明索引文件可能没被解析成功，優先回头检查索引文件本身的格式。
Sitemap 不能替代内鏈
Sitemap 解决的是存在哪些 URL，内鏈解决的是這些 URL 有多重要、從哪個入口進入。两者分工不同。新頁面既要有可被抓取的連結入口，也可以出現在 Sitemap 中；只靠 Sitemap 而没有内鏈的頁面，被發現之後往往抓取優先級也不高。
分片數量不必刻意追求精简
有人為了看起来干净，把几十萬 URL 挤進少數几個分片，结果單文件逼近体积上限，响應變慢，反而影响蜘蛛取用。更稳妥的做法是按内容节奏拆分，让每個文件保持在可控大小，通常几萬條以内、压缩後几百 KB 到几 MB 比較合适。
定期用日誌和站長工具核對三件事：索引文件是否可訪問、子文件是否被實际抓取、lastmod 是否真實反映改動。這些基础工作做扎實，Sitemap 在 URL 發現中的價值才稳定。