Sitemap 不是给用户看的页面，而是给蜘蛛的一份 URL 清单。站点小的时候一个文件就够，URL 数量上到几万、几十万以后，就要用索引文件加多个分片的写法。这套结构本身不复杂，容易出问题的是分片怎么拆、哪些 URL 不该放进去，以及它和内链讲的是不是同一件事。

索引文件解决的是“清单太长”

Sitemap 索引文件（sitemapindex）本身不含页面 URL，只列出各个分片的地址。蜘蛛先读索引，再按需要读分片，不用一次把几十兆的文件全部拉走。对抓取预算有限的大站来说，这个结构能让蜘蛛分批读取，而不是被一个巨大的文件卡住。

分片的两个硬约束

• 单个 Sitemap 文件最多 50,000 条 URL。
• 未压缩体积不超过 50MB，压缩后一般控制在 10MB 以内更稳妥。

超过就拆成多个分片，并在索引文件里逐个列出。分片地址尽量固定，不要每次生成都换路径，否则蜘蛛会反复发现“新”文件。

哪些 URL 不该写进去

Sitemap 的价值在于表达“这些页面我希望被抓、且可以被抓”。以下情况放进去只会浪费一次抓取：

• 返回 404、410 或长期 5xx 的地址；
• 被 robots.txt 屏蔽的目录；
• 需要登录、对蜘蛛返回登录页的地址；
• 带筛选、排序、追踪参数的重复页，除非它们确实是独立内容；
• 同一内容的多个版本，canonical 指向别处的那些。

换句话说，Sitemap 里的每一条，都应该对应一个能直接打开、正文完整的页面。

分片可以按什么维度拆

按目录、按内容类型、按更新频率拆都行，关键是拆完之后能回答“哪个分片对应站点的哪一块”。常见做法：

1. 文章、商品等主体内容单独一个分片；
2. 分类、标签、列表页一个分片；
3. 更新频繁的栏目单独拆出来，便于单独调整生成频率；
4. 历史归档内容体积大、变动少，可以合并成一个大分片。

这样做的好处是，某个分片生成失败或被误改时，影响范围可控，不会让整站清单一起失效。

Sitemap 和内链要说同一件事

如果 Sitemap 里有一批 URL，站内却没有任何链接指向它们，蜘蛛即使从 Sitemap 抓到了，也不容易判断这些页面的位置和重要性。两种情况要同时看：

• Sitemap 里有、内链没有：检查是不是孤儿页面，补一个合理的入口；
• 内链里有、Sitemap 没有：如果页面值得抓，把它加进去；不值得，就考虑是否需要这些页面。

另外，Sitemap 里的 URL 形式要和页面上实际使用的保持一致，包括大小写、结尾斜杠、协议与域名。形式不统一，很容易被当成两个地址处理。

提交之后的检查

生成完不要只看文件能不能打开。至少确认几件事：索引文件里每个分片都返回 200；分片内容能被正常解析；抽查几条 URL，打开后状态码、canonical 和 Sitemap 里的写法一致；文件里没有混进状态异常的地址。更新频率不必刻意提高，URL 清单的内容变了再重新生成就行。

把 Sitemap 当成一份需要维护的清单，而不是一次生成就丢在服务器上的文件。它和内链、canonical 讲的是同一套 URL 关系，三者对不上时，先修数据，再谈抓取。