很多站点把 sitemap（站点地图）当成收錄開關：提交上去，就等着頁面進索引。執行一段時間會發現，sitemap 提交和頁面收錄之間並没有直接因果關系。它更像给搜尋引擎递了一份“這里有哪些 URL”的清單，至于抓不抓、收不收，仍由頁面本身和其它信号决定。把它的职责邊界弄清楚，排查时就不會在错誤的位置反复折腾。
sitemap 管的是發現，不是收錄
搜尋引擎處理一個 URL 大致分几步：發現、抓取、渲染、索引、展示。sitemap 主要作用在第一步，让爬虫知道這個 URL 存在。它不保證抓取，更不保證收錄。所以出現“提交了 sitemap，几天過去没動静”时，要往下游看：是没被抓，還是抓了没收。
判断方法很直接：在搜尋资源平台里查具体 URL 的狀態。如果停在“已發現，尚未抓取”，說明發現环节没問题，卡点在抓取調度；如果顯示“已抓取，未编入索引”，那更可能是頁面质量或重复問题，跟 sitemap 關系不大。
哪些頁面值得寫進 sitemap
- 希望被索引、能直接訪問且返回 200 的正文頁；
- 作為導航入口的栏目頁、分類頁（前提是列表本身有獨立價值）；
- 更新频繁、需要被及时重新抓取的頁面。
反過来，下面几類通常不该出現：
- 带 noindex 的頁面，或 canonical 指向別的 URL 的頁面，放進去等于自相矛盾；
- 被 robots.txt 屏蔽的路径、登入後才可见的頁面、參數组合可以無限生成的列表頁；
- 返回 404、5xx，或重定向鏈很長的 URL。
把不该放的連結塞進去，短期看提交量很大，實际會稀释整体信号，让真正需要抓的頁面排到後面。
提交了却像没提交：常见失效原因
- 格式或地址問题。文件不是有效 XML、压缩方式與声明不一致，或放在爬虫訪問不到的位置（返回 403、需要登入、被 CDN 拦截），都會導致讀取失敗。
- 提交的是舊文件。索引文件指向分片，但分片没有更新，爬虫讀到的仍是很久以前的列表。
- 内容類型不對。有的站点把 sitemap 地址寫成了普通 HTML 頁面，或返回的 Content-Type 是 text/html，讀取會直接失敗。
- 規模超限。單個文件對 URL 數量和体积有上限，超出後需要拆分，並用索引文件组织起来。
- 與頁面内信号冲突。同一個 URL 在 sitemap 里表示可索引，頁面里却有 noindex，或 canonical 指向另一個地址，爬虫會以頁面内的指令為准。
lastmod 別随手寫
lastmod 是爬虫判断“要不要重新抓”的參考之一，前提是它准确。把所有 URL 统一刷成当天時間，短期也许能带来抓取量，几次之後這個字段的可信度就下降了，之後再想用它提醒更新，效果會打折。更稳的做法是只在實际内容發生變化时更新，並让它和頁面上的發布時間、修改時間保持一致。
sitemap 和内鏈、提交渠道怎么配合
sitemap 是补充，不是替代。一個從任何頁面都点不到的孤岛 URL，即便寫進 sitemap，抓取机會也明顯少于有内鏈指向的頁面。更可靠的组合是：關键頁面先保證站内可達，導航、列表、相關推荐里能点到，再用 sitemap 覆盖那些结构上不容易被發現的頁面，比如老内容、深层归档。
提交方式上，把 sitemap 地址寫進 robots.txt 是基础做法，同时在搜尋资源平台主動提交一次，能让爬虫更快拿到文件位置。這條路径解决的是“知不知”，不解决“收不收”。
一句话记：sitemap 把 URL 送到爬虫面前，頁面本身的质量决定它能不能留下。
排查顺序建议
- 取几個提交後没動静的 URL，逐個查抓取與索引狀態，先分清是没抓還是没收；
- 检查這些 URL 是否返回 200、是否带 noindex、canonical 指向哪里；
- 確認 sitemap 文件可正常訪問、格式合法、内容是最新版本；
- 看這些頁面在站内是否有内鏈支撑，点击深度是否過深；
- 最後再考虑調整 sitemap 结构或提交频率。
按這個顺序走，多數“sitemap 提交無效”的情况都能落到具体原因上，而不是繼續在提交動作上反复加碼。