很多人把 sitemap 当成一个“提交就收录”的按钮，实际它更像递给蜘蛛的一张路线图：告诉它站里还有哪些 URL 可以来看看。至于蜘蛛来不来、来了收不收，取决于页面本身和站点的整体情况。所以当 sitemap 提交之后迟迟没动静，先别急着怀疑平台，问题往往就写在文件本身。

先分清它解决的是哪一环

URL 进入索引大致要过三关：被发现、被抓取、被判断值得收录。sitemap 主要作用在第一关。它帮蜘蛛绕过内链不足、层级太深、入口单一这些障碍，把 URL 送到抓取队列门口。后面两关它基本插不上手，页面质量、可抓取性、重复程度这些才是决定因素。把这个前提摆正，排查时才不会把“没被收录”和“sitemap 没用”混成一件事。

几个常见的写法问题

1. 把不该出现的 URL 塞进去

sitemap 里最忌讳的是放那些明摆着不该进索引的地址：

• 返回 301、302 的跳转 URL；
• 返回 404、410 的死链；
• 页面上写了 noindex 的 URL；
• 被 robots.txt 禁止抓取的路径；
• 带会话 ID、跟踪参数的一次性地址。

这些地址混在文件里，会让蜘蛛白跑一趟，浪费抓取额度，也会让 sitemap 本身的可用性打折扣。放进去的应该是可以正常打开、返回 200、并且你希望它进索引的规范 URL。

2. lastmod 常年不动或者天天都变

lastmod 是给蜘蛛判断“要不要重爬”的参考。如果所有页面都挂着一个从建站起就没改过的时间，它逐渐会被忽略；反过来，如果每次生成都写成当前时间，等于告诉蜘蛛全站天天更新，同样会失去可信度。比较省事的做法是让程序在正文真正变动时才更新这个字段，模板、导航、页脚变化不算。

3. 分片文件写好了，索引文件没对上

URL 数量多的时候会把 sitemap 切成多个文件，再用一个索引文件串起来。常见疏漏是：分片更新了，索引文件还是旧列表；或者索引里写了分片地址，但分片本身返回 404。提交前手动打开几个分片看一眼，能省掉很多反复。

4. 只放首页和栏目页

sitemap 最有价值的场景恰恰是那些内链少、藏得深的页面——详情页、历史文章、翻页之后的内容。如果文件里翻来覆去只有首页、几个栏目和最新的十几条，那它对发现环节的帮助非常有限。理想状态是让 sitemap 覆盖你希望被索引的全部规范 URL，同时用站内链接把重要页面再串一遍。

提交之后怎么验证

• 在服务器日志里搜 sitemap 文件名，确认蜘蛛确实来取过；
• 看日志中蜘蛛顺着 sitemap 抓了哪些 URL，有没有大量 404 或跳转；
• 用站长平台的抓取与索引报告看这些 URL 的后续状态；
• 抽查几条 URL，看它们是否出现在搜索结果里。

把这四步串起来看，基本能判断卡在哪一环：文件没被取走、取走但没抓、抓了但没进索引，对应的处理方式完全不同。

什么时候该重新提交

不需要每次发文章都手动提交一次。让 sitemap 由程序自动更新，在站点结构变动、批量新增页面、迁移 URL 之后，再主动去平台点一次比较合适。如果换了域名或改了路径规则，记得同时更新 sitemap 里的地址，否则蜘蛛拿到的还是旧清单。

sitemap 能提高发现的效率，但它不改变页面的质量。一份干净、准确、覆盖完整的文件，加上站内合理的链接结构，才是让 URL 稳定进入索引的基础。