站点刚上线时，一份 Sitemap 通常就能装下全部 URL。等到栏目铺開、商品或文章累积到几千上萬條，單文件里的记錄越来越長，更新一次就要整体重新生成，蜘蛛每次拉到的還可能是一份正在變化中的資料。這时候更省力的做法，是把 Sitemap 拆成若干分片，再用一個索引文件把它們串起来。

索引文件不列 URL，只列分片

Sitemap Index 本身不包含具体地址，它列出的是一批子 Sitemap 的位置和各自的最後修改時間。蜘蛛先讀索引，再按需要去讀對應分片。這样做的直接好處有两点：

• 單個文件体积可控，生成、缓存和传輸都更轻；
• 更新只影响少數分片，lastmod 传達的信号更接近真實情况。

常见的單文件上限是 5 萬條 URL、未压缩 50MB，多數站点遠没到這個量級，但按栏目拆分依然值得做，理由是维護成本，而不是容量限制。

分片按什么维度切分

常见的切法有三種，可以按站点實际情况選一種或混用：

• 按栏目切：商品、文章、专题各一份，出問题时排查范围小，也方便單獨重新生成；
• 按時間切：按發布時間倒序分片，新内容集中在最新分片，歷史分片基本不動；
• 按站点或語言切：多語言、多子站的场景，每套語言一份，避免互相牵扯。

無论怎么切，都要保證同一批 URL 不會同时出現在多個分片里。同一個地址在索引中重复出現，等于让蜘蛛反复處理同一份清單，也容易让抓取配額浪費在無意义的比對上。

lastmod 是最容易寫错的字段

不少站点每次生成 Sitemap 都無條件把 lastmod 更新為目前時間，看起来資料很新，實际让這個字段彻底失去參考價值。更稳妥的做法是：只在頁面内容真的發生變化时更新该條记錄，格式统一使用带时区的完整日期時間，不要一會儿寫日期一會儿寫時間戳。

分片文件自身的 lastmod 同理。如果索引里每個分片的修改時間天天都在變，蜘蛛讀索引的成本就上去了，而分片内容其實没什么變化。

哪些地址不该放進目錄

• 已经返回 404、410 的失效地址；
• 還在做 301、302 跳轉的舊地址，應当寫跳轉後的最终地址；
• 頁面本身带 noindex 的地址，放進 Sitemap 與頁面信号自相矛盾；
• 需要登入、蜘蛛拿不到正文的頁面；
• 篩選、排序、跟踪參數组合出来的地址，這類應通過 URL 規范化收口。

Sitemap 替代不了内鏈

Sitemap 解决的是“告诉蜘蛛這里存在一個地址”，内鏈解决的是“這個地址在站点结构里處在什么位置、有多重要”。只靠 Sitemap 存在、站内没有任何入口指向的頁面，抓取频次通常明顯偏低，更新也不容易被及时發現。合理的做法是让两者互相印證：Sitemap 覆盖全集，内鏈负责把重要頁面串成可走通的路径。

传輸與响應也要照顾到

分片文件動辄几百 KB 到几 MB，開啟 gzip 压缩、設定合理的缓存头，能减少蜘蛛每次重复下载的開销。同时確認 Sitemap 文件本身返回 200 且是 XML 内容類型，不要被安全策略、登入跳轉或 CDN 的缓存規則拦在外面。索引和分片都放在稳定可訪問的路径下，比放在临时目錄更省事。

提交之後看什么

观察服務器日誌里對 Sitemap 文件本身的請求，以及對分片内 URL 的抓取情况。如果索引被反复讀取，但分片很少被訪問，多半是索引中的 lastmod 一直在變，或者分片地址本身不稳定。反過来，如果分片被讀了却迟迟没有對應的頁面抓取，就要回到内鏈和頁面本身的质量上找原因。

把 Sitemap 当成一份需要長期维護的目錄，而不是一次性提交的動作。分片清晰、lastmod 可信、内鏈走得通，這份目錄才真正發挥作用。