先分清：sitemap 是发现提示，不是收录开关

搜索引擎的 sitemap 协议，本质上是站点主动向爬虫提供的一份 URL 清单。它帮助爬虫更快知道“这里有哪些页面”，但并不改变页面的质量判断，也不保证这些 URL 会被抓取，更不保证被收录。在蜘蛛池的场景里这一点尤其重要：入口页和下一层页面值不值得抓，最终还是由爬虫根据内容、结构、历史表现自行决定。把 sitemap 当成“催抓工具”来用，往往会得到相反的结果——清单越长、含金量越低，对它的参考价值就越有限。

更实际的态度是：把 sitemap 当成一份整理好的目录，而不是一份提交任务的清单。

蜘蛛池里的 sitemap 该放哪些 URL

批量开站时最常见的做法，是把所有能生成的地址一股脑塞进去，包括分页、标签、排序参数、空结果页。这在蜘蛛池里格外危险，因为入口页本来就多，清单再膨胀，抓取机会会被大量低价值 URL 消耗掉。

更稳妥的取舍是：

• 只放你希望被当作入口使用的页面，以及入口页下面少量确实有内容的下一层页面；
• 不放带参数、带会话、带排序差异的地址，这些通常可以通过页面上的正常链接被发现；
• 不放空列表页、空详情页，以及内容明显重复的页面；
• 如果某个入口页本身只是过渡性质的跳转页，一般不必出现在 sitemap 里，让跳转关系自己说明即可。

判断标准很简单：这个 URL 如果被抓走一次，你是否愿意它占用一次抓取机会。答案是“不愿意”，就不要写进去。

格式、规模与分片的实际限制

主流约定是单个 sitemap 文件不超过 5 万个 URL、未压缩体积不超过 50MB，超过就要用 sitemap index 拆分成多个子文件。蜘蛛池通常入口页数量多，分片几乎是必然的。

• XML 与纯文本两种格式都被支持，纯文本一行一个 URL，适合结构简单的场景；
• 分片时按域名或按批次切分，便于后续停用某批入口页时只替换对应文件；
• 文件可以用 gzip 压缩，但要注意文件名后缀与响应头 Content-Type 保持一致；
• sitemap 文件本身也要能正常返回 200，不要被防火墙、鉴权或 CDN 缓存规则挡住。

lastmod：写假日期不如不写

lastmod 是 sitemap 里最容易被滥用的字段。批量生成时随手写成“当前时间”，或者每天全量刷新，短期看似让文件显得新鲜，但当爬虫发现这个时间和页面真实变化对不上，对该字段的参考权重就会下降。

比较务实的做法是：只有页面内容确实变化时才更新 lastmod，模板、样式、页脚改动通常不算内容变化。如果没法准确记录，宁可不写这个字段，也不要批量刷一个假时间。

声明、提交与校验

写好的 sitemap 需要让爬虫知道它在哪里。常见方式是：

• 在 robots.txt 里用 Sitemap 指令声明完整地址，多个文件时逐条列出；
• 在各搜索引擎的站长平台里提交，并观察提交数量与实际抓取数量之间的差异；
• 定期用脚本或工具检查每个文件的可访问性、URL 数量、是否混入 404 或 5xx 地址。

校验这件事在蜘蛛池里不能省。入口页批量上下线，很容易出现 sitemap 指向已停用域名、证书过期地址或返回 403 路径的情况。这类链接长期留在清单里，对整批入口的抓取表现没有好处。

把 sitemap 当成一份需要长期维护的资产，而不是一次性的提交文件。

常见误区

• 以为提交了 sitemap 就等于被收录，实际上它只影响发现环节；
• 把全站所有 URL 都塞进去，结果反而稀释了重点入口；
• 用 sitemap 去推送大量内容重复、价值不明确的页面；
• 文件长期不更新、不校验，里面堆积大量失效地址；
• 把 sitemap 当成绕过 robots 或访问限制的手段。

使用建议

如果只是小规模测试，一个纯文本 sitemap 就够了；入口页成百上千时，建议按批次分片，并让分片关系与上线节奏、止损机制对应起来——哪批入口页停用，就替换或移除对应文件。每次调整后隔一段时间回看日志里 sitemap 的抓取次数，以及后续 URL 的抓取变化，比盯着“提交了多少条”更有意义。