sitemap index 什么时候该拆，怎么写

sitemap index 是一份列其他 sitemap、而不是列页面的 sitemap。什么时候必须有它？单个文件越过 Google 写明的上限时 —— 50,000 个网址，或未压缩 50MB，哪个先到算哪个。没到这条线之前拆，对抓取没有任何好处，对排错有一个好处，而后者通常才是真正值得拆的理由。

读这篇之前

你得先有一份已经提交、能跑起来的 sitemap。第一份怎么写、哪些页面该放进去哪些不该，写在 网站地图怎么写。这一篇从「一个文件装不下了，或者读不懂了」开始。

sitemap index 和普通 sitemap 差在哪

差在里面装什么。普通 sitemap 的每个 <loc> 是一个页面地址；sitemap index 的每个 <loc> 是另一份 sitemap 的地址。根元素也不一样，前者是 <urlset>，后者是 <sitemapindex>。你在 Search Console 里只提交后面这一个。

Google 把天花板写在一句话里：「All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs.」越过任何一条，这个文件就是无效，而不只是「有点大」。文档给的处理办法同样短：「If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps. You can optionally create a sitemap index file and submit that single index file to Google」（Build and submit a sitemap，2026-09-03 访问）。

「未压缩」这三个字最容易被跳过。gzip 是允许的，也该用，但 50MB 量的是压缩之前 —— 一个磁盘上只有 9MB 的 .gz，照样可能是超限的。

index 自己也有上限：「A sitemap index file may have up to 50,000 loc tags」，以及「You can submit up to 500 sitemap index files for each site in your Search Console account」（Manage large sitemaps，2026-09-03 访问）。把前两行相乘，一个 index 的余量推算下来是 25 亿个网址。被这个文件格式卡住的站，基本不存在。

动手之前先把自己这份文件的两个数拿到：里面有多少个 <loc>，压缩之前占多少体积。多数构建工具这两个数都不报，于是团队能在「要不要拆」上争一周，而桌上一个数都没有。如果你在一万个网址、几兆体积以内，那上限就不是你的理由，下一节才是。

不是被上限逼的时候，该按什么轴拆

真正去建 index 的站，多数离 50,000 还很远。它们拆是因为：Search Console 报「4,000 个页面未收录」时，一个平铺的大文件什么也告诉不了你。按你以后想拿数字去对照的那条线拆。

最后一行要当真。三个文件表现完全一样的 index，只是多了一个会坏的零件，回答不了你任何一个问题。

按你以后想拿覆盖数字去对照的那条线拆。别的线只是把文件变多。

四步建好并提交

整件事就是一个文件加两处引用。真正难的是决定按什么拆，那是上一节的事。

1. 子 sitemap 照常写，每一份都压在两条上限以内。名字要写清里面装的是什么：sitemap-blog.xml，不是 sitemap-2.xml。
2. 写 index 文件，用绝对地址列出每个子文件。只能是同一个站 —— sitemaps.org 写得很明确：「A Sitemap index file can only specify Sitemaps that are found on the same site as the Sitemap index file.」
3. 把 index 放在站点根目录，并在 robots.txt 里用 Sitemap: 指过去。位置不只是整洁问题：Google 写着，除非你在 Search Console 里提交，否则「a sitemap affects only descendants of the parent directory」。
4. 在 Search Console 里只提交 index，绝不要把子文件也一起提交。Search Console 会把每个子文件列在它下面，而这正是你建它的全部理由。

提交完等 Search Console 显示这个 index 已读取，再确认每个子文件都出现在它下面、各自带着自己的网址数。某个子文件列出来了、发现的网址数却是 0，问题通常出在 index 里的路径，而不是子文件本身 —— 上线当天抓到它，比一个月后在覆盖率报告里发现便宜得多。

robots.txt 里那一行写绝对地址，一行一个，放在文件任何位置都行，它不属于任何一个 User-agent 段。很多站在这里踩的坑是：换了 index 的路径，忘了改 robots.txt，于是一份还在被读的旧文件和一份没人知道的新文件同时存在，两边给出的网址集合还不一样。改路径时把这两处当成一次改动来做。

可以直接抄的模板

把下面这段复制走，换掉三个条目；lastmod 如果生成不出真值，就整个删掉。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-09-03</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-docs.xml</loc>
    <lastmod>2026-09-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

index 条目上的 lastmod 描述的是那个子 sitemap，不是里面的页面。每次部署都给所有条目盖上今天日期的构建流程，发的是一个不携带任何信息的字段 —— 这种失效形态量在 sitemap 的 lastmod 可不可信。不写这个元素是合法的，也更诚实。

四种会出错的方式

四种都很安静，没有一种会在你平时会看的地方冒出报错。

1. index 和子文件一起提交。同一批网址会挂在两个父节点下被报两遍，之后你读到的每个数字都是含混的。
2. 压缩之后以为没超。50MB 量的是未压缩体积。要在压缩之前查，否则发出去的是一个磁盘上看着很小的无效文件。
3. 把 index 放进子目录。放在 /xml/sitemap-index.xml 却列了 /xml/ 之外的页面，能不能算数就完全取决于有没有在 Search Console 提交。放根目录最稳。
4. 按一条没人会去读的轴拆。按字母分片、按构建序号分片，产出的是一堆你没法对它提出假设的文件。覆盖率掉下来的那天，你面对的还是四万个网址，一样缩不了范围。

它做不到的事

它不会让 Google 抓得更快或更频繁。文档没有这样承诺，我们也没测到过只靠拆分就改变收录的案例。它也不推送任何东西，要推去看 IndexNow 怎么配。它更不能让一个本来不够格被收录的页面变得够格 —— sitemap 是关于「怎么被发现」的建议，不是关于「收不收」的指令。

还有一件事我们没查清：sitemaps.org 的协议页和 Google 的大型 sitemap 文档，都没有写 index 里能不能再列一个 index。两边的说法我们都没找到，所以我们不嵌套；在有人能指出允许它的那一行之前，你也别嵌套。另外它也不替你保证子文件里的网址是好的：一份把三千个 404 列得整整齐齐的 index，格式上完全合法。想确认自己列进去的那些网址实际返回的是什么，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

多少个网址才需要 sitemap index

技术上是 50,001 个。实际上，只要你有两类页面、而且想分开读它们的覆盖情况，就该建了 —— 对多数站来说这个时刻早得多。

子 sitemap 要不要也提交一遍

不要。只提交 index。Search Console 会把子文件列在它下面，两个都提交会造成重复统计，之后每个数字都更难读。

sitemap_index.xml 404 是怎么回事

先分清是文件没生成还是路径不对：直接用浏览器打开那个地址，看返回的是 404 还是一份空的 XML。插件生成的 index 常常挂在一个和你写进 robots.txt 的地址不同的路径上，两处对不上时，robots.txt 里那一行指向的就是一个不存在的文件。

子 sitemap 能放在子域名上吗

同一个 index 里不行。协议限定 index 只能列「found on the same site as the Sitemap index file」的 sitemap，所以另一个子域名要有自己的一套 sitemap 和自己的 Search Console 资源。

条目顺序有讲究吗

规范里没有说有，我们也没有任何数据说明它有影响。按人找起来最快的方式排就行。