站点地图（sitemap）是很多人做收录时最先想到的工具，但它的作用经常被高估。它解决的是「告诉搜索引擎这里还有哪些 URL」，而不是「让搜索引擎收录这些 URL」。如果提交之后收录没有变化，先把 sitemap 能做的事和不能做的事分开看，能省下不少反复折腾的时间。
sitemap 负责发现，不负责收录
一个 URL 从存在到出现在搜索结果里，大致要经过发现、抓取、索引、可展现几步。sitemap 能影响的只是最前面那一步：让搜索蜘蛛更快知道这个地址存在。至于它会不会被抓取、抓取后判断页面质量够不够、最终进不进索引，取决于页面本身和站点整体情况。把 sitemap 当成收录开关，是很多无效排查的起点。
所以判断 sitemap 有没有起作用，不能只看收录量，而要看：蜘蛛有没有抓取这个文件、文件里的 URL 有没有更快进入待抓队列。这两件事和「是否收录」是两回事。
几种常见的写法问题
sitemap 本身写得不规范时，它甚至连「发现」这一步都做不好。
lastmod 全站写同一个时间
有些站点每次生成 sitemap 时，把所有 URL 的 lastmod 都刷成当前时间。这样搜索引擎很快会发现这个字段不可信，之后就不再参考它来判断哪些页面值得优先回抓。lastmod 应该尽量反映页面内容的真实变更时间，而不是文件生成时间。
塞进了不该出现的地址
sitemap 里只应该放返回 200、且允许被索引的页面。以下这些放进去只会制造噪音：
- 会跳转到别处的 URL，包括站内重定向链上的中间地址
- 已经返回 404 或 410 的页面
- 被 robots.txt 屏蔽或加了 noindex 的页面
- 参数筛选、排序、追踪参数产生的重复地址
把这些混在里面，等于在告诉搜索引擎「这些也是正式页面」，反而淡化了真正想推的 URL。
文件过大或没有分索引
单个 sitemap 文件有数量上限，超过后需要拆成多个文件，再用一个索引文件把它们串起来。如果一直往里塞，最后可能出现文件过大、抓取中断的情况。分文件时按页型分组比按时间胡乱切更好用，比如列表页、详情页、聚合页各一份，后续看日志时也更容易判断哪类页型被发现的节奏慢。
文件本身没被访问
提交了地址不代表立刻会被抓。可以在服务器日志里搜一下 sitemap 的访问记录，看看搜索蜘蛛有没有来取过这个文件、多久来一次。如果连文件都没被抓过，讨论收录为时过早。
提交之后先确认两件事
- 文件是否被抓取。看日志里 sitemap 地址的请求记录和返回状态。如果一直是异常状态码，先修文件。
- URL 是否进入待抓队列。可以挑几个新页面，看它们的状态是「已发现」还是完全没出现。如果已经有发现记录，说明 sitemap 至少在起作用。
这两点确认完，再决定是继续等，还是去查别的环节。
真正能推进收录的动作
发现之后的路，sitemap 帮不上太多忙。能起作用的是这些：
- 站内链接。从已被收录、权重相对高的页面链向新页面，比只在 sitemap 里列一行更有效。
- 页面本身的可访问性。服务器响应是否稳定、内容是否正常渲染、有没有被自己用 robots 规则挡住。
- 减少重复和低质页面。同一内容多个地址、内容稀薄的页面铺得太多，会稀释抓取和索引的判断。
- 保持结构稳定。频繁改 URL、加参数、调层级，会让已经积累的发现记录重新洗牌。
一句话总结：sitemap 是把 URL 摆到台面上的工具，不是收录的保证。它能帮你少走「页面还没被发现」这一段路，剩下的路要靠内链、页面质量和站点整体结构来走。提交之后没反应时，先看文件有没有被抓、URL 有没有进入队列，再决定要不要动页面。