站点只有几百個 URL 时，一個 sitemap.xml 寫到尾就够了。当 URL 涨到几萬、几十萬，單文件會撞上协议的硬限制，這时候需要的是 Sitemap 索引文件（sitemapindex），把 URL 拆成若干份子 Sitemap 分批交给蜘蛛。

單個 Sitemap 的两條硬上限

按主流搜尋引擎的 Sitemap 协议约定，單個 Sitemap 文件有两個限制：

• 最多 50,000 條 URL；
• 解压後体积不超過 50MB（未压缩計算）。

容易踩的坑是：超限不是“只收錄前 5 萬條”，而是整份文件被判定為無效。一條 URL 都讀不到，而且你在後台看到的往往只是一個狀態标记，不會告诉你具体哪一行越界。提交前用脚本數一遍行數和字节數，比事後排查省事得多。

如果提交 .gz 压缩版本，体积按解压後的内容算，压缩只是省传輸带宽，不會放宽上限。

Sitemap 索引文件怎么组织

索引文件本身不列具体 URL，只列子 Sitemap 的地址和各自的 lastmod。它的作用是让蜘蛛知道“這個站的地图有几張、每張什么时候更新過”。

關键决策是按什么维度切分。常见的几種：

• 按内容類型：商品、文章、問答各一份，便于分別观察抓取情况；
• 按栏目或目錄：與站点自身的 URL 结构對齐，好维護；
• 按更新频率：高频更新的内容和一年不動的内容分開，這是最實用的一種；
• 按數量均分：纯粹為了让每份不超限，最省事但最难排查。

不管選哪種，切分维度要稳定。同一個 URL 不要這周在第一份、下周跑到第三份，否則子 Sitemap 的 lastmod 會频繁變動，管理員和蜘蛛都要多做無用功。

分片粒度：太细和太粗都有代價

分得太细，蜘蛛要先讀索引、再逐個請求子文件，光是請求開销就翻了几倍；一個站有 300 個子 Sitemap，蜘蛛每天爬一圈索引本身就要消耗不少抓取次數。

分得太粗，單份文件里混着高频和低频内容，每次小改動都會让整份文件的 lastmod 變化，蜘蛛無法判断到底哪部分更新了。

一個可用的折中：按更新频率切分，让每小时更新的内容和每月更新的内容各自成片；每份控制在几千到几萬條 URL，体积留出余量。這样 lastmod 才有区分度，蜘蛛复查的节奏也更贴近内容實际的變化速度。

Sitemap 是候選清單，不是入口

需要反复提醒的一点：Sitemap 里的 URL 只是候選。蜘蛛讀到它，只代表知道了這個地址存在，是否抓取、什么时候抓，仍然取决于内鏈入口、頁面權重和抓取预算。

如果某個 URL 只出現在 Sitemap 里、站内没有任何連結指向它，它大概率會長期躺在队列里不動。Sitemap 與内鏈是两套並行的發現路径，前者负责“告知”，後者负责“證明它值得抓”。

分片常见的失效原因

• 索引文件里又嵌了索引文件，层級错了；
• 子 Sitemap 返回 301、403 或 5xx，蜘蛛拿到的是無效响應；
• robots.txt 里誤屏蔽了子 Sitemap 所在目錄，蜘蛛连文件都取不到；
• 所有分片的 lastmod 寫成同一個時間，等于没有信号；
• Sitemap 里塞進了 404、重定向或已下线的 URL，白占額度；
• URL 的大小寫、轉义寫法與站内實际連結不一致，同一頁面被当成两個地址。

怎么驗證分片是否真的被讀到了

提交只是第一步，驗證靠日誌：

1. 在服務器日誌里筛出蜘蛛對 sitemap 相關路径的請求，看索引文件和子文件的請求频率是否正常；
2. 統計每個子 Sitemap 被請求的比例，找出長期没人碰的那几份；
3. 對没人碰的分片逐一检查：是否被 robots 挡了、是否返回非 200、里面的 URL 是不是早已失效；
4. 观察服務器在蜘蛛集中抓取 Sitemap 时段的响應，5xx 會让它暂时降低對這批文件的兴趣。

把 Sitemap 当成一張地图：地图画得再全，路還是得靠内鏈和服務器响應真正铺出来。

几條實践建议

• 先數 URL 總量再决定是否分片，不要等超限了才動手；
• 分片维度選好後保持稳定，不要频繁重组；
• 高频内容單獨成片，让 lastmod 有實际含义；
• 定期清理 Sitemap 里的失效 URL，保持清單干净；
• Sitemap 之外，同步维護好内鏈和入口頁，两件事要一起做。