Sitemap 常被当成一張“提交给搜尋引擎的清單”，于是很多人把站内能找到的地址全塞進去，觉得放得越多，蜘蛛来得越勤。實际用下来會發現，Sitemap 的價值主要在URL 發現這一环：它告诉蜘蛛“這些地址存在”，但抓不抓、什么时候抓、抓几次，仍由抓取预算和其他信号决定。把這張表寫干净，比寫得庞大更有用。
Sitemap 解决的是發現，不是抓取
先说清楚它的邊界。搜尋引擎讀取 Sitemap 之後，會把里面的 URL 作為候選放進队列，但入队不等于抓取，更不等于收錄。一個寫得規范的 Sitemap，能帮新頁面更快進入候選池，尤其是那些内鏈少、层級深的地址；但它没法让蜘蛛優先抓你，也没法保證收錄结果。
所以评估 Sitemap 的指标不该是“提交了多少條”，而是“提交的地址有多少被真正抓取、有多少是有效頁面”。
lastmod 要诚實，否則會被当成噪音
lastmod 表示頁面内容的最後實质性修改時間。它有用的前提是准确。很多站点每次生成 Sitemap 就把所有 lastmod 刷成目前時間，第一次蜘蛛可能會重新抓一遍，几次之後就會判断這個字段不可信，進而减少對它的參考。
- 使用 W3C 日期格式，例如 2025-03-14 或带时区的時間戳。
- 只有正文發生實质變化时才更新，模板調整、评论數變化、推荐位轮換可以不更新。
- 不要為了“催抓取”而人為改 lastmod，短期可能有效，長期會让整個字段失效。
反過来，如果頁面确實改過却一直不更新 lastmod，蜘蛛就只能靠自己的重新抓取节奏来發現變化，速度會慢不少。
只放该被抓取和索引的 URL
Sitemap 里出現的地址，預設會被理解為“希望被索引的頁面”。凡是和這個前提冲突的 URL，都不應该放進去。
- 放最终地址，不要放會 301 或 302 的中間地址，否則蜘蛛每一條都要多跳一次。
- 不放带 noindex 的頁面，两處信号互相打架，只會让處理變慢。
- 不放 404、410 或已经下线的地址，死鏈堆在 Sitemap 里會浪費讀取和抓取。
- 參數頁要谨慎，纯排序、纯篩選的组合頁一般不放；分頁頁可以考虑保留，但要确保每頁都有獨立可訪問的地址。
Sitemap 里放的是“希望被索引的地址”，不符合這個條件的地址就不要出現在里面。
還有一個容易被忽略的点：如果同一份内容有多個地址，Sitemap 里應该只寫 canonical 指向的那個，而不是把所有變体都列一遍。
分片與 sitemap index 怎么组织
單個 Sitemap 文件有數量與体积上限，通常是一條 5 萬個 URL、未压缩 50MB。超過之後需要拆成多個文件，再用 sitemap index 匯總，让蜘蛛從一個入口找到所有分片。
- 按内容類型分片，比如文章、商品、分類各自一份，出問题时容易定位。
- 大文件建议 gzip 压缩，减少传輸体积，蜘蛛讀取更快。
- 在 robots.txt 里声明 Sitemap 地址，這是最直接的告知方式。
- 分片文件本身也要能稳定返回 200，不能因為生成脚本超时而时有时無。
提交之後怎么驗證
放上去不等于被讀。可以回到服務器日誌里看几件事：蜘蛛有没有定期讀取 Sitemap 文件，讀取的是哪個分片，讀完之後有没有跟進抓取里面的正文頁。如果長期没人取，先检查 robots.txt 是否誤拦、地址是否稳定返回 200、返回的 Content-Type 是否正常。
一個简單的排查顺序
- Sitemap 地址本身能否直接打開，返回 200 且内容完整。
- robots.txt 里声明的地址是否正确，是否被其他規則挡住。
- 里面的 URL 是否都是最终地址、是否可索引。
- lastmod 是否诚實，分片是否都能正常訪問。
- 日誌里是否出現讀取记錄，之後是否跟進了正文抓取。
Sitemap 是辅助工具，它补的是“發現”這一环，替代不了内鏈。站内連結结构仍然是蜘蛛走遍全站的主要路径，Sitemap 更适合用来兜住那些靠点击很难到達的頁面。把這两件事分開做，各司其职，抓取效率才會稳。