很多站点把 sitemap 当成一个开关：只要提交了，页面就应该被收录。实际使用中更接近另一种情况——sitemap 主要解决“搜索引擎知道有这个 URL”的问题，至于抓不抓、收不收，还要看页面本身和其他入口。把它放在正确的位置上，它能省下不少排查时间；放错了，反而会制造噪音。

sitemap 能解决的是“发现”，不是“收录”

搜索引擎获取 URL 的渠道大致有几类：外链、站内链接、历史抓取记录、站长提交的 sitemap。sitemap 的价值在于批量、明确地告诉搜索引擎“这些 URL 存在，而且我希望它们被抓取”。它省掉的是“发现”这一步的时间，并不改变后续的抓取排队、内容评估和索引决策。

把 sitemap 当成“告知清单”，而不是“收录申请”。

什么样的 URL 才值得写进 sitemap

原则很简单：只放你希望出现在搜索结果里、且当前可以正常访问的规范 URL。

• 返回 200、内容完整的页面；
• 页面的规范版本，也就是 canonical 指向的那个地址，而不是各种参数变体；
• 内容有独立价值的页面，而不是纯筛选、纯排序、空结果的列表；
• URL 形式保持站内统一，例如是否带尾斜杠、是否带 www，全站一致。

反过来说，noindex 的页面、需要登录才能看的页面、重定向地址、404 地址，都不适合出现在 sitemap 里。把它们放进去，除了让报告里多出一些无意义的条目，没有别的帮助；如果 sitemap 里同时放着 noindex 页面，两种信号还会互相打架。

几个常见的使用误区

lastmod 随手写成当天

lastmod 的作用是告诉搜索引擎“这个页面什么时候真正更新过”。如果每次生成 sitemap 都刷新成当天，这个字段就失去了参考价值，长期看容易被忽略。更实用的做法是让 lastmod 跟随页面内容或模板的真实变更时间，没有变化就别动它。

提交一次就不管了

把 sitemap 当作动态文件来维护更合适：新页面生成时加入，页面下线时移除。大站点可以按栏目或模板分片，再用一个 sitemap 索引文件汇总。分片不只是为了绕开单文件的条目和体积限制，也让“哪一批 URL 提交了、哪一批没提交”更容易核对。

把 sitemap 当成唯一入口

如果一批页面只能从 sitemap 被发现，站内没有任何链接指向它们，即使被抓取，内容评估也会比较吃力。sitemap 更适合作为兜底和补充，日常的 URL 发现依然要靠清晰的导航和合理的内部链接结构。

用 sitemap 报告做排查

在 Search Console 的 sitemap 报告里，可以看到每个 sitemap 被读取的条目数量，以及是否解析成功。它更适合用来核对数量差异，而不是直接判断收录：

1. 先看 sitemap 是否读取成功，条目数和你提交的是否一致；
2. 再对比 sitemap 里的 URL 总数与站点实际需要收录的页面数量，差距大就先查生成逻辑；
3. 把 sitemap 里的 URL 与索引报告、日志中的抓取记录对照，区分是“没被发现”还是“发现了没抓”；
4. 按模板或栏目拆分后逐组看，比只看一个总数更容易定位问题集中在哪类页面。

小结

sitemap 是一件成本不高、收益稳定的基础工具：它让 URL 发现变得可控、可核对，但替代不了内容质量、链接结构和索引状态本身的问题。把该放的放进去，把不该放的拿出来，剩下的交给常规的抓取与评估流程就好。