Sitemap 通常被当成一次提交就完事的文件，但真正影响抓取路径的，往往是它的组织方式：是一個大文件，還是索引文件加分片；分片按什么维度切；lastmod 是否可信。這些细节决定了蜘蛛多久来讀一次、讀到哪些 URL，以及後續會不會按你预期的路径繼續抓。

Sitemap 索引文件不是摆设

当 URL 數量超過几萬，或者站点有多個内容類型时，用一個 Sitemap 文件硬扛並不划算。更好的做法是使用 Sitemap 索引文件，指向多個子 Sitemap。這样有几個實际好處：

• 更新时可以只重寫變化的分片，不必全量重新生成；
• 蜘蛛讀取索引文件後，可以按分片逐個抓取，路径更清晰；
• 排查問题时能快速定位是哪個分片没有被抓取。

索引文件本身不需要塞入所有 URL，它只负责告诉蜘蛛“還有哪些 Sitemap 文件可讀”。如果索引文件長期不變，而子文件定期更新，蜘蛛仍可能根據子文件的 lastmod 重新抓取。

分片怎么切更合理

分片维度没有唯一答案，但常见做法有以下几種：

1. 按内容類型切：文章、商品、分類頁各一個分片。不同類型更新频率不同，重訪节奏也可以不同。
2. 按更新時間切：把近期更新的 URL 放在一個分片，歷史归档放在另一個。蜘蛛更容易發現新内容。
3. 按數量切：每個分片控制在几千到几萬條，避免單個文件過大導致讀取超时。

需要注意，分片不是越多越好。分片過多會增加蜘蛛讀取索引和子文件的請求次數，也會让日誌分析變得零散。一般保持每個子文件在 1 萬到 4 萬條之間，按實际更新量調整即可。

lastmod 的准确性比 priority 更重要

很多站点會在每次生成 Sitemap 时，把所有 URL 的 lastmod 都寫成目前時間。這样做會让 lastmod 失去參考價值，蜘蛛多次讀到“全部刚更新”之後，可能降低對该字段的信任。

更稳妥的做法是：只在實际内容發生修改时更新對應 URL 的 lastmod。對于列表頁、篩選頁這類频繁變動的頁面，如果内容没有實质變化，不必强行刷新時間。priority 和 changefreq 字段可以保留，但不必過度纠结，蜘蛛更多是综合判断，並不會只按這两個字段决定抓取顺序。

抓取路径不會只跟着 Sitemap 走

Sitemap 是 URL 發現的通道之一，但它不是抓取路径的全部。蜘蛛進站後，仍然會结合内鏈、入口頁、導航结构和服務器响應来决定下一步。常见的情况是：

• 重要頁面在 Sitemap 里，但没有内鏈指向，蜘蛛可能只抓一次就很少重訪；
• 頁面在 Sitemap 里，但服務器响應慢或经常 5xx，抓取會被推迟；
• 内鏈层級過深，蜘蛛更依赖 Sitemap 才能發現，路径稳定性就差一些。

比較稳的做法是：Sitemap 负责兜底和批量暴露，内鏈负责提供持續路径。两者重合度越高，蜘蛛發現和重訪的路径越不容易断。

用日誌驗證 Sitemap 有没有被讀

提交了 Sitemap 不等于蜘蛛會频繁讀取。可以在服務器日誌里過滤蜘蛛 UA，观察几個点：

• 蜘蛛是否訪問了 Sitemap 索引文件；
• 是否繼續訪問了子 Sitemap 文件，哪些子文件被跳過；
• 從 Sitemap 中出現的 URL 是否在之後進入抓取日誌；
• 讀取 Sitemap 时返回的狀態碼是否是 200，有没有 304 或 5xx。

如果索引文件被讀，但子文件長期没人訪問，可能是子文件太大、响應太慢，或者索引里指向的路径有誤。如果子文件被讀，但對應 URL 很少被抓，就要回到内鏈和服務器稳定性上找原因。

分片更新與服務器负载

Sitemap 文件本身也會消耗服務器资源。分片更新时，尽量只重寫有變化的部分，避免一次性生成超大文件。對于訪問量較大的站点，可以把 Sitemap 放在静態目錄或 CDN 上，减少動態生成带来的压力。

把 Sitemap 当作抓取路径的辅助线，而不是唯一路线。它的價值在于稳定地暴露 URL，並在内鏈之外提供一條可核對的线索。

最後，定期检查 Sitemap 里的 URL 是否仍然返回 200，是否出現大量 301、404 或软 404。保持 Sitemap 干净，比不断往里塞新 URL 更能帮助蜘蛛维持稳定的抓取路径。