sitemap 的作用是“告知”，不是“保证收录”
很多站点把 sitemap 当成收录开关：只要 URL 写进去，就等着它出现在索引里。实际情况是，sitemap 只是一种发现入口，它告诉蜘蛛“这个地址存在”，但要不要抓、抓了要不要进索引，仍然取决于页面质量、重复情况和站内结构。把 sitemap 写得又大又满，并不会让收录量自动上涨，反而可能稀释蜘蛛对重要页面的注意力。
单文件写多少条 URL 比较合适
主流搜索引擎对单个 sitemap 文件的 URL 条数和文件体积都有上限约定，通常是不超过 5 万条、未压缩体积不超过 50MB。这是硬性边界，不是推荐值。实际运营中更常见的做法是远远低于这个数：
- 几百到几千条的小站点，一个文件写完全部 URL 即可，维护成本最低。
- 上万条的中型站点，按栏目或内容类型拆分，一个文件对应一个可独立维护的集合。
- 内容量持续增长的站点，按时间或分部拆分，避免每次更新都重写整个文件。
数量本身不是问题，把不同优先级、不同更新节奏的 URL 混在一起才是问题。当新闻页和帮助文档同处一个文件，蜘蛛很难从 sitemap 层面判断哪些值得优先抓。
分片拆分的原则：按业务逻辑，不按凑数
分片（sitemap index 指向多个子 sitemap）的意义在于让每个文件有清晰的语义。可以考虑这几种切分方式：
- 按内容类型：商品、文章、分类、标签各一个文件，便于单独观察各类页面的收录表现。
- 按更新频率：高频更新的列表页放一起，几乎不变的静态页放一起。
- 按站点分部：多语言或多地区站点，按语言目录或子域拆分，方便排查某一分部的抓取异常。
不推荐单纯为了“每个文件不超过 N 条”而机械切割，那样拆出来的文件没有业务含义，出问题时无法定位。
lastmod 该写多准
lastmod 是 sitemap 里最容易被滥用的字段。常见两种极端：
- 全部页面都写当天日期，或者每次生成时统一刷新一遍。
- 完全不写，让蜘蛛自己判断。
前者会让这个字段失去参考价值——当所有 URL 都显示“刚刚更新过”，蜘蛛会逐渐忽略它。后者虽然不算错，但放弃了向蜘蛛传递更新信号的机会。比较稳妥的做法是只在页面正文确有实质变化时更新 lastmod，例如模板微调、广告位轮换、页脚年份变化这类改动不应触发更新。如果做不到精确到每个页面，宁可只给真正会变的栏目加这个字段。
一个可用的判断标准：这个改动，用户重新访问时会察觉到吗？察觉不到，就不必改 lastmod。
怎么判断 sitemap 有没有被用上
提交之后不要只看“已提交”状态，可以从几个方向验证：
- 服务器日志：观察蜘蛛是否按 sitemap 里的 URL 发起抓取，抓取的时间分布是否集中在你预期的栏目上。
- 索引报告：看“已发现但未编入索引”的 URL 是否大多来自 sitemap。如果比例很高，说明发现问题解决了，但质量问题没解决。
- 抓取频次与响应码：如果 sitemap 里的 URL 大量返回 3xx、404 或 5xx，先把这些地址清理掉，否则蜘蛛会降低对该文件的信任。
几个容易忽略的细节
- sitemap 里只放返回 200 且允许被抓取的规范 URL，被 robots.txt 屏蔽或带 noindex 的地址不必放进去。
- 写进去的应该是页面的最终规范地址，而不是带跟踪参数、会话 ID 的变体。
- 更新 sitemap 后不必频繁 ping 提交入口，稳定更新比高频触发更有意义。
- 索引文件本身的 URL 保持固定，不要每次改名，否则蜘蛛需要重新发现入口。
把 sitemap 当成一份需要长期维护的清单，而不是一次性的提交动作，它才能真正帮上 URL 发现的忙。