Sitemap 是站点主動交给搜尋蜘蛛的一份 URL 清單。頁面不多时，一個文件就能覆盖；当站内 URL 涨到几萬、几十萬條，單文件必然装不下，這时怎么拆、怎么用索引文件串起来，會直接影响蜘蛛讀這份清單的效率和完整度。

先確認几個硬上限

各搜尋平台的規則略有差异，但大方向一致：

• 單個 Sitemap 文件能放的 URL 數量有上限，未压缩体积也有上限。
• 超出上限就得拆成多個子文件，再用一個 Sitemap 索引文件把它們列出来。
• 索引文件本身同样受數量和体积约束，子文件特別多时要再分一层。
• 開啟压缩能明顯减小传輸体积，但响應头與文件名要寫對，別让蜘蛛下载到一個打不開的文件。

具体數字以各家官方文档為准。运营上更值得關注的是：每個文件是不是都能正常打開、返回的狀態碼是不是 200、内容是不是合法的 XML。

按什么维度拆分更顺手

按内容板块拆

商品、文章、分類、标簽各给一個子文件，好處是出問题时定位快。某一類 URL 突然出現大批量抓取異常，看一眼對應的子文件就能把范围缩小。

按更新节奏或 URL 段拆

把高频更新的内容單獨放一個子文件，低频的放另一個。這样观察新增 URL 的發現速度时，資料會更干净，不會因為新老内容混在一起而看不出變化。

不建议按 URL 參數或查询串去拆，那類地址本身就该收口，放進 Sitemap 只會把噪音一並递出去。

哪些 URL 不该出現在清單里

• 會跳轉的地址，也就是 301、302 的源 URL，直接寫最终地址。
• 返回 404、410 的失效頁面。
• 已经设了 noindex 的頁面。
• 被 robots.txt 屏蔽、蜘蛛本来就不能抓的 URL。
• 同一内容有多套地址时，只留 canonical 指向的那一個。

把不该出現的地址放進 Sitemap，等于给蜘蛛派了一批注定失敗的任務，消耗的是抓取時間和服務器资源。

Sitemap 不能替代内鏈

Sitemap 解决的是“蜘蛛知道有這個地址”，但它不负责告诉蜘蛛這個頁面在站内有多重要、從哪條路径能走到。一個只出現在 Sitemap、站内没有任何入口連結的頁面，仍然容易變成孤岛。

把 Sitemap 当作發現通道，把内鏈和導航当作抓取主干道，两者各司其职，別指望其中一方包办。

新頁面上线时，比較稳妥的做法是同时在两個地方露出：站内给它一個自然的入口連結，Sitemap 里同步更新。只做前者，蜘蛛可能晚几天才發現；只做後者，它進来了也未必會認真走。

提交之後该观察什么

• 後台的 Sitemap 相關报告：文件是否讀取成功、识別到多少 URL。
• 服務器日誌：Sitemap 文件本身的訪問是否频繁报错或超时。
• 子文件里的 URL 被實际訪問過的比例，用来判断發現通道是否顺畅。
• 新增 URL 從上线到第一次被抓的時間，作為發現速度的參考。

Sitemap 更新後不需要反复重新提交，让文件内容保持實时准确，比多按几次提交按钮更重要。

几個反复出現的坑

• Sitemap 文件本身被 robots.txt 挡住，或者放在需要登入才能訪問的目錄里。
• 子文件里長期混着已刪除、已改版的舊 URL，没人清理。
• 索引文件引用的子文件用了错誤域名，www 和非 www 混着寫。
• 体积靠压缩達标了，但解压後仍然超限，蜘蛛讀到一半就停。

這些問题的共同点是：不影响頁面本身，只影响蜘蛛拿到清單的效率，所以平时不容易被發現，往往要翻日誌才看得出来。定期抽查一次文件狀態和日誌里的讀取记錄，比事後排查省事得多。