XML Sitemap 怎么做：该提交哪些 URL（2026）
XML Sitemap 不是越全越好。本文讲清哪些 URL 应该提交，哪些不该进 sitemap，以及提交后怎么验证。
// 相关文章
XML Sitemap 不是越全越好。本文讲清哪些 URL 应该提交，哪些不该进 sitemap，以及提交后怎么验证。
很多网站一提 XML Sitemap，就默认它是 SEO 基础动作，必须有，而且越全越好。这个判断不算完全错，但经常太粗。因为 Google 对 sitemap 的态度其实一直很明确：它是一个帮助发现 URL 的工具，不是收录保证书，也不是排名按钮。站内结构本身清楚，很多页 Google 也能自己找到；站内结构混乱，光把 URL 塞进 sitemap 也救不了根本问题。
所以，XML Sitemap 真正值得讲的，不是“要不要有”，而是三件事：什么时候它真的有用，应该把哪些 URL 放进去，哪些看起来像规范做法的字段其实 Google根本不看。尤其在 2025-2026 这种更强调抓取效率、URL 治理和页面质量的环境下，sitemap 更像一个治理工具，而不是礼仪动作。
这篇文章就只讲一个问题：XML Sitemap 到底该怎么做，哪些站值得认真维护，哪些 URL 不该放进去，`lastmod` 应该怎么用，大站又该什么时候拆分 sitemap index。把这些判断做清楚，比“网站上线先生成一个 sitemap.xml”更有用。
先把这个结论定住。Google 在 What is a sitemap 和 Build and submit a sitemap 里讲得很清楚：sitemap 可以帮助 Google 更高效地发现你认为重要的 URL，但它不保证这些 URL 一定会被抓取或收录。
也就是说，sitemap 更像“我建议你优先看这些 URL”，不是“我提交了你就必须收”。如果页面本身质量差、规范化混乱、重复严重、根本不值得索引，放进 sitemap 也不会把坏页变好页。
| sitemap 能做什么 | sitemap 不能做什么 | 更适合怎么理解 |
|---|---|---|
| 帮助发现 URL | 不保证一定收录 | 是发现层工具 |
| 提示哪些 URL 更重要 | 不直接提升排名 | 是抓取辅助信号 |
| 帮助提交大站和复杂站的 URL 集 | 不能替代站内链接结构 | 要和内链一起用 |
不是每个站都同样依赖 sitemap。Google 官方给的判断很务实：如果站点很大、很新、外链少、媒体内容多，或者有些重要 URL 不容易靠普通内链被发现，那么 sitemap 会更有用。反过来，如果站点很小、结构清楚、重要页都能通过导航和内链稳定到达，sitemap 当然还是可以有，但它不是决定性的。
Google 在文档里甚至直接说了一个很实用的边界：大约 `500` 页以内、而且站内链接做得清楚的小站，可能并不强依赖 sitemap。这个判断不是鼓励你删掉 sitemap，而是提醒你别把它当成第一优先级。相关边界在 sitemap overview 里本来就讲得很直白。
| 网站类型 | sitemap 的重要性 | 原因 |
|---|---|---|
| 新站、外链少 | 高 | Google 发现路径本来就少 |
| 大站、URL 多 | 高 | 靠普通内链更容易漏页 |
| 图片/视频较多 | 中高 | 扩展 sitemap 更容易帮助发现媒体资源 |
| 小站、结构清楚 | 中 | 有益，但不是唯一依赖项 |
很多站点的问题，不在于缺 sitemap，而在于 sitemap 太脏。比如把参数页、标签页、搜索结果页、分页变体、canonical 指向别处的页、`noindex` 页、软 404 页统统塞进去。这样做的结果，不是“提交更全”，而是向 Google 反复提交低价值 URL。
Google 在 build sitemap 文档里写得很直接：你应该在 sitemap 里列出你希望出现在搜索结果里的 canonical URL。这个口径其实已经够用了。凡是不想让它成为结果页的 URL，就别往 sitemap 里硬塞。
这也是为什么 sitemap 治理，最好和 Index Bloat、参数 URL 治理、Canonical 冲突 放在一起看。你提交给 Google 的 URL 集，本身就代表你对站内价值页的判断。
如果要把 sitemap 做干净，这个判断必须先有。通常不建议放进去的，包括：
换句话说，sitemap 不是“站内存在过的所有 URL 清单”，而应该更接近“当前值得被 Google 发现和考虑收录的 URL 清单”。
这个点很重要。Google 在 build sitemap 文档里明确说明：它会使用 `
更稳的做法是：只有页面发生了真正重要的变化，才更新 `
| 页面变化 | 适不适合更新 lastmod | 原因 |
|---|---|---|
| 主内容明显更新 | 适合 | 对用户和搜索结果都有实际影响 |
| 结构化数据或重要内链调整 | 适合 | 页面理解信号发生变化 |
| 仅改页脚年份 | 不适合 | 不属于显著内容更新 |
| 自动重新生成文件但内容没变 | 不适合 | 会降低 lastmod 的可信度 |
很多旧教程还在讲 sitemap 里要认真填 `priority`、`changefreq`。但 Google 的 build sitemap 文档已经写得很清楚：Google 会忽略这两个值。也就是说，这两个字段不是今天做 sitemap 优化的重点。
真正值得花时间的，不是猜“首页优先级该填 1.0 还是 0.8”，而是把 URL 集做干净，把 canonical 关系做清楚，把 `
如果 sitemap 很大，或者 URL 类型很多，拆分 sitemap index 就很有必要了。Google 官方的限制很明确：单个 sitemap 最多 `50,000` 个 URL，或者 `50MB` 未压缩大小。超过这个边界，就该拆分。这个限制和拆分方式，在 large sitemaps 文档里写得很清楚。
更实用的做法，通常不只是因为超限才拆，而是按 URL 类型拆。比如：
这样做的好处，不只是满足上限，还方便你在 Search Console 里分开看不同 URL 集的提交和索引状态。Google 在 sitemap index file 文档里，也给了这条路。
WordPress、Shopify、Wix 这类 CMS 确实通常会自动生成 sitemap。Google 也在文档里提到，很多 CMS 已经会帮你完成这一层。但自动生成，不等于自动正确。尤其当站点本身会生成大量标签页、筛选页、参数 URL、作者归档、空分页时，CMS 自动 sitemap 也可能把不该提交的 URL 一起带进去。
所以更稳的做法不是“有就行”，而是至少周期性抽查：
这一步和 Search Console 周报工作流 放在一起做，很适合。
如果站点的图片、视频本身就是搜索入口，单独处理媒体 sitemap 会更有意义。Google 在 image sitemaps 文档里就讲得很清楚：如果图片比较难靠普通 HTML 被发现，image sitemap 能提供额外帮助。视频、新闻也有类似的扩展做法。
但前提还是一样：只有这些媒体资源本身值得被发现、页面也希望出现在搜索里，扩展 sitemap 才有意义。不是所有站都需要一上来把所有扩展都堆满。
sitemap 提交上去以后，不要停在“已成功提交”这一步。更有用的观察方式，是看它有没有在帮你更快发现和管理 URL。最常见的检查点包括：
如果 sitemap 里列了一大堆页，但 Search Console 里长期显示这些页都被排除、被 canonical 到别处、被判低价值，那问题就不在提交动作，而在 URL 集本身。
如果只给企业站一套更实用的顺序，我会更建议这样做：
这套顺序的重点，不在“生成一个文件”，而在“把你希望 Google 优先看的 URL 集治理清楚”。
很多人把 sitemap 当作技术附件。其实不是。你把哪些 URL 放进去，哪些不放，本身就在暴露一件事：你到底知不知道自己站里哪些页值得被发现，哪些页只是系统噪音。
真正有用的 sitemap，不是最大、最全、最花哨，而是干净、准确、可信。把这三件事做好，sitemap 才会成为抓取和索引的助力，而不是另一层混乱来源。
