把 sitemap 提交上去，并不等于页面会被抓取，更不等于会进索引。它更像一份地址清单，负责告诉搜索引擎站内有哪些地址存在。收录没动静时，很多人的第一反应是再提交一次，其实更值得做的是从文件本身往上查一层——文件有没有被读到、里面放的地址合不合格、站内还有没有别的入口。这三层里任何一层出问题，提交多少次都不会有变化。
第一层：先确认 sitemap 本身被读到了
提交动作显示成功，不代表文件被正常解析。先确认这几件事：
- 可访问性：用无痕窗口直接打开 sitemap 地址，看是否返回 200，有没有被登录墙、CDN 规则或访问控制挡住。如果 robots.txt 里把 sitemap 所在目录 Disallow 了，抓取也会受影响。
- 格式与编码：必须是合法 XML，声明 UTF-8；特殊字符需要转义，例如 & 要写成实体形式。用校验工具过一遍，比肉眼扫一遍靠谱。
- 声明位置：在 robots.txt 里加一行 Sitemap 指向完整地址，同时也在后台提交。两者不冲突，覆盖的是不同读取路径。
- 后台的读取记录：看上次读取时间和读取到的条数。如果时间一直停在几周前，说明读取端根本没来，需要回头查服务器日志和访问控制。
- 体量限制：单个文件不超过 5 万条 URL、50MB（未压缩）。超了就拆成多个，再用 sitemap index 汇总成一个入口。
如果这一步就不通过，后面的排查都没有意义。
第二层：清单里的 URL 是不是该出现的地址
sitemap 是规范地址的清单，不是站内所有链接的备份。放错地址不但起不到作用，还可能把抓取引向不该去的地方。
- 只放返回 200、允许被索引的正式页面。
- 不要放 301 跳转地址、404 页面、被 robots 屏蔽的地址。
- 不要放标注了 noindex 的页面，两个信号互相打架。
- 带参数的地址、筛选页、排序页，除非确认要单独收录，否则不要放进去。
- 同一内容的多个地址，只保留 canonical 指向的那一个。
- 翻页与分页地址按实际策略决定，不要一股脑全塞进去。
还要确认清单里的 URL 与页面上 canonical 写的一致。批量生成时经常出现模板改了、sitemap 生成脚本没跟着改的情况，两边对不上，提交上去也等于白交。
第三层：sitemap 之外，页面还有没有别的入口
sitemap 解决的是发现，抓取和收录还要看页面本身与站内结构。常见的情况是：清单里的地址早就被抓过了，但迟迟不进索引，这说明问题不在提交环节。
- 入口深度：页面能不能从首页顺着正常内链点到？只能靠 sitemap 触达的地址，抓取优先级通常很低。
- 内链数量与质量：同一批页面里，被内链指向更多的往往收录更快。完全孤立的地址即使提交了也很难推进。
- 内容是否值得单独成一个页面：模板套壳、信息量明显不足的页面，收录困难往往出在这里，而不是提交方式。
- 服务器响应：抓取时超时、频繁返回 5xx、大量重定向，都会被视为负面信号。
一个可执行的核对顺序
- 打开 sitemap 地址，确认返回 200、XML 合法、能被公开访问。
- 去后台看上次读取时间和读取到的条数，判断文件有没有被解析到。
- 抽样十几条 URL，逐条检查状态码、canonical、robots 与 noindex 标记。
- 核对 sitemap 生成逻辑与页面模板是否同源，避免两边不一致。
- 回到站内，检查这些页面有没有正常内链入口、能否从栏目页点到。
- 查服务器日志，确认抓取端来过没有；来过却没收录，重点就转向页面质量本身。
把 sitemap 当成一份地址清单，而不是一个收录开关，排查思路会清晰很多。它负责让页面被看见；能不能被留下，取决于地址是否规范、入口是否通畅、内容是否站得住。
提交之后没有动静，先别急着重复提交。按文件、URL、入口这三层从上往下走一遍，多数问题在前两层就能定位。