很多站点把 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 提交无效”的情况都能落到具体原因上，而不是继续在提交动作上反复加码。