很多站点把 sitemap 当成“提交一次就完事”的清單，實际它更像一份持續维護的 URL 目錄。搜尋引擎會參考它来發現新頁面、判断更新节奏，但 sitemap 本身不會保證收錄，也不會直接带来排名。真正有價值的是：让這份清單尽量准确、干净、可抓取，减少蜘蛛在無效 URL 上浪費的時間。
一、先確認 sitemap 有没有被正确声明
最常见的低級問题是文件存在，但搜尋引擎不知道去哪找。你可以在 robots.txt 里加一行 Sitemap 指令，也可以在各搜尋平台的站長工具中主動提交。两者不冲突，建议都做。提交後不要只看“提交成功”的提示，過一段時間去後台看 sitemap 报告里的已發現 URL 數、已抓取數和错誤提示。
二、只放規范、可抓取的 URL
sitemap 里的每一個地址，都應该是你希望搜尋引擎抓取並索引的版本。以下情况需要先處理掉：
- 返回 404、410 或 5xx 的頁面，不要留在 sitemap 里。
- 會 301/302 跳轉的舊地址，直接寫最终地址。
- 被 robots.txt 屏蔽、或被 meta robots 标成 noindex 的頁面，不要放進去。
- 同一内容有多個參數版本时，只保留 canonical 指向的那個 URL。
- 带 session id、跟踪參數、排序篩選參數的地址，通常不值得進入 sitemap。
如果 sitemap 里混入大量低质或不可抓取 URL，搜尋引擎會降低對整份文件的信任，後續真正重要的新頁面也可能被拖慢發現。
三、lastmod 不要随便寫
lastmod 是告诉搜尋引擎“這個頁面最後一次實质性更新是什么时候”。有些 CMS 每次生成 sitemap 都會把所有頁面的 lastmod 刷成目前時間，短期看似乎能吸引蜘蛛，長期反而让這個字段失去參考價值。更稳妥的做法是：只有正文、價格、库存、步骤等核心内容真正變化时才更新 lastmod；模板調整、样式修改、广告位更換可以不改。
四、大站用 sitemap index 拆分
当 URL 數量較多时，單個 sitemap 文件會變得很大，生成和抓取都容易出問题。這时可以用 sitemap index 做索引，再按栏目、内容類型或更新時間拆成多個子文件。拆分时注意两点：一是每個子文件只放同一類 URL，便于排查；二是索引文件里只列子 sitemap 的地址，不要把普通頁面混進去。子文件數量多时，也要控制單個文件的 URL 數量，避免超出搜尋引擎建议的上限。
五、分頁、图片和多語言怎么處理
分頁列表頁是否放進 sitemap，要看它們是否有獨立價值。如果只是翻頁聚合，通常不需要全部提交；如果每頁都有獨特摘要且能被用戶直接訪問，可以保留 canonical 版本。图片和视频可以單獨做扩展 sitemap，但前提是资源本身可訪問、有稳定 URL，並且和頁面内容相關。多語言站点則要确保每個語言版本都有對應的 hreflang 和規范地址，不要互相混在同一個 sitemap 里。
六、提交之後看什么
提交 sitemap 不是终点。後續可以观察搜尋平台里的抓取統計、索引覆盖和 sitemap 报告：哪些 URL 被發現但没抓取，哪些抓取了却没索引，哪些报错。發現異常时，先回到頁面本身检查狀態碼、canonical、robots 和内容质量，而不是反复重新提交同一份文件。對站点运营来说，定期清理 sitemap 比频繁提交更有意义。
七、几個常见的脏資料来源
- 自動把站内搜尋结果頁、标簽聚合頁、用戶後台頁寫進 sitemap。
- 已下架商品或已刪除文章仍留在文件里。
- URL 大小寫、带不带斜杠、http 與 https 混用，造成重复地址。
- 把需要登入才能訪問的頁面列入 sitemap，蜘蛛抓到的是登入頁或 403。
- 子目錄站点没有獨立 sitemap，主站文件却混入了其他域名的 URL。
八、一份可执行的自查清單
- 在浏览器直接打開 sitemap 地址，確認返回 200 且格式可讀。
- 检查 robots.txt 中的 Sitemap 声明是否正确，协议和域名是否一致。
- 抽查文件中的 URL：是否 200、是否 canonical 自身、是否可被抓取。
- 確認 lastmod 反映真實内容更新，而非生成時間。
- 大站检查 sitemap index 與子文件是否各司其职。
- 提交後定期查看报告，清理失效和低质 URL。
把 sitemap 当成一份需要维護的清單，而不是一次性任務。它不能保證收錄，但能让搜尋引擎少走弯路，也让站点运营多一個观察 URL 健康度的窗口。