站点刚上线时，一份 Sitemap 往往只有几十條 URL，随手寫完就行。等到栏目铺開、商品或文章累积到几千上萬條，同一個文件會變得又大又难维護，蜘蛛讀取时也容易在中間被打断。這时要考虑的不是再寫一份更大的文件，而是把申报结构拆開，用索引文件把它组织起来。
什么規模适合上索引文件
單個 Sitemap 文件有约定俗成的上限：通常不超過 5 萬條 URL、未压缩体积不超過 50MB。實际使用建议留出余量，比如到两三萬條就開始規划拆分。判断依據不只是條數，還包括下面几点：
- 更新节奏差异大：新闻栏目每天在變，产品頁几周不動，混在一起不利于频繁重新生成。
- 由不同系統生成：CMS、商城、论坛各自輸出，硬拼成一個文件容易出错。
- 需要單獨观察：某一類 URL 的抓取情况想分開看，就必须分開申报。
只要满足其中一條，用 Sitemap 索引把多個子文件串起来，申报和排错都會轻松一些。
分片的几種實用切法
- 按目錄切：栏目各自一個文件，與站内结构對齐，出問题时容易定位到具体栏目。
- 按内容類型切：文章、商品、专题、图片或视频各成一路，方便對比不同類型的抓取结果。
- 按更新時間切：活跃内容與沉淀内容分開，活跃文件可以频繁重新生成和提交。
- 按語言或地区切：多語言站点除了 hreflang，申报通道也分開會更清晰。
切法不必追求唯一正确，關键是稳定。分片規則频繁變動，等于让蜘蛛反复重新認识你的申报结构。
文件层面的细节
- 每個子文件都是完整的 urlset 结构，索引文件用 sitemapindex 结构，两者不要混着寫。
- 地址一律用绝對 URL，且指向最终可訪問的規范形態，不要寫成會跳轉的地址。
- 只放值得被發現的頁面，登入頁、站内结果頁、带大量參數的篩選頁不要塞進来。
- lastmod 寫内容真正發生變化的時間，不要每次生成都刷新成目前時間。
- 大文件可以压缩後再提交，但索引文件里要寫压缩後的那份地址。
索引文件要和内鏈、robots 對得上
Sitemap 负责申报，内鏈负责背书，两者的口径要一致。索引里列出的子文件，應该能被 robots.txt 声明到，或者直接提交到站長平台；而子文件里的 URL，最好在站内也有能走到的入口。如果某個分片里的地址几乎都是孤儿頁，申报出去也未必走得通。
把 Sitemap 当作“建议你先看這些”，而不是“必须收錄這些”。它影响的是發現顺序和排队节奏，並不决定最终结果。
几個常见坑
- 分片之間互相引用，或者索引文件指回自己，形成循环。
- 子文件已经返回 404 或 500，却長期留在索引里，拖累整份申报的可信度。
- 提交後從不看資料，不知道哪一片抓得多、哪一片没動静。
- 把生成的 URL 數量当成被抓取、被收錄的數量，忽略了這是两件事。
一套简單的巡检节奏
不必天天盯，固定一個周期做三件事就够：
- 检查每個子文件的可訪問性和狀態碼，確認没有死鏈。
- 核對索引里列出的分片數量與實际生成是否一致，避免漏掉某一類内容。
- 對照服務器日誌，看蜘蛛實际讀到了哪些分片、跳過了哪些，再决定要不要調整切分方式。
URL 規模變大之後，申报结构本身就是一份站内地图。把它整理清楚，不只是方便蜘蛛，也方便你自己在出問题时快速定位到具体是哪一類地址出了状况。