sitemap 怎么拆：索引文件、分片与提交频率的实操细节

sitemap 是 SEO 里最没有技术含量、又最容易被做错的一环。大部分站点的 sitemap 就一个文件、几千条 URL、半年没更新过。这不算错，但它几乎没有起作用。

这篇文章讲三个具体问题：什么时候该拆文件、索引文件怎么用、提交频率到底该怎么定。

一、先确认 sitemap 的实际作用

它不是「提交就收录」的开关。它的作用是：

• 告诉搜索引擎「这些 URL 存在」，尤其是内链很少、层级很深的页面
• 提供 lastmod，让抓取系统判断哪些页面值得重抓
• 作为诊断依据（Search Console 会报告 sitemap 里的错误）

它不能做的：提高排名、加速新站收录、让薄页面被收录。指望 sitemap 救收录，方向就错了。

二、什么时候需要拆

这是最关键的一个判断。以下四个信号出现任意两个，就该拆了：

信号	具体表现
单文件超过 5 万条 URL	协议上限是 5 万条 / 50MB（未压缩）
索引率明显偏低	sitemap 报告里「已提交」远大于「已编入索引」
内容类型差异大	目录页、文章页、标签页混在一个文件里
更新频率差异大	一部分页面天天变，一部分半年不动

第三个和第四个信号最容易被忽略。混在一个文件里，搜索引擎只能看到整体的平均更新频率，无法区分「哪些是新的」。拆开之后，每类内容有独立的 lastmod 节奏，抓取优先级才能体现出来。

三、推荐的拆分结构

按内容类型拆，不按数量硬切：

/sitemap_index.xml          ← 索引文件，列出下面所有文件
/sitemap-pages.xml          ← 静态页（关于、联系、收录标准）
/sitemap-categories.xml     ← 分类页
/sitemap-sites.xml          ← 条目详情页（数量最大）
/sitemap-articles.xml       ← 文章页
/sitemap-tags.xml           ← 标签聚合页

条目详情页如果超过 5 万条，再按分片拆：sitemap-sites-1.xml、-2.xml……分片顺序要稳定，不要每次重新生成时打乱，否则会造成大量无效重抓。

索引文件长什么样

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-10-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-sites.xml</loc>
    <lastmod>2026-10-22</lastmod>
  </sitemap>
</sitemapindex>

索引文件本身也要提交给搜索引擎，只提交 /sitemap_index.xml 一个地址就够了。

四、lastmod 怎么写才不算撒谎

这是最常见的技术性错误：每次生成 sitemap 时，把所有 URL 的 lastmod 都刷成当前时间。

后果很直接——搜索引擎会很快发现「这个站的 lastmod 全是假的」，然后开始完全忽略这个字段。一旦被忽略，你后面真的更新了内容，它也不信了。

正确做法：

• lastmod 只在该页面的实质内容变化时更新
• 模板改版、样式调整、广告位变动，不算内容变化
• 用数据库里的 updated_at 字段，不要用 date('Y-m-d')
• 格式用 W3C 日期（2026-10-22）或完整时间（2026-10-22T13:45:00+08:00），两种都支持，但全站统一

如果实在没有可靠的更新时间字段，宁可不写 lastmod，也不要写假的。缺失不会受罚，撒谎会。

五、哪些 URL 不该进 sitemap

sitemap 里塞垃圾 URL，比不提交更糟。以下这些不要放进去：

1. 带参数的筛选/排序页（?sort=hot&page=2）
2. 搜索结果页（/search?q=xxx）
3. 分页的第 2 页之后（除非分页页本身有独立价值）
4. 返回 404/301 的 URL（会直接报错，拉低整个文件的信任度）
5. 被 noindex 的页面（自相矛盾，等于告诉搜索引擎两个相反的事）
6. 内容重复的页面（canonical 指向别处的）

第五条最常被忽略。很多人一边在页面里加 noindex，一边把同一个 URL 放进 sitemap，然后困惑为什么收录没变化。

六、提交频率：不是越勤越好

「每天重新提交一次 sitemap」是流传很广的一个错误做法。

实际上：

• 文件内容变了才需要重新提交（或者等搜索引擎自己按 lastmod 来重抓）
• 频繁提交同一个没变的文件，不会加快抓取，只会浪费配额
• 大多数搜索引擎对单个站点的 sitemap 抓取有自己的频率安排，你提交得再勤也改不了

合理的做法：

站点类型	重新生成频率	提交方式
日更内容站	每天（自动生成）	只在 GSC/资源平台登记一次，后续自动读取
导航/目录站	每周	同上
企业站	每月或内容变更时	同上

关键点：地址固定，内容自动更新。提交一次之后，搜索引擎会按自己的节奏来读。你不需要每次手动提交。

七、三个诊断动作

1. 看 sitemap 报告的错误类型

Search Console 和百度资源平台都会列出：格式错误、404、被 robots 屏蔽、被 noindex。每类错误指向不同的问题，逐个修。

2. 对比「已提交」和「已编入索引」

这个比值是判断内容质量的间接指标。比值低于 50% 通常意味着：页面太薄、内容重复、或者内链不足。这时候该修的是内容，不是 sitemap。

3. 抽样验证 lastmod 是否可信

随便挑 10 个 URL，看 sitemap 里的 lastmod 和页面上显示的更新日期是否一致。不一致说明生成逻辑有 bug。

八、一个最小可用的清单

• 有一个 sitemap_index.xml，按内容类型拆成 4-6 个子文件
• 每个子文件的 URL 数不超过 5 万，体积不超过 50MB
• lastmod 来自数据库更新时间，不是生成时间
• 不含 noindex 页、不含参数页、不含 301/404
• 地址固定，在 GSC 和百度资源平台各登记一次
• 每季度看一次错误报告，清理失效 URL

这些做完，sitemap 这一块就不会再拖后腿了。它本来也不该是个需要反复折腾的东西——一次做对，长期受益。