Sitemap 是什么，不是什么
Sitemap 解决的是广度問题：告诉搜尋引擎站点里存在哪些規范 URL。它不解决權重和優先級問题，也不保證被收錄。不少站点把 sitemap 当成唯一的發現渠道，内鏈却断得七零八落，最後 sitemap 里大量 URL 長期停留在已知但很少被訪問的狀態，提交動作本身没错，缺的是配套的入口结构。
文件结构上的几個硬约束
- 單個文件不超過 50000 條 URL，解压後不超過 50MB，超過就分片
- 分片之後要用 sitemap 索引文件串起来，索引里同样只放各個分片的地址
- 只放最终返回 200 的規范地址，不放重定向目标之外的舊地址、不放參數變体、不放已设 noindex 的頁面
- 寫绝對 URL，包含协议；统一用 UTF-8 编碼；体量較大时用 gzip 压缩
這几條看着基础，但审核不嚴的站点常常在分片环节出错：文件生成了，索引里却漏掉某一個，等于這部分 URL 從未被提交過。
lastmod 為什么容易失真
很多站点的 lastmod 用的是构建時間，而不是内容實际變更時間。發一次版，全站 URL 的時間戳一起變成今天。第一次可能還會引起抓取系統的注意，几次之後這個信号就没有区分度了——所有頁面都顯示刚更新，等于所有頁面都没有更新。
更麻烦的是時間戳回退。某篇文章的 lastmod 從 6 月變回 3 月，這種前後不自洽會让抓取系統降低對整個 sitemap 的信任。
lastmod 的價值在于区分，而不是新鲜。全站统一刷新，等于没有信号。
相對稳妥的做法
- 把 lastmod 绑定到内容實体：正文、标题、结构化資料、主要配图的實际修改時間
- 模板、導航、頁脚的調整不要寫進 lastmod
- 時間戳只前進不後退，时区统一，格式用带偏移的 ISO 8601
- 没有可靠時間来源的頁面，宁可不寫 lastmod，也不要随手填一個目前時間
分片與更新节奏
分片不要按字母顺序随便切。可以按内容類型或更新频率来分：高频更新的栏目一個文件，長期稳定的頁面一個文件。這样你只需要重新生成變動的那個分片，不必每次重寫全部。
更新频率上，sitemap 不需要每有一條内容變動就重新生成並推送，一天几次通常足够。频繁提交同一個文件，收益是递减的。
和 canonical、内鏈的分工
sitemap 只列規范版本。同一篇内容的其它地址通過 canonical 指向它，不要把几條地址都塞進 sitemap，那是自己制造重复抓取。
sitemap 负责让抓取系統知道地址存在，内鏈负责說明哪個頁面更重要、從哪儿進入。只提交 sitemap、内鏈里却没有任何指向的頁面，抓取間隔通常明顯長于有内鏈支撑的頁面。反過来，内鏈结构清晰、sitemap 寫得粗糙的站点，抓取表現往往也不差——两者的權重並不對等。
怎么驗證它有没有起作用
- 在服務端日誌里筛出 sitemap 中的路径，看是否被訪問、訪問間隔多長
- 對比有内鏈入口和無内鏈入口的頁面，抓取频次差异是否明顯
- 查看搜尋引擎後台的 sitemap 报告，關注已發現與已抓取之間的差距
- 抽查 lastmod 與内容實际修改時間是否一致
如果大量 URL 長期停在已發現未抓取，先別急着改 sitemap，回到内鏈和站点层級上看：這些頁面本身是不是缺少入口，或者藏得太深。
几個常见坑
- sitemap 里包含 robots.txt 已屏蔽的目錄，白提交
- 分片文件没有在索引里列出，等于没提交
- 把搜尋结果頁、篩選頁塞進去，制造大量低质抓取
- 把 sitemap 当站点结构图用，放進去成千上萬個几乎不更新的頁面，反而稀释了真正的更新信号