Google Sitemap 创建与提交实战指南

💡 核心摘要：Sitemap 的质量取决于三个核心：格式适合网站，URL 是希望出现在搜索结果中的规范 URL，元数据真实可验证。Google 支持 XML、RSS/Atom 和文本 Sitemap；单个 Sitemap 不得超过 50MB（未压缩）或 50,000 个 URL；提交后也只是给 Google 一个提示，不保证抓取或索引。

一、先选择合适的 Sitemap 格式

Google 支持多种 Sitemap 格式，包括 XML Sitemap、RSS/mRSS/Atom 1.0 Feed，以及普通文本 Sitemap。Google 对格式没有偏好，关键是选择最适合网站架构、内容类型和维护方式的格式。

XML Sitemap 最通用，可以扩展图片、视频、新闻和本地化版本信息；RSS 和 Atom 通常由 CMS 自动生成，适合提供近期更新；文本 Sitemap 最简单，每行一个 URL，但只能列网页 URL，不能携带图片、新闻或视频等扩展信息。

格式选择速查

XML：最通用，适合多数网站和扩展数据
RSS/Atom：适合 CMS 自动输出近期更新
文本 Sitemap：适合只提交网页 URL 的简单场景

💡 实操建议：如果不确定选什么，优先使用 XML Sitemap；如果 CMS 已自动生成 RSS/Atom，也可以作为补充提交。

二、Sitemap 只能放你希望展示的规范 URL

创建 Sitemap，本质上是在告诉搜索引擎你希望哪些 URL 出现在搜索结果中。这些 URL 应该是规范 URL，而不是所有可访问 URL 的合集。

如果同一内容有多个版本，例如桌面版、移动版、带参数版本、追踪参数版本、打印版或大小写不同路径，应选择你偏好的规范版本放进 Sitemap。不要把所有重复版本都提交给 Google。

推荐与不推荐

推荐：   https://www.example.com/product/seo-tool
不推荐： /product/seo-tool
不推荐： https://www.example.com/product/seo-tool?utm_source=newsletter
不推荐： https://m.example.com/product/seo-tool  （除非你已添加移动/桌面注解）

⚠️ Sitemap 中必须使用完全限定的绝对 URL。不要使用 /mypage.html 这类相对 URL。

三、遵守大小、编码和位置规则

无论使用哪种格式，单个 Sitemap 文件大小不得超过 50MB（未压缩），并且最多包含 50,000 个 URL。如果超过限制，就应拆分成多个较小的 Sitemap，并用 Sitemap index 管理。

Sitemap 文件必须使用 UTF-8 编码。文件可以托管在网站任意位置，但如果不是通过 Search Console 提交，Sitemap 通常只影响其父级目录及下级目录。因此，Google 建议将 Sitemap 放在网站根目录，以覆盖整个站点。

基础规则

单文件不超过 50MB（未压缩）
单文件不超过 50,000 个 URL
使用 UTF-8 编码
优先放在站点根目录
大型网站使用 Sitemap index

💡 如果你想在 Search Console 中分别跟踪不同内容类型的表现，可以提交多个 Sitemap 或 Sitemap index。

四、XML Sitemap 是默认主力格式

XML Sitemap 是最灵活的格式，适合大多数网站。它不仅能列出 URL，还能通过扩展提供图片、视频、新闻和多语言版本信息。

一个最小 XML Sitemap 可以非常简单：包含 XML 声明、urlset 根节点、每个 URL 的 loc，以及可选但很有价值的 lastmod。

XML 示例

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/foo.html</loc>
    <lastmod>2026-05-09</lastmod>
  </url>
</urlset>

⚠️ XML 中的标记值必须正确转义。比如 URL 里的 & 需要写成 &。

五、正确使用 lastmod

lastmod 是 Sitemap 中最容易被滥用的字段。Google 表示，如果 lastmod 始终准确且可验证，可能会使用这个值。它应反映页面最后一次重大更新的日期和时间。

什么算重大更新？正文主要内容、结构化数据、页面内重要链接、核心信息发生变化，通常可以算。只改版权年份、页脚、广告脚本或无关模板细节，不应更新 lastmod。

lastmod 判断

应该更新：正文大幅修改、结构化数据变化、重要链接变化
不应更新：版权年份变化、无关模板变化、追踪脚本变化

⚠️ 不要每天自动把所有 URL 的 lastmod 改成今天。长期不准确会削弱这个字段的可信度。

六、Google 会忽略 priority 和 changefreq

很多旧 Sitemap 示例会包含 <priority> 和 <changefreq>。Google 明确说明会忽略这两个值。因此，不要把时间花在给页面分配优先级或更新频率上。

更值得投入的是：确保 URL 清单干净、lastmod 真实、状态码正确、Sitemap 能被访问、规范 URL 一致。这些因素比虚假的优先级更有实际意义。

💡 对 Google 来说，真实可验证的更新信号，比你声明“这个页面很重要”更可信。

七、根据网站规模选择生成方式

如果 Sitemap 只有几十个 URL，可以手动创建。但只要页面数量超过几十个，最好自动生成。大型网站更应从数据库、CMS、路由表或内容发布系统中生成 Sitemap，而不是手动维护。

自动生成时要注意过滤规则：只包含 200 状态码、允许索引、规范版本、希望展示在搜索结果中的 URL。不要混入 404、重定向、草稿页、参数页、测试页或被 noindex 排除的页面。

生成过滤规则

状态码为 200
不是重定向
不是 noindex
是规范 URL
内容可公开访问
希望进入搜索结果

⚠️ URL 顺序对 Google 不重要。不要为了排序浪费工程复杂度，优先保证清单质量。

八、提交 Sitemap 的几种方式

Google 支持多种提交方式。最常用的是在 Search Console 的 Sitemap 报告中提交，这样可以看到 Googlebot 何时访问了 Sitemap，以及是否有处理错误。

你也可以使用 Search Console API 程序化提交，或在 robots.txt 中加入 Sitemap 路径。对于 RSS 或 Atom，还可以通过 WebSub 广播更新。

robots.txt 示例

Sitemap: https://example.com/my_sitemap.xml

💡 提交 Sitemap 只是提示 Google：无法保证 Google 一定下载、使用或抓取其中所有 URL。

九、多站点和跨域 Sitemap 要谨慎

如果你管理多个网站，可以把多个已验证网站的 Sitemap 集中托管到一个位置，简化维护。但每个 Sitemap 文件应只包含对应网站的 URL，并在对应网站的 robots.txt 中引用正确的 Sitemap。

这种做法适合集团站、多品牌站、多语言站或统一平台托管多个域名的场景。关键是验证所有权和 URL 归属，不要把多个站点的 URL 混在一个没有清晰边界的文件里。

跨站点 robots.txt 示例

# https://example.com/robots.txt
Sitemap: https://sitemaps.example.com/sitemap-example-com.xml

⚠️ 集中托管可以提高运维效率，但不能降低 Sitemap 质量要求。每个站点仍应有干净、准确、可验证的 URL 清单。

📌 核心收获

• ✓ 格式按需求选：XML 最通用，RSS/Atom 适合近期更新，文本 Sitemap 适合简单网页清单
• ✓ 只提交规范 URL：Sitemap 应包含希望出现在搜索结果中的绝对 URL
• ✓ 遵守硬限制：单个文件最多 50MB（未压缩）或 50,000 个 URL
• ✓ lastmod 必须真实：只在页面发生重大更新时更新，避免每天批量刷新
• ✓ 提交不是保证：Search Console、API、robots.txt 都只是给 Google 提示

🚀 立刻行动

1. 打开现有 Sitemap → 检查是否使用绝对 URL → 删除相对 URL、参数 URL、重定向和 404。
2. 统计 Sitemap 文件大小和 URL 数量 → 超过 50MB 或 50,000 个 URL 时拆分并创建 Sitemap index。
3. 抽查 20 个 lastmod → 对照页面实际更新时间 → 修正每天自动刷新的错误逻辑。
4. 检查生成规则 → 只保留 200、可索引、规范、公开、希望进入搜索结果的页面。
5. 在 Search Console 提交 Sitemap → 查看是否有解析错误、读取失败或异常 URL。

来源：创建和提交站点地图 | 本文为知识提炼与重新表达