Sitemap 在只有几百個 URL 的时候很简單，一個文件交上去就行。但当站点做到几萬、几十萬條頁面时，單份文件的容量和蜘蛛的讀取体驗都會變成問题，這时候通常要拆成多份分片，再用一個索引文件把它們串起来。

為什么單份 Sitemap 不够用

协议對單個 Sitemap 文件有明确上限，超出的部分不會被讀取，等于白交上去：

• URL 數量：一份文件不超過 5 萬條；
• 文件体积：未压缩狀態下不超過 50MB；
• 一份文件出問题（比如生成失敗、返回 500），整份清單的可信度都會受影响。

除此之外，一個体积很大的 XML 文件對蜘蛛来说也是讀取负担：它需要完整下载、解析，才能拿到里面的地址。拆小之後，蜘蛛可以按片讀取，某一片暂时不需要更新时，其他片仍然正常。

索引文件不是清單，是目錄

索引文件（sitemapindex）本身不包含頁面 URL，它只列出各個子 Sitemap 的地址，每個子文件带一個 lastmod。寫的时候注意几点：

• 索引里只放子 Sitemap 的地址，不要把頁面 URL 混進去；
• 子文件必须和索引文件在同一個站点域名下；
• 每個子文件的地址要能直接訪問並返回 200，且内容确實是 XML。

常见的做法是：索引文件固定在 /sitemap.xml 這個位置，子文件放在同一目錄或獨立目錄下，命名上能看出這一片装的是什么内容。

分片的三種常见切法

• 按栏目或内容類型切：文章、商品、专题、帮助文档各自一片，排查問题时定位快；
• 按時間切：当月或当季一片，歷史内容归档成較大的片，更新集中在少數几片上；
• 按數量切：每片 1 萬到 2 萬條，给增長留出余量，避免某天突然触顶。

切法没有标准答案，判断标准是运维和排查是否方便。当一個子文件报错时，能不能一眼看出影响的是哪一块内容。

容易踩的几個坑

• 子文件 404 或返回 HTML：服務器把错誤頁当成 200 返回，蜘蛛拿到一堆 HTML，這片清單就废了；
• 更新不同步：新 URL 加進了子文件，但索引文件里對應的 lastmod 没變，蜘蛛可能認為這一片整体没有變化；
• 体积按未压缩算：gzip 之後看着很小，但限制通常以未压缩体积衡量；
• 塞進不该出現的地址：带篩選參數的列表頁、需要登入的頁面、同一内容的多條規范化地址，都會稀释這份清單的價值。

Sitemap 表達的是這里有這些 URL，並不等于要求蜘蛛必须抓取。它替代不了站内連結结构，只能作為清單的补充。

提交之後怎么判断有没有生效

清單交上去只是第一步，接下来要看真實請求：

1. 日誌里子 Sitemap 文件是否被請求、請求频率如何、返回碼是不是 200；
2. 新 URL 從出現在 Sitemap 到第一次被抓取，中間隔了多久；
3. 抓取是否集中在某几片，另外几片長期無人問津。

如果長期没有變化，先排查 robots.txt 是否誤挡了 Sitemap 目錄，再確認索引文件本身可訪問、服務器没有間歇性超时。清單再規范，也依赖一個能稳定返回内容的服務器。

小结

分片加索引解决的是清單規模變大之後怎么让蜘蛛讀得完、讀得准的問题。把上限记牢、把切法定清楚、让索引和子文件的更新保持同步，比一次性堆一個巨大的 XML 文件要稳妥得多。