给 Google 提交 sitemap，敲键盘大概两分钟，等结果要 24 到 72 小时。难的是提交完怎么读状态：Search Console 只给三种状态（Success、Has errors、Couldn’t fetch），而且「Success」也可能掩盖一张坏掉的 sitemap。下面是完整流程，加上每种状态到底怎么看。
TL;DR
打开 Search Console 的 Sitemaps 报告，只填路径（sitemap.xml，前面不要斜杠，也不要完整 URL），点提交。24-72 小时内状态应该变成 Success，并显示一个和你实际页面数对得上的 Discovered URLs。如果显示 Couldn’t fetch，多半是 URL 填错了或者 robots.txt 把文件屏蔽了。如果 Discovered URLs 远低于你的页面数，说明生成器漏页了。提交 sitemap 不保证收录——它只是给 Google 一份干净的清单，外加一份能尽早抓出 bug 的状态报告。
提交 sitemap 到底做了什么
sitemap 是一个 XML 文件，列出你希望 Google 发现的 URL。提交它做了三件事，还有一件它不做：
- 给 Google 一份权威的、列全你站点所有 canonical URL 的清单。
- 提供一份状态报告，能抓出抓取失败、编码错误、漏页这类你平时根本看不到的 bug。
- 在新站或大站上加快发现速度——这类站点光靠内链爬起来很慢。
- 它不会强制收录。Google 对每个 URL 单独判断，看内容质量、链接和权威度。sitemap 是「这是清单」，不是「请收录这些」。
注意：Google 完全忽略 sitemap 里的 <priority> 和 <changefreq> 标签（见 Google 官方文档），别花时间调它们。<lastmod> 会被用，但前提是你填得一直准确。
什么时候需要这篇
- 刚上线，不知道 Google 有没有看到你的 sitemap。
- Search Console 显示 Couldn’t fetch。
- sitemap 报的 Discovered URLs 远少于你的实际页面数。
- 换了域名搬站、或改过 sitemap 名字，老条目还挂在列表里。
提交流程：分步走
- 确认文件存在。 浏览器打开
https://你的域名/sitemap.xml，应该返回一个列着 URL 的 XML 文档。如果 404，说明你的框架没生成——先解决这个。（Astro 的@astrojs/sitemap、Next.js 的sitemap.ts、大多数 CMS 插件都会自动生成。） - 打开 Sitemaps 报告。 在 Search Console 左侧「索引」下面点 Sitemaps。
- 只填路径。 在 Add a new sitemap 里填
sitemap.xml——前面不要斜杠，不要https://。域名已经从你的资源里自动带上了。点 Submit。 - 等 24-72 小时。 状态行几分钟就出现，但一开始常显示「Couldn’t fetch」或空白，这是正常的。过一天再看。
- 核对数量。 状态变成 Success 后，确认 Discovered URLs 和你的实际页面数对得上。站点 50 页但写 3，说明 sitemap 不全——多半是生成器 bug，或者某个草稿过滤条件忘了关。
- 抽查 3 个 URL。 再开一次 sitemap，随机挑三个 URL。能打开吗（HTTP 200）？协议和域名（
https://、www 还是裸域）和你的 canonical 一致吗？协议或主机不一致，整张 sitemap 都作废。 - 一周后对照看。 对比 Pages 报告。「Submitted」和「Indexed」几乎不会 100% 相等，但如果「Crawled - currently not indexed」或「Discovered - currently not indexed」一大堆，那是内容或权威问题，不是 sitemap 问题。
三种状态，逐个拆解
Search Console 只会给三种状态之一。这就是关键所在：
| 状态 | 含义 | 该做什么 |
|---|---|---|
| Success | 抓取并解析成功，所有 URL 进入爬取队列。 | 核对 Discovered URLs 数量。「Success」但数字不对，照样是 bug。 |
| Has errors | 抓取成功，但有一条或多条格式错误。能解析的 URL 仍进队列。 | 点进 sitemap 看具体报错行，修 XML。 |
| Couldn’t fetch | Google 最近一次 HTTP 请求没拿到文件。没有任何 URL 被处理。 | 检查 URL 是否正确、文件是否返回 200、robots.txt 有没有屏蔽。然后重新提交。 |
最坑的是 Success 但 Discovered URLs 偏低，因为表面上一切正常。永远要核对数字，别只看那个绿色标签。
修「Couldn’t fetch」
这是新站最常见的失败。按顺序排查：
- 路径填错。 确认 Sitemaps 框里是
sitemap.xml，不是页面 URL 或拼错的字符串。删掉错条目重新加。 - 文件 404 或 500。 自己打开那个 URL。如果不返回 200，说明你的构建没在那个路径输出文件。有些框架输出的是
sitemap-index.xml而不是sitemap.xml。 robots.txt屏蔽了它。 一行Disallow: /sitemap.xml（或者一刀切的 disallow）会挡住 Googlebot。用「网址检查」工具的「测试实际网址」确认能不能抓到。- 服务器慢或不稳。 Google 抓取超时也会显示「Couldn’t fetch」。等你的主机稳定后重新提交，这种情况常常几天内自己好。
这个状态和你用哪家主机无关——Vercel、Firebase、Cloudflare Pages 上都会遇到，几乎总是上面四个原因之一。
容易踩的坑
- 把完整 URL（
https://你的域名/sitemap.xml）填进只要路径的框里。有些 property 两种都接受，但填路径永远安全。 - 列了会 301、404 或带
noindex的 URL。 Google 看到信号冲突，可能降低对整张 sitemap 的信任。sitemap 里只放 canonical、可索引、返回 200 的 URL。 - 主机或协议不一致。 Domain 资源下的 sitemap 却指向
http://或别的子域，会被整张忽略。 - 搬完家忘了更新。 老 URL 会在索引报告里挂好几个月。
- 拆得太碎。 单张 sitemap 上限是 50,000 个 URL 或 50 MB（未压缩，允许 gzip）。没超就用一张。超了用 sitemap index，一个 index 最多可以引用 500 个子 sitemap。
你已经不需要 ping 端点了
老的「ping」小技巧——访问 https://www.google.com/ping?sitemap=... 来催 Google——已经在 2023 年废弃，现在返回 404（Google Search Central）。Google 发现绝大多数无认证的 ping 都是垃圾。现在支持的提交方式只有两种：Search Console 的 Sitemaps 报告，以及 robots.txt 里的一行 Sitemap:：
Sitemap: https://你的域名/sitemap.xml在 robots.txt 里列一行值得顺手做，除了 Search Console 之外——Bing 和别的爬虫也是这么找到 sitemap 的。
这篇适合谁，什么时候可以跳过
适合上线第一个月的新站、换域名搬家的站，以及 URL 超过 100、想让 Google 快速找全的站。一个总共五页、也不打算长期更新的展示站可以跳过——Google 顺着内链就能找到那五页，sitemap 不是瓶颈。
FAQ
- 提交后多久显示 Success？: 通常 24-72 小时。3 天后还显示「Couldn’t fetch」，要么 URL 填错了、要么文件没返回 200、要么
robots.txt屏蔽了它。 - sitemap 显示 Success 但页面没收录，怎么回事？: 提交不等于保证收录。sitemap 是清单，收录是 Google 对每个 URL 单独的判断，看内容、链接、权威度。去 Pages 报告看这些 URL 落在哪个「未收录」分类里。
- 每发一篇新文章要不要重新提交？: 不用。提交一次后，Google 会按自己的频率重新抓 sitemap（一般几天一次）。确保每次部署生成器都重新生成文件即可。
- 提交
sitemap_index.xml还是分开的子 sitemap？: 提交 index。Google 会自动顺着找到每个子 sitemap，你也只需盯一行，而不是几十行。 - 硬性上限是多少？: 单张 sitemap 最多 50,000 个 URL 或 50 MB（未压缩），一个 index 文件最多引用 500 张 sitemap。要求 UTF-8 编码、URL 写成完整绝对地址。
- 还能 ping Google 加速吗？: 不能。ping 端点 2023 年退役，现在返回 404。用 Search Console 和
robots.txt；单个急需的页面，用「网址检查」工具的「请求编入索引」。