Sitemap 最早是個單文件，几百上千個 URL 放進去就完事。但站点長大以後，單文件會同时出現三個問题：生成一次要跑很久、任何一處小改動都要整份重寫、里面有一條 URL 格式出错可能影响整份文件的解析。索引文件加分片的做法，正是為了解决這類维護問题，而不是為了直接提升抓取量。

什么时候值得拆

• URL 總量已经過萬，單文件生成時間明顯變長。
• 站点包含几類更新节奏完全不同的内容，比如文章、商品、标簽頁。
• 需要按語言或按目錄分別提交，便于定位問题。
• 每次發布只影响少量頁面，却要重新生成整份清單。

行业里普遍遵循的约定是單個 Sitemap 文件不超過 5 萬條 URL、未压缩体积不超過 50MB。這更像是一條安全线：接近上限时，解析和传輸都容易出問题，拆開更稳妥。

索引文件和分片的基本寫法

索引文件本身只做一件事：列出各個分片的地址。它通常包含 loc 和 lastmod 两個字段，指向分片的 XML 地址。真正承载 URL 的是分片文件。

這里有個容易被忽略的点：分片地址要保持稳定。每次生成时用時間戳或哈希做文件名，等于每隔一段時間就換一批新地址，之前积累的抓取记錄就断了。内容可以變，地址尽量不變。

分片地址一變，對蜘蛛来说就是一批新 URL，而不是同一份文件的更新。

分片按什么切

• 按目錄或栏目切：结构清晰，出問题时容易對應到具体频道。
• 按更新频率切：高频更新的内容單獨一個分片，低频内容合在一起。
• 按頁面類型切：文章詳情、列表頁、专题頁分開，便于分別观察。
• 按語言切：多語言站点可以按語言目錄拆分，和 hreflang 的划分保持一致。

單個分片的條數不必卡到上限，一萬到两萬條留出余量，反而更利于生成和校驗。分片數量也不宜無限膨胀，几十個分片還好管理，上千個就會让索引文件本身變得臃肿。

lastmod 该寫什么

lastmod 只有在頁面内容确實變化时才更新。批量刷新所有頁面的時間戳，看起来是“顯得活跃”，實际會让這個字段失去參考價值。格式上使用 W3C 日期格式，整份站点统一时区，避免同一批頁面出現前後矛盾的時間。

它和内鏈的分工

Sitemap 解决的是發現，内鏈解决的是路径。蜘蛛從 Sitemap 拿到 URL 後，仍會结合站内連結判断這個頁面處在什么位置、值不值得经常回来。一個只在 Sitemap 里出現、站内没有任何入口的頁面，抓取频率通常不會高。

• 内鏈能到的頁面，仍然要以内鏈為主，Sitemap 只是补充清單。
• 内鏈到不了的頁面（比如深层的篩選结果、临时活動頁），才需要靠 Sitemap 兜底。
• 參數頁、排序頁、日歷翻頁這類會大量繁殖的 URL，不建议寫進 Sitemap。

几個常见排查点

1. 索引文件或某個分片返回 404，導致整块 URL 丢失。
2. 分片所在目錄被 robots.txt 誤屏蔽。
3. 分片里寫的是會跳轉的舊地址，抓取时多走一跳。
4. XML 语法错誤，比如轉义字符没處理，整份文件解析失敗。
5. 压缩方式與响應头不匹配，蜘蛛拿到的是压缩内容却识別不出類型。

還有一点和服務器稳定性有關：分片最好离线生成後作為静態文件輸出，不要让蜘蛛的請求触發實时生成。抓取高峰时如果每個請求都要查询資料库拼 XML，响應時間會被拖長，连带影响其他頁面的抓取节奏。

怎么判断有没有起作用

訪問日誌里能看到蜘蛛對各分片的抓取记錄：哪些分片被反复讀取、哪些長期没人碰。搜尋後台的 Sitemap 报告只作為參考，真正能說明問题的是日誌里 URL 有没有陆續被訪問。索引文件與分片是一套维護工具，它的價值在于让 URL 清單可管理、可分批更新，而不是提交了就一定會有反馈。