不少人把 sitemap 当成收录开关：文件生成好、提交到搜索平台，接下来就等着页面进索引。实际跑一段时间会发现，提交量和收录量对不上，有时差得还很远。问题通常不在文件本身，而在于对 sitemap 的定位理解偏了。
sitemap 解决的是“被发现”，不是“被收录”
搜索蜘蛛发现新 URL 主要有几条路径：站内链接、外部链接、sitemap，以及历史抓取记录。sitemap 在其中的作用是补充性的——它帮蜘蛛知道“这个站还有这些地址”，但知道之后要不要抓、抓完要不要编入索引，是另外两个独立环节。
- 被 sitemap 列出：URL 进入待抓取队列
- 被抓取：拿到 HTTP 状态和 HTML 内容
- 被索引：内容质量、重复程度、站点整体情况综合判断
这三步任何一步卡住，最终结果都是“提交了却搜不到”。所以看到 sitemap 里的 URL 没有收录，先别急着改文件，应该回到索引状态报告里看它停在哪一档。
哪些 URL 不该放进 sitemap
sitemap 是一份“希望被收录”的清单，往里塞不该收录的地址，只会稀释它的信号价值，也会白白消耗蜘蛛的抓取额度。
- 被 noindex 的页面：一边告诉蜘蛛别索引，一边又列进 sitemap，属于自相矛盾。
- 重定向 URL：301、302 的旧地址应该写成跳转之后的目标地址。
- 返回 404 或 410 的地址：已经下架的页面尽快从文件里移除。
- 大量参数组合页：筛选、排序、会话参数生成的近乎无限的 URL，应收敛而不是提交。
- 非规范版本：如果 A 页的 canonical 指向 B，那么 sitemap 里应该出现的是 B。
判断标准很简单：这个 URL 你是否真的希望它单独出现在搜索结果里？答案是否定，就别放进去。
lastmod 别乱写
lastmod 是 sitemap 里少数会被参考的字段之一，前提是它准确。如果每次生成文件都把全部 URL 的时间刷成当天，时间一长这个字段就失去参考意义，蜘蛛也会逐渐忽略它。只在页面内容确实发生实质变化时，更新对应条目的时间，才更有价值。
规模大时先拆分再提交
单个 sitemap 文件有数量和体积上限，通常不超过 5 万条 URL、未压缩不超过 50MB。超过就拆成多个子文件，再用 sitemap 索引文件统一指向。拆分时按栏目或内容类型划分，比按生成时间随机切分更好排查问题，也方便后续单独观察某一类的收录情况。
提交之后的自查动作
- 从 sitemap 里抽样一批 URL，比如每个栏目抽二十条，把这批地址固定下来。
- 隔一段时间复查这批 URL 的抓取状态和索引状态，记录变化。
- 对比没有放进 sitemap、但有正常内链入口的页面，看两者的收录节奏差多少。
- 如果差距很小，说明 sitemap 的边际作用有限，重点该转向内链结构和内容质量。
内链才是主通道
对多数中小站点来说，蜘蛛进入站内最稳定的路径，是从首页和栏目页一路跟下来的链接。sitemap 更适合处理那些链接入口较弱的页面：刚发布还没被内链带到的内容、深层归档页、变动频繁的页面。如果站点本身的链接结构就很浅，页面都能在两三次点击内到达，sitemap 更多是兜底，而不是主力。
把 sitemap 当成一份需要持续维护的清单，而不是一次性提交的动作。定期清理失效地址、补上新页面、保持字段准确，再配合内链和内容质量一起看，收录状态才会慢慢稳下来。