文章目录
- [从零配置 Google Search Console 并提交 Sitemap：完整实操与原理](#从零配置 Google Search Console 并提交 Sitemap：完整实操与原理)
-
- 一、开始前先检查网站
- 二、添加网站资源
-
- [Domain 和 URL prefix 有什么区别？](#Domain 和 URL prefix 有什么区别？)
- [三、通过 Cloudflare DNS 验证所有权](#三、通过 Cloudflare DNS 验证所有权)
-
- [DNS TXT 验证的原理](#DNS TXT 验证的原理)
- 补充说明
- 四、进入资源面板
- [五、提交 sitemap](#五、提交 sitemap)
-
- [Sitemap 的原理](#Sitemap 的原理)
- [六、理解"URL is not on Google"](#六、理解“URL is not on Google”)
- 七、先测试实时页面，再请求索引
- 八、提交完成后该做什么？
- 九、常见误区
-
- [误区 1：Sitemap 显示 Success 就是收录成功](#误区 1：Sitemap 显示 Success 就是收录成功)
- [误区 2：把所有页面逐一 Request indexing 会更快](#误区 2：把所有页面逐一 Request indexing 会更快)
- [误区 3：验证后可以删除 DNS TXT 记录](#误区 3：验证后可以删除 DNS TXT 记录)
- [误区 4：Search Console 会自动修复 SEO](#误区 4：Search Console 会自动修复 SEO)
- 总结
- 参考资料
从零配置 Google Search Console 并提交 Sitemap：完整实操与原理
网站上线并不代表 Google 会立刻发现和收录它。对于一个新站，比较稳妥的做法是：先确保页面允许抓取，再用 Google Search Console 验证网站所有权、提交 sitemap，最后对首页做一次实时检测和索引请求。
本文以 example.com 为例，记录一套实际完成并验证成功的流程。域名 DNS 由 Cloudflare 托管，网站已经具备可索引页面、canonical URL、开放抓取的 robots.txt 和 XML sitemap。
提醒：Search Console 和 sitemap 能帮助 Google 发现、抓取和诊断页面，但不能保证收录，更不能保证排名。
一、开始前先检查网站
在进入 Search Console 前，至少确认以下地址可以公开访问：
text
https://你的域名/
https://你的域名/robots.txt
https://你的域名/sitemap.xml有些框架会生成 sitemap index，例如本文使用的是：
text
https://example.com/sitemap-index.xml同时检查：
- 正式页面返回 HTTP 200；
- 页面没有
noindex； robots.txt没有用Disallow: /屏蔽全站；- sitemap 中使用完整的 HTTPS canonical URL；
- HTTP、
www等非首选地址会永久跳转到首选域名。
这些条件决定 Googlebot 能否抓取和理解网站。Search Console 只是管理与诊断入口，不能替网站修复抓取限制。
二、添加网站资源
登录 Google Search Console，点击 Add a website。
随后会看到两种网站资源：Domain 和 URL prefix。
本文选择 Domain，并且只填写根域名：
text
example.com不要加 https://，不要加路径，也不必加 www。
Domain 和 URL prefix 有什么区别？
Domain Property 会汇总这个域名下的所有协议和子域名，例如：
http://example.comhttps://example.comhttps://www.example.com- 将来可能增加的其他子域名
URL-prefix Property 只覆盖所填写的精确协议与前缀。例如填写 https://example.com/，并不会自动覆盖 http://example.com/ 或 https://www.example.com/。
因此，对自己完整控制的独立域名，Domain Property 通常更省事。它的代价是只能通过 DNS 验证，因为 Google 需要证明你控制的是整个域名，而不只是某个网页目录。Google 对两种资源类型的官方说明
三、通过 Cloudflare DNS 验证所有权
创建 Domain Property 后，Search Console 会要求通过 DNS 记录验证域名所有权。因为本例域名由 Cloudflare 管理，Google 能识别服务商并提供自动验证。
点击 Start verification 后，会跳转到 Cloudflare 授权页。页面明确显示：这是一次性授权，Google 将为指定域名添加一条 DNS-only TXT 记录，不获得未来继续修改 DNS 的权限。
确认域名、记录类型和授权范围无误后，点击 Authorize 。随后 Search Console 返回 Ownership verified。
DNS TXT 验证的原理
DNS 是域名的公开分布式记录系统。能够在权威 DNS 中添加指定 TXT 内容，通常意味着操作者控制这个域名的 DNS 配置。Google 查询到匹配的 google-site-verification=... 记录后，便将对应 Google 账号认定为该 Search Console 资源的已验证所有者。
TXT 记录不负责网站流量转发，也不会替换现有的 A、AAAA、CNAME、MX 等记录。因此，正确添加这条记录不会改变网站访问和邮件路由。
验证完成后不要删除该 TXT 记录。Google 可能定期复查所有权；删除验证方式可能导致权限丢失。Google 所有权验证说明
补充说明
域名解析不只是"把域名指向服务器 IP"，而是一个可以存放多种公开记录的查询系统。Google 不是通过网页访问这段文本，而是直接向 DNS 查询。
例如 Google 查询：
text
example.com 的 TXT 记录是什么？权威 DNS 服务器可能返回：
text
google-site-verification=abc123...常见 DNS 记录包括：
A：域名 → IPv4 地址AAAA：域名 → IPv6 地址CNAME：域名 → 另一个域名MX：邮件服务器TXT：任意短文本，常用于所有权验证和邮件安全配置
所以这里实际上有两条独立路线：
text
访问网站：
域名 → 查询 A/AAAA → 得到服务器 IP → 请求网页
验证域名：
域名 → 查询 TXT → 得到验证码 → 与 Google 发给你的验证码比较TXT 记录是公开可查询的。任何人都能读取它，但通常只有控制该域名 DNS 配置的人才能添加或修改它。类似于 Google 先给你一张随机纸条，然后让你把纸条放进一个"人人看得到、但只有管理员能放东西"的展示柜里。
例如在命令行中可以查询：
bash
nslookup -type=TXT example.comGoogle 做的本质上也是类似的 DNS 查询，并不需要访问你的网站，也不要求网站服务器正常运行。
四、进入资源面板
点击 Go to property 后进入新资源面板。新资源通常暂时没有 Performance 或 Indexing 数据，页面会提示稍后再检查。
这是正常现象。Search Console 的报表不是实时日志；Google 需要先发现、抓取并处理页面，然后才会逐渐产生覆盖率、查询、展示和点击数据。
五、提交 sitemap
在左侧进入 Indexing → Sitemaps，将完整 sitemap 地址填入输入框：
text
https://example.com/sitemap-index.xml
点击 Submit。如果 Google 能读取该文件，会先显示提交成功。
关闭弹窗后，在 Submitted sitemaps 表格中确认状态。本例显示：
- Type：Sitemap index；
- Status：Success；
- Submitted 与 Last read 均有日期；
- 刚提交时 Discovered pages 为 0。
Sitemap 的原理
Sitemap 是站点主动提供给搜索引擎的 URL 清单。它帮助 Googlebot 更高效地发现新页面和更新后的 canonical 页面，尤其适合刚上线、外部链接很少的网站。
Sitemap index 则是一份"sitemap 的目录"，可以指向一个或多个实际 sitemap。网站规模扩大时，可以按内容类型或数量拆分多个 sitemap，而 Search Console 只需提交 index。
需要注意：
- sitemap 是发现提示，不是收录命令；
Success表示 Google 成功读取文件，不表示里面的每个 URL 都已收录；- sitemap 应只列出希望进入搜索结果的 canonical URL；
- Google 官方限制单个 sitemap 最多 50,000 个 URL、未压缩不超过 50 MB；更大的网站应拆分并使用 sitemap index。
六、理解"URL is not on Google"
提交 sitemap 后立即检查首页，很可能看到 URL is not on Google ，并显示 URL is unknown to Google、Last crawl 为 N/A。
对刚上线的新站来说，这通常只表示 Google 的索引系统还没有抓取和处理该 URL，而不是页面配置错误。这里展示的是 Google 当前索引库中的历史状态，并不等同于网站此刻的实时状态。
七、先测试实时页面，再请求索引
点击 Test live URL 后，Google 会临时抓取当前页面并检查是否存在明显的索引障碍。本例测试结果是：
- URL is available to Google；
- Page can be indexed。
实时测试通过后，可以点击 Request indexing，把首页加入优先抓取队列。
实时测试与索引请求分别做了什么？
Google Index 结果 读取 Google 已经保存的索引状态；Live Test 则临时访问当前网页，检查 HTTP 响应、抓取许可和页面是否具备被索引的基本条件。实时测试通过只能说明"可以被索引"，不代表"已经被索引"。
Request indexing 会把该 URL 放入抓取队列，但不会立即收录，也不能保证最终收录。Google 仍会根据内容质量、重复性、canonical 判断、网站信誉及其他系统信号决定是否索引。
Google 对单 URL 请求设有限额，重复请求同一页面不会提升优先级。少量关键页面可使用 URL Inspection；大量页面应依靠 sitemap。URL Inspection 官方说明、请求重新抓取的官方说明
八、提交完成后该做什么？
本例完成时的状态是：
- Domain Property 所有权验证成功；
- sitemap index 提交成功并被读取；
- 首页实时测试确认可以索引；
- 首页索引请求已进入优先抓取队列；
- sitemap 的初始 Discovered pages 仍为 0。
接下来不需要重复点击提交。可以按以下节奏观察：
- 24--48 小时后查看 Sitemaps 中的 Discovered pages；
- 3--7 天后查看 Pages 报告中的抓取与索引状态；
- 查看 Performance 是否开始出现展示次数和搜索查询；
- 如果一周后仍完全没有发现或抓取，再检查 robots、
noindex、HTTP 状态、canonical、sitemap URL 和服务器可访问性。
Google 明确说明，抓取可能需要几天到几周，提交 sitemap 或索引请求都不保证收录。Google 抓取与索引常见问题
九、常见误区
误区 1：Sitemap 显示 Success 就是收录成功
不是。Success 只说明 sitemap 文件可以读取和解析。真正的收录情况要看 Pages 报告或具体 URL 的 Google Index 状态。
误区 2：把所有页面逐一 Request indexing 会更快
没必要。单 URL 请求有配额，重复请求不会加速。为首页或少数关键更新页请求一次即可，其余交给 sitemap 和站内链接。
误区 3：验证后可以删除 DNS TXT 记录
不建议。该记录是持续证明所有权的依据之一，删除后可能失去已验证所有者身份。
误区 4：Search Console 会自动修复 SEO
Search Console 负责呈现 Google 看到的状态、问题和搜索表现。页面质量、信息架构、内部链接、内容更新、响应速度和技术 SEO 仍然需要网站自己负责。
总结
整套流程背后其实是四个独立环节：
- 所有权：通过 DNS TXT 证明你控制整个域名；
- 发现：通过 sitemap 告诉 Google 哪些 canonical URL 值得抓取；
- 可抓取性：通过 Live Test 确认 Googlebot 当前能够访问且未被阻止；
- 处理队列：通过 Request indexing 为少数关键 URL 发出抓取请求。
完成这四步，只代表网站已经把技术入口准备好。是否收录以及获得怎样的排名，最终仍取决于 Google 的处理结果和网站持续提供的实际价值。