sitemap 常被当成一個開關：提交了，就该收錄。實际上它只解决一件事——告诉搜尋引擎這里有一批 URL 存在。抓不抓、收不收，取决于頁面本身和站点整体情况。所以当提交後長時間没動静，先回到文件本身看几處细节，通常比反复重新提交更有用。

sitemap 到底解决什么

搜尋引擎發現 URL 的入口有好几類：站内連結、外部連結、sitemap，以及歷史抓取积累。sitemap 的優势是覆盖面全、更新及时，尤其适合深层頁面和新上线的内容。它的局限同样明顯：文件只是线索，既不是抓取命令，也不是收錄承诺。把它理解成给蜘蛛的一份地图，而不是一張收錄申請表，预期會合理很多。

提交只是把 URL 放進候選池。是否抓取、是否收錄，最终還是要回到頁面质量和站点整体表現上。

文件里最容易被忽略的几處

放進来的 URL 是不是都该被抓

• 設定了 noindex 的頁面不要寫進 sitemap，两邊信号矛盾會让蜘蛛白跑一趟。
• 有跳轉的舊地址不要寫，直接寫跳轉後的最终地址。
• 带大量參數的篩選頁、站内搜尋结果頁、翻得很深的分頁，一般不值得放進去。
• 已经 404 或 410 的地址如果不清理，會造成反复抓取空頁面，浪費抓取配額。

lastmod 是不是真的在變

lastmod 的作用是提示内容的實际更新時間。如果每次生成文件都把全部 URL 的時間戳刷成今天，這個字段很快就會失去參考價值；反過来，内容明明改過却不更新，也可能让重抓延後。建议按内容真實變更時間寫入，没有改動就不要動它。

文件本身能不能被正常讀到

• URL 數量超過五萬條或体积過大时需要分片，並用 sitemap 索引文件把它們串起来。
• 文件地址要能公開訪問，不要挡在登入、白名單或 CDN 的訪問控制後面。
• robots.txt 里的 Sitemap 声明建议寫完整的绝對地址。
• XML 格式错誤、编碼不统一，都可能让整個文件解析失敗，而报告里未必给出明确提示。

和 robots、canonical 是否打架

最常见的冲突有两種：robots.txt 阻止了某個目錄，sitemap 里却還在推這些 URL；頁面 canonical 指向另一個地址，sitemap 里寫的却是目前地址。這類矛盾不會报错，但會让抓取预算花在無效請求上。整理一遍，保證能被抓、能自指、值得收這三件事彼此一致。

提交之後怎么观察

1. 看 sitemap 报告里已發現的網址數，是否接近文件里的實际條目數量。
2. 用抓取統計或服務器日誌，確認這些 URL 有没有真的被請求過。
3. 抽样挑几個地址，用 URL 检查工具看目前狀態和抓取结果。
4. 分批次做對比，观察新增内容從提交到被抓的延迟有没有在缩短。

如果已發現數量對得上，但長時間没有抓取請求，問题多半不在文件，而在站点整体的抓取分配。這时候更值得回头看内鏈结构和内容质量。反過来，如果已發現數量遠低于文件條目，就先怀疑文件解析、格式或訪問限制。

几個常被問到的点

是不是提交得越频繁越好

没必要。文件随内容更新自然重新生成即可。没有變化的反复提交不會加速收錄，反而让报告資料波動更难判断。

新站能不能只靠 sitemap 被收錄

新站阶段，蜘蛛對站点的信任度有限，單靠 sitemap 推 URL 收效偏慢。更稳的做法是让新頁面從首頁或栏目頁经過少量点击就能到達，sitemap 作為补充入口，而不是唯一入口。

收錄變差了要不要删掉 sitemap

不要。收錄波動的原因通常在頁面质量和抓取分配，不在文件本身。删掉 sitemap 只會让 URL 發現變慢，原来的問题没解决，還多出一层干扰變量。

小结

sitemap 是個成本低、長期有效的工具，但它只负责让 URL 被看见。把文件里的地址控制在该抓、可抓、值得抓的范围内，保證 lastmod 真實、格式可讀、與 robots 和 canonical 不冲突，剩下的就交给頁面质量和站内结构去解决。提交之後按节奏观察，別用反复提交替代排查。