Sitemap 常被当成一张“提交给搜索引擎的清单”，于是很多人把站内能找到的地址全塞进去，觉得放得越多，蜘蛛来得越勤。实际用下来会发现，Sitemap 的价值主要在URL 发现这一环：它告诉蜘蛛“这些地址存在”，但抓不抓、什么时候抓、抓几次，仍由抓取预算和其他信号决定。把这张表写干净，比写得庞大更有用。
Sitemap 解决的是发现，不是抓取
先说清楚它的边界。搜索引擎读取 Sitemap 之后，会把里面的 URL 作为候选放进队列，但入队不等于抓取，更不等于收录。一个写得规范的 Sitemap，能帮新页面更快进入候选池，尤其是那些内链少、层级深的地址；但它没法让蜘蛛优先抓你，也没法保证收录结果。
所以评估 Sitemap 的指标不该是“提交了多少条”，而是“提交的地址有多少被真正抓取、有多少是有效页面”。
lastmod 要诚实，否则会被当成噪音
lastmod 表示页面内容的最后实质性修改时间。它有用的前提是准确。很多站点每次生成 Sitemap 就把所有 lastmod 刷成当前时间，第一次蜘蛛可能会重新抓一遍，几次之后就会判断这个字段不可信，进而减少对它的参考。
- 使用 W3C 日期格式，例如 2025-03-14 或带时区的时间戳。
- 只有正文发生实质变化时才更新，模板调整、评论数变化、推荐位轮换可以不更新。
- 不要为了“催抓取”而人为改 lastmod，短期可能有效，长期会让整个字段失效。
反过来，如果页面确实改过却一直不更新 lastmod，蜘蛛就只能靠自己的重新抓取节奏来发现变化，速度会慢不少。
只放该被抓取和索引的 URL
Sitemap 里出现的地址，默认会被理解为“希望被索引的页面”。凡是和这个前提冲突的 URL，都不应该放进去。
- 放最终地址，不要放会 301 或 302 的中间地址，否则蜘蛛每一条都要多跳一次。
- 不放带 noindex 的页面，两处信号互相打架，只会让处理变慢。
- 不放 404、410 或已经下线的地址，死链堆在 Sitemap 里会浪费读取和抓取。
- 参数页要谨慎，纯排序、纯筛选的组合页一般不放；分页页可以考虑保留，但要确保每页都有独立可访问的地址。
Sitemap 里放的是“希望被索引的地址”，不符合这个条件的地址就不要出现在里面。
还有一个容易被忽略的点：如果同一份内容有多个地址，Sitemap 里应该只写 canonical 指向的那个，而不是把所有变体都列一遍。
分片与 sitemap index 怎么组织
单个 Sitemap 文件有数量与体积上限，通常是一条 5 万个 URL、未压缩 50MB。超过之后需要拆成多个文件，再用 sitemap index 汇总，让蜘蛛从一个入口找到所有分片。
- 按内容类型分片，比如文章、商品、分类各自一份，出问题时容易定位。
- 大文件建议 gzip 压缩，减少传输体积，蜘蛛读取更快。
- 在 robots.txt 里声明 Sitemap 地址，这是最直接的告知方式。
- 分片文件本身也要能稳定返回 200，不能因为生成脚本超时而时有时无。
提交之后怎么验证
放上去不等于被读。可以回到服务器日志里看几件事：蜘蛛有没有定期读取 Sitemap 文件，读取的是哪个分片，读完之后有没有跟进抓取里面的正文页。如果长期没人取，先检查 robots.txt 是否误拦、地址是否稳定返回 200、返回的 Content-Type 是否正常。
一个简单的排查顺序
- Sitemap 地址本身能否直接打开，返回 200 且内容完整。
- robots.txt 里声明的地址是否正确，是否被其他规则挡住。
- 里面的 URL 是否都是最终地址、是否可索引。
- lastmod 是否诚实，分片是否都能正常访问。
- 日志里是否出现读取记录，之后是否跟进了正文抓取。
Sitemap 是辅助工具，它补的是“发现”这一环，替代不了内链。站内链接结构仍然是蜘蛛走遍全站的主要路径，Sitemap 更适合用来兜住那些靠点击很难到达的页面。把这两件事分开做，各司其职，抓取效率才会稳。