先把 sitemap 的位置摆正：它管发现，不管收录
站点地图（sitemap）最直接的作用，是把一批 URL 一次性告诉搜索引擎，省去它们沿着内链和外链慢慢爬的过程。它是一份候选清单，不是收录申请单。搜索引擎读完 sitemap 之后，仍然会按自己的判断决定要不要抓、要不要放进索引。
所以当 sitemap 在后台显示“已成功处理”，而索引里却找不到对应页面时，这两件事并不矛盾。前者只说明文件被读到了、格式没出错；后者取决于页面质量、内容是否重复、站点整体是否值得信任等一堆因素。
哪些 URL 值得放进 sitemap
一份干净的站点地图，应该只包含希望被索引、且本身具备被索引条件的页面。判断标准可以简单列成几条：
- 返回状态码 200，不是 301、302、404、410；
- 页面自身没有 noindex，也不在 robots.txt 的 Disallow 范围内；
- canonical 指向自己，或者干脆没有指向别处的 canonical；
- 内容是能独立成页的，不是纯筛选、排序、会话参数生成的临时地址。
常见反例是把全站链接一股脑导出来：站内搜索结果页、带跟踪参数的分享链接、已经被合并的老地址、需要登录才能看的页面，全都塞进去。文件体积上去了，有效信号反而被稀释，蜘蛛花在低价值地址上的时间也变多。
lastmod 写不准，比不写更糟
lastmod 字段的原意是告诉搜索引擎这个页面什么时候有过实质改动，方便它优先回抓更新的内容。如果每次生成 sitemap 都把全站 lastmod 刷成当天时间，第一次可能还有效，几次之后搜索引擎就会开始忽略这个字段。
更稳妥的做法是：只在正文、标题、结构化数据等真正变化时更新 lastmod，与内容无关的模板调整、样式改动不要动它。做不到精确追踪，就干脆不写，让搜索引擎自己判断。
数量、拆分和更新节奏
单个 sitemap 文件有条数和体积上限（通常为 5 万条 URL、未压缩 50MB），超过之后需要用 sitemap 索引文件指向多个子文件。这个限制本身不难处理，麻烦的是拆分方式。
按栏目拆比按时间拆更好维护：文章、商品、专题、帮助中心各自一个文件，某个板块出问题时不至于整份文件推倒重来。子文件的数量也不必刻意堆，几十个页面能覆盖的站点，没必要拆成上千份。
更新频率上，内容型站点每天或每周生成一次通常够用；更新稀疏的站点，按月甚至更低频也没问题。真正要紧的是别让文件里长期挂着大量 404 或重定向地址，那会让后续几次抓取都浪费在无效地址上。
提交之后没动静，按这个顺序排查
- 先确认文件真的被读到了：后台有没有报格式错误、编码问题，是否被 robots.txt 挡住。这一步没过，后面的排查都没有意义。
- 再抽查 sitemap 里的 URL 本身：随机挑十几个，用抓取工具模拟一次访问，看状态码、canonical、robots meta 是否符合预期。
- 然后看内链：如果站点地图里有一批页面，站内却几乎没有链接指向它们，蜘蛛即便知道地址，也缺少再次回访的理由。sitemap 是补充通道，内链才是主路径。
- 最后才看内容和竞争：页面是否与其它页高度重复、是否有足够的独立信息、是否属于用户会主动搜索的类型。这一层的问题，靠调整 sitemap 解决不了。
几个容易踩的细节
- 文件里同时出现 http 和 https、带 www 和不带 www 的版本，会产生大量重复地址，最好只保留正式版本。
- 分页、筛选、排序参数页要不要进 sitemap，取决于是否希望它们被索引。不确定的话先放一小部分，观察一段时间再决定。
- 多语言或多地区站点，可以把各语言版本的 URL 放在同一份文件里，用 hreflang 标注关系，不必为每种语言单独提交一份。
- sitemap 是公开可访问的，不要往里放内部测试页、后台地址或只有特定用户才能访问的 URL。
把它当基础设施，而不是开关
站点地图更像给搜索引擎准备的一份目录，长期保持干净、准确、与站内实际情况一致，它的价值才会慢慢体现。指望它一提交就带来收录变化，往往会把注意力从真正的问题——页面质量和站内结构——上移开。