Sitemap 本身不复杂，难的是站点規模上来之後怎么维護。一個栏目几百個 URL 时，随便生成一個 XML 文件就够用；当 URL 數量到了几萬甚至几十萬，單個文件迟早會撞上协议上限，抓取入口就需要重新设計一遍。

先確認單文件的上限

Sitemap 协议對單個文件有明确限制，超出部分不會被處理：

• 一個文件最多 50,000 條 URL；
• 未压缩狀態下不超過 50MB；
• 一個文件里的 URL 應属于同一站点，跨站需要分開。

這两個數字是硬约束，不是「差不多就行」。超過之後，文件可能被截断讀取，後面的 URL 就等于没提交。

索引文件是给蜘蛛的目錄

URL 數量超過上限时，标准做法是拆成多個子 Sitemap，再用一個 Sitemap 索引文件（sitemap index）把它們列出来。索引文件里每一條只寫子文件的位置和最後修改時間，本身不包含具体 URL。

可以把它理解成一份目錄：蜘蛛先讀索引，知道有哪几個分片可取，再按需抓取。這样既避免了單文件過大，也让更新可以局部進行——只改動某個分片，不必整份重建。

分片怎么切比較顺手

按栏目或业務线切

商品、文章、标簽頁、专题頁各自一個分片。好處是邊界清楚，某個栏目出問题时，影响的只是它對應的那一份，排查范围小很多。缺点是各栏目 URL 數量差异可能很大，需要留意別让某個分片長期贴着 50,000 的上限。

按更新节奏切

把高频更新的内容（新闻、商品上新）和低频内容（關于我們、帮助中心）分開。這样 lastmod 的變動會更集中，也方便观察蜘蛛對不同分片的回訪差別。

分片之後常见的几個坑

• 分片 404：拆文件时改了命名規則，舊分片删掉但索引没同步，蜘蛛拿着過期地址取不到内容。
• 索引没更新：新增子分片後忘记寫進索引文件，等于白做。
• lastmod 假更新：每次生成都寫目前時間，看起来天天在變。時間久了這個字段就失去參考意义。
• 压缩處理不一致：压缩文件的扩展名和响應头對不上，讀取时可能直接失敗。

這些問题都不难修，但都需要有人定期看一眼抓取日誌，而不只是把文件生成出来就結束。

Sitemap 之外，内鏈仍然是主路

分片再整齐，Sitemap 也只是「告知」有哪些 URL，蜘蛛走不走、走多深，依然看站内的連結结构。栏目頁、列表頁、分頁、相關推荐這些位置如果完整，蜘蛛可以顺着連結自然展開；如果某些 URL 只在 Sitemap 里出現、站内没有任何入口，抓取優先級通常不會高。

比較稳的做法是：Sitemap 负责覆盖全量和更新提示，内鏈负责提供合理的抓取路径，两邊不要互相替代。

服務器這一头的成本要算進去

不少站点用動態接口實时生成 Sitemap，每次請求都要查一遍資料库。URL 多的时候，這個過程本身就很重，遇上蜘蛛集中抓取，容易把响應時間拖長，反過来影响其他頁面的抓取。

更省事的做法是把分片结果定时生成、寫到静態文件或缓存里，蜘蛛来取时直接返回。抓取高峰时段尽量避免重建大文件，也別把生成任務和维護窗口排在一起。

把 Sitemap 当成一份需要長期维護的清單，而不是一次性提交的文件；索引、分片、lastmod 三者能對上，抓取入口才算稳。