sitemap 常被当成“提交即收录”的开关，但它只解决一件事：告诉爬虫站点上存在哪些 URL。至于这些 URL 会不会被抓、抓完会不会进索引，取决于页面状态、站内结构和内容本身。所以当 sitemap 提交后迟迟没有反应，先别反复提交同一个文件，按下面的顺序从文件本身查到入口和内链。
先确认爬虫有没有读过这个文件
第一步不是看收录量，而是看抓取日志里有没有对 sitemap 地址的请求。如果完全没有记录，问题多半出在入口上：
- robots.txt 里的 Sitemap 行容易写错，需要完整绝对地址，例如 https://example.com/sitemap.xml，不要写成相对路径。
- 检查 robots.txt 有没有顺手把 sitemap 文件本身 Disallow 掉。文件被禁止抓取，自然读不到里面的 URL。
- 文件地址要能直接访问，返回 200，Content-Type 为 xml（.xml.gz 则为 gzip），不要先跳一跳再返回内容。
- 用工具后台上传的文件，注意是否被放到了需要登录才能访问的目录。
如果日志显示爬虫确实来读了几次，说明发现渠道是通的，接下来要排查的是 URL 质量和优先级。
文件里放的 URL 是否都值得被收录
sitemap 里混进不可收录的地址，会稀释这份名单的可用性，爬虫读到的无效条目越多，对整份文件的信任就越低。以下类型建议先清理：
- 返回 3xx 的地址：直接写跳转后的最终地址。
- 404、410 或长期打不开的地址。
- 带 noindex、被 robots 屏蔽、canonical 指向其他页面的地址。
- 会话参数、时间戳参数、排序筛选参数生成的大量变体。
- 需要登录、需要加购或需要提交表单才能看到正文的页面。
一个简单判断：如果你不希望这个 URL 出现在搜索结果里，就不要放进 sitemap。另外，线上地址要和文件里的写法完全一致，包括协议、主机名（www 与否）、大小写和末尾斜杠，任何不一致都可能被当成另一个 URL 处理。
格式与体量上的硬性限制
- 单个 sitemap 文件上限 5 万条 URL、50MB 未压缩体积。
- 超过上限要拆分成多个子文件，再用 sitemap index 汇总，索引文件本身同样有 5 万个条目的上限。
- URL 要用绝对地址，& 等特殊字符需要转义，否则文件会解析失败。
- lastmod 填真实修改时间。全站批量刷成当天、或长期一动不动，都会让这个字段失去参考价值。
入口位置与提交方式
常见做法是把文件放在根目录，并在 robots.txt 中用 Sitemap 行声明，同时在搜索资源平台的 sitemap 报告里提交一次。报告能告诉你文件是否读取成功、发现了多少条 URL，但它衡量的是发现，不是收录，不要拿这里的数据当成收录结果。更新文件内容后，保持地址不变即可，不需要每次改动都重复提交；真正需要检查的是文件是否仍可访问、是否仍返回 200。
sitemap 之外还缺什么
发现和抓取是两回事。sitemap 只提高 URL 被知道的概率，不传递权重，也不决定抓取顺序。如果新页面除了 sitemap 之外没有任何内链指向它，通常还是要等很久，甚至一直等不到。更稳的做法是让新页面从已经被抓取的页面链出，并尽量控制在一两跳以内到达。
抓取预算有限时，往 sitemap 里堆大量低价值地址，反而会分散爬虫对真正重要页面的注意力。名单越精简，越容易看出问题出在哪。
一份可执行的核对清单
- 日志中是否有对 sitemap 地址的请求记录，响应码是否为 200。
- robots.txt 的 Sitemap 行是否写对，文件本身未被 Disallow。
- 抽样访问文件里的 URL，确认全部是最终地址、可正常打开。
- 排查 noindex、canonical、参数变体是否混入名单。
- 核对文件体积、条目数和 lastmod 的写法。
- 确认新增页面有内链入口，而不是只靠 sitemap 等待发现。
按这个顺序走一遍，通常能定位到是文件没被读到、名单本身有问题，还是页面缺少站内入口。至于多久能看到变化，取决于抓取节奏和页面质量，没有可以承诺的时间表。