Sitemap 最早是个单文件，几百上千个 URL 放进去就完事。但站点长大以后，单文件会同时出现三个问题：生成一次要跑很久、任何一处小改动都要整份重写、里面有一条 URL 格式出错可能影响整份文件的解析。索引文件加分片的做法，正是为了解决这类维护问题，而不是为了直接提升抓取量。

什么时候值得拆

• URL 总量已经过万，单文件生成时间明显变长。
• 站点包含几类更新节奏完全不同的内容，比如文章、商品、标签页。
• 需要按语言或按目录分别提交，便于定位问题。
• 每次发布只影响少量页面，却要重新生成整份清单。

行业里普遍遵循的约定是单个 Sitemap 文件不超过 5 万条 URL、未压缩体积不超过 50MB。这更像是一条安全线：接近上限时，解析和传输都容易出问题，拆开更稳妥。

索引文件和分片的基本写法

索引文件本身只做一件事：列出各个分片的地址。它通常包含 loc 和 lastmod 两个字段，指向分片的 XML 地址。真正承载 URL 的是分片文件。

这里有个容易被忽略的点：分片地址要保持稳定。每次生成时用时间戳或哈希做文件名，等于每隔一段时间就换一批新地址，之前积累的抓取记录就断了。内容可以变，地址尽量不变。

分片地址一变，对蜘蛛来说就是一批新 URL，而不是同一份文件的更新。

分片按什么切

• 按目录或栏目切：结构清晰，出问题时容易对应到具体频道。
• 按更新频率切：高频更新的内容单独一个分片，低频内容合在一起。
• 按页面类型切：文章详情、列表页、专题页分开，便于分别观察。
• 按语言切：多语言站点可以按语言目录拆分，和 hreflang 的划分保持一致。

单个分片的条数不必卡到上限，一万到两万条留出余量，反而更利于生成和校验。分片数量也不宜无限膨胀，几十个分片还好管理，上千个就会让索引文件本身变得臃肿。

lastmod 该写什么

lastmod 只有在页面内容确实变化时才更新。批量刷新所有页面的时间戳，看起来是“显得活跃”，实际会让这个字段失去参考价值。格式上使用 W3C 日期格式，整份站点统一时区，避免同一批页面出现前后矛盾的时间。

它和内链的分工

Sitemap 解决的是发现，内链解决的是路径。蜘蛛从 Sitemap 拿到 URL 后，仍会结合站内链接判断这个页面处在什么位置、值不值得经常回来。一个只在 Sitemap 里出现、站内没有任何入口的页面，抓取频率通常不会高。

• 内链能到的页面，仍然要以内链为主，Sitemap 只是补充清单。
• 内链到不了的页面（比如深层的筛选结果、临时活动页），才需要靠 Sitemap 兜底。
• 参数页、排序页、日历翻页这类会大量繁殖的 URL，不建议写进 Sitemap。

几个常见排查点

1. 索引文件或某个分片返回 404，导致整块 URL 丢失。
2. 分片所在目录被 robots.txt 误屏蔽。
3. 分片里写的是会跳转的旧地址，抓取时多走一跳。
4. XML 语法错误，比如转义字符没处理，整份文件解析失败。
5. 压缩方式与响应头不匹配，蜘蛛拿到的是压缩内容却识别不出类型。

还有一点和服务器稳定性有关：分片最好离线生成后作为静态文件输出，不要让蜘蛛的请求触发实时生成。抓取高峰时如果每个请求都要查询数据库拼 XML，响应时间会被拖长，连带影响其他页面的抓取节奏。

怎么判断有没有起作用

访问日志里能看到蜘蛛对各分片的抓取记录：哪些分片被反复读取、哪些长期没人碰。搜索后台的 Sitemap 报告只作为参考，真正能说明问题的是日志里 URL 有没有陆续被访问。索引文件与分片是一套维护工具，它的价值在于让 URL 清单可管理、可分批更新，而不是提交了就一定会有反馈。