Sitemap 在 URL 發現里扮演什么角色
不少人把 Sitemap 当成“提交了就會被收錄”的開關，實际它更像是一份候選清單。蜘蛛發現 URL 的渠道有好几條：外鏈、内鏈、歷史抓取记錄、Sitemap 以及其他声明文件。Sitemap 的價值在于，它能把那些内鏈层級很深、或者暂时没有外鏈指向的 URL 主動摆到蜘蛛面前，缩短發現环节的等待時間。但發現只是第一步，能不能抓、抓了之後怎么處理，取决于頁面本身的可訪問性和内容质量。
索引文件與分片：規模變大後怎么组织
單個 Sitemap 文件有明确上限：5 萬個 URL、未压缩体积不超過 50MB。超過之後就需要拆分成多個文件，再用一個 Sitemap 索引文件把它們串起来。索引文件本身只列出各個子 Sitemap 的地址，不直接列頁面 URL。
拆分时的几個實际注意点
- 按内容類型拆通常比按時間拆更好维護，例如文章、商品、专题各一個文件。
- 子文件之間不要互相嵌套，索引文件只引用最末一級的 Sitemap。
- 文件地址尽量保持稳定，频繁改名會让已经抓過的记錄變成無效路径。
- 压缩成 .gz 是被支持的，但要保證解压後内容完整、编碼正确。
lastmod 什么时候真正有用
lastmod 表示頁面内容的最後修改時間。它有用的前提是准确。如果每次生成 Sitemap 都把全部 URL 的 lastmod 刷成目前時間，蜘蛛很快會發現這個字段不可信，進而忽略它，甚至降低對整份文件的信任度。
比較稳妥的做法是：只在内容确實發生實质變化时更新對應條目的 lastmod。比如正文补充、價格調整、库存變化這類會改變頁面主要信息的改動。模板微調、广告位轮換、時間戳自動刷新這類不影响主体内容的改動，不建议動 lastmod。
把 lastmod 当成“我改了所以你要来看”的信号，前提是它真的代表改動。
Sitemap 和内鏈的分工
Sitemap 负责告诉蜘蛛“有這么個 URL”，内鏈负责告诉蜘蛛“這個 URL 有多重要、和別的頁面是什么關系”。两者不能互相替代。一個只存在于 Sitemap、站内没有任何連結指向的頁面，即使被抓取，也很难获得稳定的回訪，因為它在站点结构里没有位置。
反過来，連結受限的深层頁面如果只靠内鏈發現，可能要等很久。這时候用 Sitemap 补一刀，是合理的搭配。
寫好之後怎么驗證
- 確認 Sitemap 地址能在浏览器直接打開，返回 200 而不是 404 或跳轉。
- 检查 robots.txt 里是否声明了 Sitemap 地址，注意路径完整、大小寫正确。
- 抽查若干條目，確認其中的 URL 都是可訪問的、返回 200 的規范化地址。
- 過一段時間看抓取日誌，观察這些 URL 是否出現蜘蛛的訪問记錄，以及抓取後的狀態碼分布。
- 如果長期没有抓取痕迹，先排查文件本身是否可讀、條目是否有效，再考虑其他因素。
几個容易被忽略的细节
- Sitemap 里不要放被 robots.txt 拦截的 URL，两者矛盾會让信号變混乱。
- 不要放重定向地址、404 頁面、參數化篩選頁這類不该被当作獨立頁面處理的 URL。
- 列表頁如果要放進 Sitemap，最好只放第一頁，後續分頁交给内鏈處理。
- 文件更新频率不必太高，一天多次重寫並不會明顯加快發現速度。
Sitemap 做得好，能减少 URL 在發現环节的等待；但它解决不了内容层面和服務器层面的問题。把它当作一項稳定的基础配置，而不是抓取問题的萬能钥匙，思路會更清楚。