sitemap 管的是“发现”，不是“收录”
很多人把 sitemap 当成一个“提交就能收录”的按钮：文件生成好、丢进后台，然后坐等索引数量上涨。实际运行一段时间就会发现，提交前后蜘蛛的抓取节奏可能有变化，但收录结果并不会因为一份文件就整体改变。sitemap 解决的是“发现”问题，不是“收录”问题。它把一批 URL 明确摆到蜘蛛面前，减少“没人链接所以找不到”的情况；至于这些页面最终进不进索引，仍然由页面本身的质量、可索引状态和站点整体情况决定。
哪些 URL 值得放进 sitemap
- 返回 200、允许索引的规范 URL：canonical 指向自己，robots meta 里没有 noindex。
- 有实质内容、确实希望被搜到的页面：栏目主页面、文章详情、产品页。
- 站内链接深度较深、入口较少的页面，靠 sitemap 补一条发现路径。
- 新上线、内链还来不及铺开的页面。
- 更新频繁、需要重新抓取的页面，配合可靠的 lastmod 一起提交。
哪些 URL 放进去只会添乱
- noindex 页面：一边声明不许索引，一边请蜘蛛来抓，信号互相矛盾。
- 301、302 跳转地址：应该放跳转后的目标，而不是跳转前的旧地址。
- 404、410 或已经下线的页面：长期挂着死链，既消耗抓取，也削弱文件的可信度。
- 站内搜索结果页、排序筛选参数页：数量可能无限增长，且大多是重复内容。
- 分页的深层页面、标签聚合页：是否值得收录要单独判断，不要整批塞进去。
多版本 URL 只留一个
同一个页面如果存在带参数、大小写不同、结尾斜杠不同等多个版本，sitemap 里只写规范版本。把几个版本一起提交，等于主动把重复内容送到蜘蛛面前，后面再靠 canonical 收口，效率会差很多。如果站点同时存在 http 与 https，或者 www 与非 www 并存，先在服务器层面统一跳转，再谈 sitemap。
格式和维护上的几个细节
- 单个文件建议不超过 5 万个 URL、未压缩体积不超过 50MB，超出就分片，再用索引文件汇总。
- 一份 sitemap 里只放同一域名下的 URL，不要混入其他域名。
- 文件地址写在 robots.txt 中，方便蜘蛛找到；有多份时列出索引文件即可。
- 定期清理：下线的页面、失效的 URL 该删就删，sitemap 是一份维护中的清单，不是一次性动作。
lastmod 不要随便填
lastmod 是给蜘蛛判断“这个页面值不值得再来一趟”的参考。如果每次生成 sitemap 都把时间刷成当天，蜘蛛很快就会学会忽略这个字段；反过来，页面确实做了大幅修改却从不更新，也会错过重新抓取的时机。宁可只给真正改过内容的 URL 写 lastmod，也不要整批刷时间。
提交之后该看什么
- 抓取日志里这些 URL 有没有被访问，返回的是什么状态码。
- 索引报告里，这批 URL 是进入了索引，还是停在“已发现，尚未编入索引”。
- 被排除原因的分布：是 noindex、重定向，还是“已抓取，尚未编入索引”。
- 站点整体抓取量有没有被这批 URL 挤占。
如果日志里根本看不到抓取，先检查 robots.txt 是否拦截、文件是否可正常访问、URL 本身是不是跳转地址。如果抓取了却不收录，问题通常不在 sitemap，而在页面内容和站点整体质量层面。
把 sitemap 当成一份“告诉蜘蛛有哪些页面”的清单，而不是收录的承诺书，很多困惑会自然减少。