在完成 A Tour of Go 简体中文站点上线、搜索引擎验证以及 Sitemap 提交之后，我原本准备继续处理 --minimal-protect。
不过在继续开发之前，我重新检查了一遍 go-dev.shuijingwanwq.com 在几个主要搜索引擎中的索引情况。
此前 Google、Bing、360 已经完成 Sitemap 提交，其中 Sitemap 共包含 104 个 URL，也就是站点首页加 103 个课程页面。百度和搜狗则没有采用同样的 Sitemap 提交流程。
最开始我的想法是：既然新站还没有明显看到收录结果，是不是应该趁现在再主动提交一次 URL，尽量缩短搜索引擎发现和索引页面的时间。
实际逐个平台检查之后，情况却比预想中更有意思。Google 已经开始正常索引；Bing 已经发现网站但还没有抓取；百度能够通过 API 主动提交，但新站每天只有很少的提交额度；搜狗则让我进一步怀疑是否值得为主动提交投入太多维护成本。
最终，这次实践没有变成“把 104 个 URL 向所有搜索引擎都提交一遍”，而是逐个平台判断投入产出比，然后决定哪些值得主动处理，哪些更适合交给搜索引擎自然抓取。
一、先检查 Google：其实已经开始正常索引
首先检查 Google Search Console。
一开始，“网页索引编制”汇总页面仍然显示正在处理数据，需要稍后再查看，所以单纯看汇总数据很容易产生“Google 还没有开始收录”的感觉。
于是我改用网址检查工具，直接检查具体页面。
除了首页之外，我还检查了课程列表：
https://go-dev.shuijingwanwq.com/tour/list
结果显示：
- 网址已收录到 Google；
- 网页已经编入索引；
- Googlebot 抓取成功；
- 页面允许抓取；
- 页面允许编入索引。
/tour/list 已经正式编入索引】更值得注意的是，引荐来源中已经出现了其他课程页面，例如：
/tour/flowcontrol/2
/tour/moretypes/5
这说明 Google 并不是只发现了站点首页，而是已经开始顺着站点内部链接发现和处理整个课程体系。
因此 Google 这一边没有继续进行人工“请求编入索引”。
既然 Sitemap、内部链接和正常抓取链路已经开始工作，那么继续人工干预的意义并不大。
二、Bing 的情况不同：已经发现，但还没有爬网
接下来检查 Bing Webmaster Tools。
对首页：
https://go-dev.shuijingwanwq.com
执行 URL 检查后，Bing 给出的状态与 Google 明显不同。
页面已经在 8 月 13 日被 Bing 发现，但状态仍然是：
- 已发现；
- 未爬网；
- 尚未进入索引。
这至少说明之前提交的 Sitemap 已经发挥了“告诉 Bing 这些 URL 存在”的作用，但几天过去以后，Bing 仍然没有真正进入抓取阶段。
因此，相比已经开始正常工作的 Google，Bing 更值得尝试一次主动通知。
我没有继续使用传统 URL Submission，而是决定测试 IndexNow。
三、百度索引量仍然是 0
在百度搜索资源平台中，go-dev.shuijingwanwq.com 的索引量则更加明确。
从 8 月 12 日到 8 月 15 日，后台索引量一直是：
0百度没有像 Google、Bing、360 那样完成这次 Sitemap 提交，因此这里确实值得尝试一下官方提供的普通收录 API。
站点一共有 104 个 URL，于是我先从现有的：
https://go-dev.shuijingwanwq.com/sitemap.xml
自动提取 URL。
结果确认：
========== URL COUNT ==========
104 /tmp/go-dev-urls.txt最开始我尝试一次提交全部 104 个 URL。
结果百度直接返回：
{"error":400,"message":"over quota"}这说明问题并不在 URL，而是在当天的提交额度。
为了确认实际额度，我改成只提交首页。
这一次成功：
{"remain":9,"success":1}也就是说，这个新站当天实际只有 10 个普通收录提交额度。
四、百度剩余 9 个额度，不再机械按照 Sitemap 顺序使用
确定只剩 9 个额度以后，就没有必要按照 Sitemap 顺序继续提交 /tour/basics/1、/tour/basics/2、/tour/basics/3……
每天只有 10 个名额时，更值得优先提交整个课程体系的入口页面。
因此首页之外，我最终选择了：
https://go-dev.shuijingwanwq.com/tour/list
https://go-dev.shuijingwanwq.com/tour/welcome/1
https://go-dev.shuijingwanwq.com/tour/basics/1
https://go-dev.shuijingwanwq.com/tour/flowcontrol/1
https://go-dev.shuijingwanwq.com/tour/moretypes/1
https://go-dev.shuijingwanwq.com/tour/methods/1
https://go-dev.shuijingwanwq.com/tour/generics/1
https://go-dev.shuijingwanwq.com/tour/concurrency/1
https://go-dev.shuijingwanwq.com/tour/welcome/2随后一次提交这 9 个 URL：
{"remain":0,"success":9}
HTTP_STATUS: 200
remain 归零】至此，当天 10 个百度主动提交额度全部用完。
不过做到这里以后，我反而决定：后续不准备每天继续人工提交剩余页面。
原因很简单。
每天只有 10 个额度，就意味着需要连续多天回来处理，而且主动提交本身也不等于最终建立索引。
对于一个已经具备正常内部链接、搜索引擎验证和公开访问能力的新站来说，每天专门回来维护这件事情，成本开始明显超过收益。
所以这一次更多是验证：
百度普通收录 API 可以正常工作。
至于后面的页面，则准备交给百度自己自然发现和抓取。
五、Bing 改用 IndexNow，一次提交全部 104 个 URL
Bing 这边则完全是另一种体验。
Bing Webmaster Tools 本身已经提供 IndexNow 入口，因此我生成了一个 IndexNow Key。
随后将对应的 Key 文件部署到 go-dev.shuijingwanwq.com 根目录，并通过 Nginx 单独映射到现有的：
/data/go-tour/verification/目录。
这样没有必要修改 Go Tour 程序本身，百度、搜狗等已有验证文件的处理方式也可以继续保持不变。
部署以后分别进行了源站和公网验证。
最终公网访问 Key 文件：
HTTP_STATUS=200返回内容与 IndexNow Key 完全一致。
在确认 Key 文件能够正常访问以后，从 Sitemap 中读取全部 104 个 URL，构建 IndexNow JSON 请求。
提交前再次检查：
url_count=104
payload_check=OK然后一次提交：
========== INDEXNOW SUBMIT ==========
HTTP_STATUS=202
这里的 202 并不是接口调用失败。
第一次使用新的 IndexNow Key 时，请求已经被接收，但 Key 验证和后续处理仍然是异步进行的。
与百度每天只有 10 个额度相比，IndexNow 这种方式显然更适合一次通知整个新站。
六、等待约 20 分钟，Bing Webmaster Tools 仍然没有变化
提交完成以后，我没有马上结束，而是继续观察 Bing Webmaster Tools 的 IndexNow 页面。
从大约 17:13 完成 IndexNow 提交，到 17:32 左右再次检查，已经等待了接近 20 分钟。
后台仍然保持原来的：
Get Started页面，没有立即出现 104 个 URL 的提交统计。
不过这时继续刷新已经没有太大意义。
现有证据已经足够完整：
- IndexNow Key 格式正常；
- Key 文件部署成功；
- 源站访问正常；
- 公网访问为 HTTP 200；
- 文件内容正确；
- 104 个 URL 检查通过；
- IndexNow API 已返回 HTTP 202。
剩余过程已经属于 Bing 和 IndexNow 后台的异步处理。
因此我没有为了追求一个立即出现的后台结果而重复提交 104 个 URL，也没有重新生成 Key 或继续修改 Nginx。
这一次就停在这里，让 Bing 自己继续处理。
七、360：Sitemap 已经提交，暂时没有必要额外操作
360 的情况相对简单。
Sitemap 已经完成提交，但站长平台的索引量页面暂时仍显示没有数据。
既然 Sitemap 已经存在，而且站点本身访问正常，就没有必要为了刚上线几天的新站继续增加额外处理。
因此 360 当前采取的策略是：
继续等待自然抓取和后台数据更新，不再额外折腾主动推送。
八、搜狗的数据让我决定放弃主动推进
搜狗则是这次检查里最能说明“主动提交未必值得投入”的一个例子。
go-dev.shuijingwanwq.com 当前还没有显示收录和索引数据。
但我顺手检查了长期运行的主站：
www.shuijingwanwq.com
结果截至 8 月 15 日：
索引量：84
收录量：52,936
这里的“收录量”和“索引量”并不是同一个概念。
从后台结果来看，搜狗已经发现或抓取了大量页面，但真正进入索引的数据却少得多。
这说明对于搜狗而言，问题已经不只是“有没有主动告诉它 URL”。
即使搜索引擎知道大量页面存在，最终愿意建立多少索引仍然是另外一回事。
在这种情况下，如果再为 go-dev 研究每天如何手动提交、怎样批量提交，投入产出比就比较低了。
因此搜狗也决定不主动推进。
站点继续允许正常抓取即可。
九、最终真正主动处理的只有百度和 Bing
这一轮开始之前，我还在考虑：
要不要把 Google、Bing、360、百度、搜狗五家全部主动提交一遍？
真正检查完后台以后，答案变得简单很多。
Google 已经开始自然抓取和索引，因此不需要干预。
Bing 已发现 URL 但没有抓取，所以通过 IndexNow 一次通知了全部 104 个 URL。
百度索引量为 0，因此验证了普通收录 API，并使用当天 10 个额度提交了最重要的入口页面。
360 已经完成 Sitemap 提交，继续等待即可。
搜狗则因为成熟主站本身就存在“抓取很多、实际索引很少”的情况，不再主动投入维护时间。
最终真正需要主动处理的，其实只有百度和 Bing。
而且百度这一次完成 API 能力验证以后，我也不准备继续每天提交。
十、主动提交不是越多越好，还要考虑维护成本
这次最大的收获并不是成功向百度提交了 10 个 URL，也不是成功向 IndexNow 一次提交了 104 个 URL。
更重要的是重新确认了一件事：
搜索引擎主动提交只是帮助搜索引擎更早发现页面的一种方式，并不是“提交以后就一定收录”。
如果一个网站：
- Sitemap 已经正常公开；
- 页面之间存在完整内部链接；
- robots.txt 没有阻止抓取；
- 页面能够稳定访问；
- 搜索引擎已经开始发现 URL；
那么后续是否值得每天花时间人工提交，就需要考虑真实维护成本。
百度每天只有少量额度，如果为了把整个站点都推完，需要每天回来重复操作，那么这种维护方式并不适合当前项目。
IndexNow 可以低成本一次提交整个新站，所以值得配置一次。
Google 已经能够自己正常工作，就没有必要人为增加操作。
360 和搜狗同样没有必要为了“尽快看到数字变化”而不断增加维护逻辑。
因此这轮处理结束后，我准备重新回到原本的开发任务：
--minimal-protect搜索引擎这边则暂时交给 Sitemap、内部链接以及自然抓取继续工作。
十一、后续计划
后续不会每天检查这几个平台。
目前只需要偶尔观察：
- Google 的索引页面数量是否继续增加；
- Bing 首页是否从“已发现但未爬网”进入抓取和索引；
- IndexNow 后台是否最终出现本次提交记录；
- 百度是否开始出现自然索引量；
- 360 是否开始产生索引统计。
如果这些数据后续自然发生变化，再继续记录即可。
对于 www.shuijingwanwq.com 和 en.shuijingwanwq.com，未来如果确实需要接入 IndexNow，也可以分别按照各自子域部署独立 Key，再围绕新增、更新和删除的 URL 做自动通知。
但这已经属于后续独立优化工作。
当前最重要的仍然是把 A Tour of Go 多语言翻译项目本身继续推进，而不是为了搜索引擎后台的数字变化不断增加人工操作。
这一次主动提交实践，到这里就可以告一段落了。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复