📖 11 分钟阅读

如何把 sitemap 提交到 Google Search Console（2026）

分步操作：验证站点所有权、提交 sitemap.xml、请求编入索引，并修复「无法获取」状态。

  • Google Search Console
  • Sitemap
  • Indexing

你把站点上线了。页面能访问，HTML 干净，内容也不错。可 site:yourdomain.com 却什么都搜不到。Google 根本不知道你的存在。

sitemap 就是你交给 Google 的一份机器可读的 URL 清单，告诉它你希望哪些页面被抓取。通过 Google Search Console（GSC）提交 sitemap，等于在告诉 Google「这是我站点的权威清单——从这里开始」。它并不能保证页面被编入索引，但能消除「被发现」这个环节的难题——而对一个全新站点来说，这恰恰是最慢的一步。

本指南是面向开发者的实操版：验证所有权、提交 sitemap、为重要页面请求编入索引、看懂那个让人困惑的 Couldn't fetch 状态，并把 sitemap 写进 robots.txt，让每个爬虫都能找到它。没有废话，全是真实命令。

🧑‍💻 开发者视角：sitemap 不过是一份 XML 文档，里面是一串 <loc> URL，外加可选的 <lastmod> 提示。GSC 则是架在 Google 抓取/索引流水线之上的一块仪表盘。提交 sitemap 是一个类似 POST 的「这是我的 URL 列表」信号——没什么魔法，你只是缩短了从「页面存在」到「Googlebot 抓取它」之间的路径。

验证所有权

在 GSC 给你看任何数据之前，你得先证明你拥有这个站点。GSC 提供两种资源类型（property type），怎么选很关键，因为它同时决定了你如何验证、以及你能看到哪些数据。

网域资源（Domain property）网址前缀资源（URL-prefix property）
覆盖范围所有子域 + http/https仅一个精确来源
范围示例example.com、www.、blog.，http 与 https仅 https://example.com/
验证方式DNS TXT 记录HTML 标签、HTML 文件、GA、GTM 或 DNS
在 *.pages.dev 上是否可用否（无法编辑 DNS）是
适用场景你掌控 DNS 的站点子域、快速上手、更细粒度的数据

网域资源通过一条 DNS TXT 记录验证，验证后覆盖该网域下的一切——每个子域、两种协议。前提是你拥有该 DNS 区域，否则它就是最干净利落的选项。GSC 会给你一个待添加的令牌：

# Add this as a TXT record on the apex (@) of your zone
google-site-verification=AbC123dEf456GhI789jKl0mNoPqRsTuVwXyZ_example

在大多数注册商或 Cloudflare DNS 上，你会这样添加：

Type:  TXT
Name:  @            (or yourdomain.com)
Value: google-site-verification=AbC123...
TTL:   Auto

在 GSC 里点「验证」之前，先确认它已经生效：

dig +short TXT yourdomain.com | grep google-site-verification
# or
nslookup -type=TXT yourdomain.com

网址前缀资源验证的是单个精确来源（协议 + 主机 + 末尾斜杠全都算数——https://example.com/ 和 https://www.example.com/ 是不同的资源）。你可以用好几种方式验证它，全程不碰 DNS：

<!-- Option A: meta tag in the <head> of your homepage -->
<meta name="google-site-verification" content="AbC123dEf456GhI789jKl0..." />
# Option B: upload a verification file to the site root
# GSC gives you something like: google1234567890abcdef.html
# It must be reachable at:
https://example.com/google1234567890abcdef.html

验证之前，先确认这个文件确实被对外提供：

curl -sI https://example.com/google1234567890abcdef.html | head -n 1
# Expect: HTTP/2 200

⚠️ pages.dev（以及类似的 *.vercel.app、*.netlify.app、*.workers.dev）陷阱：对于一个你并不掌控其 DNS 的子域，你无法创建网域资源。pages.dev 这个区域不属于你——它属于 Cloudflare——所以在那一层根本没有你能添加的 TXT 记录。对于预览/预发布子域，请改用网址前缀资源，并用 HTML meta 标签或上传文件来验证。等你把站点搬到自己的自定义域名上之后，再切换到（或额外添加）网域资源。

对于大多数跑在自定义域名上的生产站点，用网域资源。对于 *.pages.dev URL 或任何平台子域，用网址前缀资源，配合文件/meta 验证。

提交你的 sitemap

如果你的构建会生成一个 sitemap 索引（大多数框架都会——例如 Astro 的 sitemap 集成会输出一个 sitemap-index.xml，指向一个或多个 sitemap-0.xml 分片），那你要提交的是这个索引，而不是各个单独文件。Google 会顺着索引读取它的每一个子文件。

首先，做一次基本检查，确认文件确实在线且格式正确：

curl -s https://example.com/sitemap-index.xml | head -n 20
# Should return XML, not an HTML 404 page

# Check the status code and content type explicitly
curl -sI https://example.com/sitemap-index.xml | grep -iE 'HTTP/|content-type'
# Expect:
#   HTTP/2 200
#   content-type: application/xml   (or text/xml)

一个合法的 sitemap 索引长这样：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-0.xml</loc>
    <lastmod>2026-06-23T00:00:00.000Z</lastmod>
  </sitemap>
</sitemapindex>

然后在 GSC 里：

  1. 打开 Search Console → 你的资源 → 索引 → Sitemap（左侧边栏）。

  2. 在 添加新的站点地图 字段里，输入相对于资源根目录的路径。对大多数站点来说就是 sitemap-index.xml。GSC 会预填好域名，你只需输入路径：

    sitemap-index.xml

  3. 点击 提交。

  4. 这一行会出现，状态为 成功（一开始往往是一个临时状态——见下一节）。点击该行可查看 Google 发现了多少个 URL。

💡 索引文件只提交一次，不要逐个提交子文件。Google 会按自己的节奏重新读取它，所以你发布新页面时根本无需重新提交——你的构建只管重新生成 XML，Google 会在下一轮抓取时拾取新的 <loc> 条目。

请求编入索引

提交 sitemap 会把你的 URL 送进 Google 的发现队列。对于你最在意的少数几个页面（首页、关键落地页、你最好的内容），你可以用 网址检查（URL Inspection） 工具直接推 Google 一把：

  1. 把完整 URL 粘贴进 GSC 最顶部的搜索栏（标注为「检查……中的任意网址」）。
  2. GSC 会从它的索引里获取该 URL，并显示它是否已被编入索引。
  3. 点击 测试实际网址，确认 Google 能抓取当前版本（这一步还会暴露出渲染问题、robots 屏蔽以及 noindex 标签）。
  4. 如果一切正常，点击 请求编入索引。这会把该 URL 加入一个优先抓取队列。
Inspect:  https://example.com/                 → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/pricing           → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/blog/launch-post  → "URL is not on Google" → Request Indexing

⚠️ 请求编入索引有速率限制（每天有一个不大的配额），它是为单个重要 URL 准备的——而不是用来给一个 5000 页的站点强行灌料的。批量场景下，sitemap 才是正确的工具；让大规模抓取自己发生就好。手动请求是留给眼下最要紧的那 5 到 20 个页面的。

「无法获取」通常是虚惊一场

新站点站长最常见的那个恐慌时刻：你提交了 sitemap-index.xml，刷新一下，状态写着 Couldn't fetch。在你动手重写 XML 之前，先记住这一点：刚提交完时，这个状态往往是临时的。Google 已经把抓取排进了队列，但还没真正取回并处理它，于是仪表盘显示了一个占位状态。在很大一部分情况里，它会在几小时到一两天内自动翻成 Success，你这边什么都不用改。

所以第一步实实在在就是：等 1 到 3 天，再回来看一眼。

话虽如此，如果它一直不消失，就走一遍这份清单——这些才是真正的成因，而且每一条都能在你的终端里验证：

  • 返回 200。 sitemap URL 必须以 200 OK 响应，而不是一串重定向、403、404 或 5xx。

    curl -sI https://example.com/sitemap-index.xml | head -n 1
# HTTP/2 200   = good   |   anything else (301/302/403/404/5xx) is a problem

  • 正确的 content type。 提供 application/xml 或 text/xml。如果你的服务器发回的是 text/html（当返回的是 SPA 回退页或 404 页面而非该文件时很常见），Google 可能会拒收。

    curl -sI https://example.com/sitemap-index.xml | grep -i content-type
# content-type: application/xml   = good
# content-type: text/html         = bad (you're serving an HTML page, not the sitemap)

  • robots.txt 没有屏蔽它。 一条多余的 Disallow: /sitemap 或一条过于宽泛的规则，都可能阻止 Googlebot 读取该文件。把你的 robots 取下来读一读：

    curl -s https://example.com/robots.txt
# Make sure nothing disallows the sitemap path for Googlebot

  • 没有协议 / 主机不匹配（跨源陷阱）。 sitemap 里的每一个 <loc> 必须与资源、以及 sitemap 文件本身处于同一协议和同一主机之下。如果你的资源是 https://example.com 这个网址前缀，而你的 <loc> 条目却写着 http:// 或 www.example.com，Google 会把它们当作跨站点而忽略掉。抽查几条：

    curl -s https://example.com/sitemap-0.xml | grep -oE '<loc>[^<]+' | head
# Every URL should start with https://example.com/ — no http://, no bare www mismatch

  • sitemap 路径上没有 noindex / 鉴权墙。 预发布站点常常藏在 HTTP basic auth 或一条 Cloudflare Access 策略后面。如果 sitemap 需要登录，Googlebot 会拿到 401/403，从而无法获取它。

如果这五项全部通过，状态过了一周还是不肯转好，那就在网址检查里对 sitemap URL 用一次 测试实际网址——它会把 Googlebot 看到的确切响应展示给你，通常能立刻定位到问题所在。

多久才会被编入索引

把预期摆正，因为不耐烦会让人去「修」那些根本没坏的东西：

站点状况首批页面被编入索引的典型耗时
全新域名，没有外链几天到数周
在一个成熟、被频繁抓取的站点上发布的新页面几小时到几天
大型站点，内容稀薄或重复缓慢 / 部分——Google 可能会跳过页面

一旦 sitemap 提交了，发现（Google 知道这个 URL 存在）就很快。编入索引（Google 抓取、渲染、评估，并决定存储该页面）才是耗时的部分，而且它是一个关于质量与信任的决定，不只是排队那么简单。一个没有外链、没有历史记录的全新域名，优先级天然就靠后——这是正常现象，不是 bug。持续发布、攒到几条外链，抓取频率自然会上升。

💡 「页面」报告里的「已发现 - 尚未编入索引」和「已抓取 - 尚未编入索引」并不是错误。它们的意思是 Google 找到了（或抓取了）该 URL，但还没决定把它编入索引——在新站点上，这通常是内容稀薄或优先级偏低的信号。与其反复重新提交，不如改进页面或去争取外链。

把它从 robots.txt 里链接出去

GSC 提交只告诉了Google。在 robots.txt 里加一行 Sitemap:，则是在告诉每一个爬虫——Bing、DuckDuckGo，以及任何尊重该标准的程序——而无需逐个引擎去对应的仪表盘里操作。这是一招一行搞定的双保险，也是宣告 sitemap 的权威做法。

# robots.txt
User-agent: *
Allow: /

# Absolute URL, one per line; you can list multiple sitemaps
Sitemap: https://example.com/sitemap-index.xml

几条容易让人栽跟头的规则：

  • Sitemap: 后面的 URL 必须是绝对路径（完整的 https://...），而不是相对路径。
  • 它与 User-agent 块互不相干——放在文件里任何位置都行，习惯上放在顶部或底部。
  • 如果你按板块或语言拆分了多个 sitemap，可以列出多行 Sitemap:。

确认它已生效：

curl -s https://example.com/robots.txt | grep -i sitemap
# Sitemap: https://example.com/sitemap-index.xml

🧑‍💻 我们在本站是这么做的：就是这套配置——自动生成的 sitemap-index.xml、robots.txt 里的一行 Sitemap:、GSC 里的一个网域资源，再加上为基石页面做的几次请求编入索引的推动。如果你想在不手改 XML 的前提下生成干净的 robots.txt 与 sitemap 条目，我们的 robots 与 sitemap 工具 能替你搞定。等 Google 开始抓取后，我们关于 日志分析与抓取预算 的指南会教你如何确认 Googlebot 真的在抓取你 sitemap 所宣告的那些 URL。

小结

整个流程，按顺序排：

  1. 验证所有权——掌控 DNS 就用网域资源（DNS TXT）；pages.dev 及其他平台子域则用网址前缀资源（HTML 标签/文件）。
  2. 在 索引 → Sitemap 下提交 sitemap-index.xml。 提交索引，别提交子文件。
  3. 通过网址检查，为你最重要的 5 到 20 个 URL 请求编入索引。
  4. 别被 Couldn't fetch 吓到——先等 1 到 3 天，然后走一遍 200 / content-type / robots / 跨源 / 鉴权 这份清单。
  5. 有点耐心——发现很快，给一个新域名编入索引则要几天到数周。
  6. 在 robots.txt 里加一行 Sitemap:，好让每个爬虫都能找到它。

下一步：用 robots 与 sitemap 工具 生成你的 robots.txt 与 sitemap 配置，然后用 抓取预算指南 在服务器日志里观察 Googlebot 的行为。提交只是与 Google 对话的开始——日志才会告诉你它到底有没有在听。