系列帖子
A Tour of Go 简体中文站正式上线到：
https://go-dev.shuijingwanwq.com/
之后，我开始处理上线后的搜索引擎提交。
这次原本的计划很简单：沿用此前给 en.shuijingwanwq.com 添加搜索引擎资源时积累的经验，快速完成 Google、Bing、360、百度和搜狗五个平台的接入。
实际操作下来，搜索引擎提交本身并不复杂，但在正式提交之前，我先发现了两个更基础的问题：
/robots.txt实际返回的是 Tour 首页 HTML；/sitemap.xml同样返回 Tour 首页 HTML。
也就是说，A Tour of Go 应用的通配路由接管了这两个本应提供给搜索引擎的路径。
最终这次工作不只是完成了五个平台提交，还顺手补齐了生产站的 SEO 基础入口，解决了百度和搜狗的验证文件访问问题，并清理了 Nginx 新版本下已经过时的配置警告。
一、正式提交前，先检查搜索引擎抓取入口
最开始，我从公网检查：
https://go-dev.shuijingwanwq.com/robots.txt
https://go-dev.shuijingwanwq.com/sitemap.xml
结果发现，两者虽然都返回 HTTP 200，但 Content-Type 都是：
text/html; charset=utf-8
正文也不是 robots 或 Sitemap，而是完整的“Go 语言之旅”首页 HTML。
根因很直接：
生产 HTTP 路由没有注册
/robots.txt和/sitemap.xml，因此请求最终落到了 Tour 的/通配路由。
所以我没有急着进入各个站长平台，而是先暂停搜索引擎提交，在 go-tour-i18n 中补齐这两个入口。
二、从正式课程页面集合动态生成 Sitemap
这次没有另外维护一份 103 页的硬编码 Sitemap 列表。
项目本身已经掌握完整的正式课程页面集合，因此 Sitemap 直接从正式渲染页面生成。
最终包含：
- 首页：1 个；
- 正式课程页面：103 个；
- 总计：104 个 URL。
课程 URL 统一采用：
https://go-dev.shuijingwanwq.com/tour/{article}/{section}
同时没有人为加入没有可靠来源的数据：
lastmodchangefreqpriority
也没有出现已经废弃的旧域名：
go-tour.shuijingwanwq.com
robots.txt 则保持得很简单：
User-agent: *
Allow: /
Sitemap: https://go-dev.shuijingwanwq.com/sitemap.xml
相关代码测试完成后提交：
7162b98 feat: 添加搜索引擎抓取入口
随后重新生成生产发布包。
三、生产发布前，再验证一次真实 bundle
新的 production bundle 仍然保持：
locale=zh-CN
ready=103
pending=0
blocked=0
pages=103
articles=7
为了避免“源码测试正常、实际发布包却有差异”的情况，我直接启动最终 production bundle 做本地验收。
最终确认：
/robots.txt
HTTP 200
Content-Type: text/plain; charset=utf-8
/sitemap.xml
HTTP 200
Content-Type: application/xml; charset=utf-8
Sitemap URL 数量
104
课程页面本身也继续正常：
/tour/welcome/1
HTTP 200
<html lang="zh-CN">
<title>Go 语言之旅</title>
而 /tour/lesson/ 仍然能够返回中文课程数据。
这说明新增 SEO 入口没有影响现有 Tour 的工作方式。
四、部署生产并处理 EdgeOne 旧缓存
新的 production bundle 上传服务器后，先完成：
- SHA-256 完整校验；
go-tour服务用户读取权限检查；- release 目录检查；
current切换前后确认。
之后再原子切换：
/data/go-tour/current
从旧版本：
/data/go-tour/releases/20260812-zh-CN-cac4d6e
切换到：
/data/go-tour/releases/20260812-zh-CN-7162b98
服务重启后：
go-tour.service
Active: active (running)
源站直接访问已经能够正确获得新的 robots 和 Sitemap。
不过公网访问一开始仍然拿到了旧内容。
原因不是应用，也不是 Nginx，而是 EdgeOne 节点仍然保留着部署前的缓存。
因此我只精准清除了：
https://go-dev.shuijingwanwq.com/robots.txt
https://go-dev.shuijingwanwq.com/sitemap.xml
没有刷新整个站点。
刷新后公网重新回源，最终得到：
robots.txt
HTTP/2 200
content-type: text/plain; charset=utf-8
sitemap.xml
HTTP/2 200
content-type: application/xml; charset=utf-8
URL_COUNT=104
五、曾经短暂考虑：课程正文不在源代码里，会不会影响 SEO？
这里还有一个比较值得记录的小插曲。
在浏览器打开：
view-source:https://go-dev.shuijingwanwq.com/tour/welcome/1
时，我发现原始 HTML 中并没有当前课程正文。
页面源码中主要还是 Tour 的 HTML 外壳，课程正文是在 JavaScript 运行以后，再通过课程接口获取并渲染出来的。
这让我一度产生了一个疑问：
如果搜索引擎拿到的初始 HTML 中没有课程正文，那么给 103 个课程页面生成 Sitemap 到底还有多大意义？
于是又专门检查了官方 A Tour of Go 当前的实现。
结果发现官方本身仍然采用类似的客户端渲染结构：
<div table-of-contents></div>
<div ng-view ng-cloak class="ng-cloak"></div>
<script src="/tour/script.js"></script>
具体课程数据同样是在浏览器运行 JavaScript 后获取。
也就是说：
这不是简体中文翻译项目引入的新问题，而是官方 A Tour of Go 本身的架构方式。
因此最终没有为了 SEO 单独把整个 Tour 改造成服务器端渲染。
对于 A Tour of Go 这种连续教程型网站，我现阶段更看重：
- 首页能够正常抓取和建立索引；
- 搜索引擎能够发现整个课程 URL 集合；
- 用户从首页进入后，通过 Tour 自身的课程导航继续学习。
课程页能够获得独立索引当然更好，但目前没有必要为了这个目标大幅偏离官方架构。
六、Google Search Console：104 个页面全部发现
SEO 基础入口准备完成以后，正式开始搜索引擎提交。
第一个是 Google Search Console。
go-dev 此前已经作为独立 URL 前缀资源存在，所以直接进入“站点地图”，提交：
sitemap.xml
Google 很快完成读取：
状态：成功
已发现的网页：104
这也反向证明，新生成的 Sitemap 不只是能够访问，而且能够被 Google 正常解析。
七、Bing：继续沿用之前添加 en 子域的经验
接下来是 Bing Webmaster Tools。
这里没有重新添加 go-dev 独立站点。
之前处理 en.shuijingwanwq.com 时已经验证过一种更简单的方式：
直接在现有
shuijingwanwq.comBing 资源下面提交子域的完整 Sitemap 地址。
所以这次继续沿用：
https://go-dev.shuijingwanwq.com/sitemap.xml
很快显示：
状态：成功
已发现 URL：104
这次也再次说明了一个很实际的经验：
已经走通过一次的平台流程，没有必要换一个子域以后再重新探索一遍。
能直接复用此前的成功经验，就尽量不要重复踩坑。
八、360：添加二级站，再设置 HTTPS 和 Sitemap
360 这边同样沿用此前处理 en 时的经验。
因为 go-dev.shuijingwanwq.com 是已有主域下面的子域，因此没有重新选择“添加网站”，而是：
站点管理
→ 添加二级站
添加：
go-dev.shuijingwanwq.com
添加成功后，站点显示：
备案状态：已备案
站点权限：拥有者
随后完成 HTTPS 设置，再进入：
数据提交
→ Sitemap提交
提交：
https://go-dev.shuijingwanwq.com/sitemap.xml
刚提交时，“包含 URL”和“更新时间”暂时显示 --，这个阶段没有必要一直等待。
Sitemap 已经成功进入平台即可。
九、百度：继续采用文件验证，但不修改 Tour 应用
百度搜索资源平台需要单独添加：
https://go-dev.shuijingwanwq.com
站点属性继续选择“信息技术”。
到了验证阶段，百度提供：
- 文件验证；
- HTML 标签验证。
之前处理 en 时已经使用过文件验证，因此这次继续沿用。
百度生成的验证文件类似：
baidu_verify_codeva-XXXXXXXXXX.html
但 go-dev 与 WordPress 站点不同。
它本身是一个 Go Tour 应用，并没有一个传统意义上可以随便往根目录丢 HTML 文件的 Web 根目录。
一开始可以考虑把这个验证路径增加到 Tour 应用中，但很快发现其实完全没有必要。
因为生产环境前面本来就有 Nginx：
EdgeOne
→ Nginx
→ 127.0.0.1:3999
→ Tour
因此最终把验证文件长期保存到：
/data/go-tour/verification/
然后通过 Nginx 精确匹配：
location = /baidu_verify_codeva-XXXXXXXXXX.html {
alias /data/go-tour/verification/baidu_verify_codeva-XXXXXXXXXX.html;
default_type text/html;
}
这样只有百度验证文件由 Nginx 直接返回：
/baidu_verify_codeva-XXXXXXXXXX.html
其他所有 Tour 请求仍然继续：
proxy_pass http://127.0.0.1:3999;
完全不需要污染 Tour 应用本身。
十、顺便清理 Nginx 新版本下的旧配置警告
修改百度验证配置以后执行：
nginx -t
发现已有 Nginx 配置存在两个历史警告。
第一个是旧 HTTP/2 写法：
listen 443 ssl http2;
listen [::]:443 ssl http2;
于是调整为：
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
第二个是：
ssl_stapling on;
ssl_stapling_verify on;
当前证书已经没有可供 Nginx 使用的 OCSP responder，因此对应配置只会不断产生：
ssl_stapling ignored
的警告。
这两行也一并删除。
最终重新执行：
nginx -t
只剩：
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
不再有原来的警告。
然后按照当前生产运维手册使用：
service nginx reload
完成重载。
十一、百度验证成功，还顺手发现 en 漏了“关联主体”
百度验证文件通过源站和 EdgeOne 两层访问测试后，完成网站验证。
最终在百度“站点管理”中已经可以同时看到：
https://go-dev.shuijingwanwq.com/
https://en.shuijingwanwq.com/
https://www.shuijingwanwq.com/
这里还顺手发现了一个之前遗漏的问题：
en.shuijingwanwq.com 虽然早已经添加到百度，但此前没有关联现有主体。
后来查看 en 的百度索引量，发现即使没有关联主体，百度实际上仍然一直在建立索引，最近索引量甚至已经增长到 80 多。
所以：
没有关联主体，并不意味着百度完全不会收录站点。
不过既然已经发现这个遗漏，而且 www、en、go-dev 本身都属于同一主体，这次就顺手把三个站点的主体关联统一补齐。
十二、搜狗：这次文件验证终于一次成功
最后一个平台是搜狗资源平台。
此前给 en.shuijingwanwq.com 做搜狗验证时，文件验证曾经反复失败。
当时 en 使用 Cloudflare CDN，我一直怀疑搜狗的验证抓取与 Cloudflare 之间存在某种兼容问题，但始终没有足够证据确认。
这一次 go-dev 使用的是 EdgeOne，所以正好再测试一次。
搜狗生成的验证文件为：
sogousiteverification.txt
同样没有修改 Tour 应用，而是放到：
/data/go-tour/verification/sogousiteverification.txt
再通过 Nginx 精确匹配：
location = /sogousiteverification.txt {
alias /data/go-tour/verification/sogousiteverification.txt;
default_type text/plain;
}
分别验证：
源站 Nginx
→ HTTP 200
EdgeOne 公网
→ HTTP 200
→ EO-Cache-Status: MISS
验证文件内容也完全正确。
随后回到搜狗点击“完成验证”。
这一次：
一次成功。
这至少说明当前：
EdgeOne
→ Nginx
→ 验证文件
这条链路能够被搜狗正常访问。
至于之前 en + Cloudflare 验证失败是否真的由 Cloudflare 引起，目前还不能仅凭这一次对照直接下定论，但这个差异值得保留记录。
十三、搜狗不需要走完整资质审核，也已经能提交资源
搜狗完成网站验证以后，平台继续引导进入：
提交资质
→ 审核资质
需要填写：
- 网站名称；
- 行业；
- ICP 备案号；
- ICP 备案截图；
- 主办方；
- 主体信息；
- 运营者信息。
一开始我不确定：
如果不把这整套资质流程做完，会不会影响搜狗收录？
于是没有急着继续填写，而是先进入：
搜索服务
→ 资源收录
结果在站点下拉框里已经能够直接选择：
go-dev.shuijingwanwq.com
也就是说：
网站验证完成以后，即使没有继续提交完整资质，也已经能够以“已验证站点”的身份使用基础资源收录功能。
因此目前没有必要为了搜索引擎收录继续填完整资质。
十四、搜狗 Sitemap 仍然采用邀请制
搜狗“资源收录”页面同时存在：
URL提交
Sitemap提交
于是又检查了一下 Sitemap 权限。
结果页面明确显示：
此站点未开通 sitemap 权限
并说明 Sitemap 属于邀请制，需要搜狗 Spider 对站点抓取达到一定条件以后才可能开放。
这也意味着目前五个平台的实际情况并不完全一致。
十五、五个平台最终状态
至此，go-dev.shuijingwanwq.com 的搜索引擎接入状态如下：
✅ 独立资源
✅ Sitemap 提交成功
✅ 已发现 104 个网页
Bing
✅ 在现有 shuijingwanwq.com 资源下提交
✅ Sitemap 成功
✅ 已发现 104 个 URL
360
✅ 添加二级站
✅ HTTPS
✅ Sitemap 已提交
百度
✅ 添加 go-dev 站点
✅ 文件验证通过
✅ 关联现有主体
⚠ 当前账号/站点没有直接使用 Sitemap 提交的条件
搜狗
✅ 网站文件验证通过
✅ 可以作为已验证站点使用资源收录
⚠ Sitemap 权限仍为邀请制
十六、为什么我开始考虑单独做一个“搜索引擎提交项目”
做到最后，一个新的需求也变得越来越明显。
目前我已经维护：
www.shuijingwanwq.com
en.shuijingwanwq.com
go-dev.shuijingwanwq.com
以后 A Tour of Go 如果继续增加新的语言，还可能出现更多站点。
如果每一次新站上线、新文章发布，都手工进入：
Google
Bing
360
百度
搜狗
逐个平台操作，会产生越来越多重复劳动。
而且各个平台支持的能力并不一样：
Google / Bing / 360
→ Sitemap 相对方便
百度
→ 更适合结合主动推送接口
搜狗
→ Sitemap 邀请制
→ 当前可以使用 URL 提交
所以后续我比较倾向于单独做一个很轻量的项目，例如：
search-engine-submit
职责保持简单：
读取 sitemap.xml / URL 列表
↓
识别新增或需要重新提交的 URL
↓
调用能够自动提交的官方接口
↓
生成需要人工提交的平台 URL 清单
↓
保存每次提交状态
第一阶段完全没有必要做：
- 数据库；
- Web 管理后台；
- 分布式任务队列；
- 复杂调度系统。
一个命令行工具加少量 JSON 状态文件，就已经足够解决主要重复劳动。
十七、这次最大的体会：已经验证过的经验，要直接复用
这次实际操作时间并不算长，一个很重要的原因就是大量复用了之前添加 en.shuijingwanwq.com 时积累的经验。
例如：
Bing 不再重新探索“如何添加一个独立子域站点”，而是直接：
现有 shuijingwanwq.com
→ Sitemap
→ 提交 go-dev 完整 Sitemap 地址
360 直接：
添加二级站
→ HTTPS
→ Sitemap
百度继续：
添加网站
→ 文件验证
搜狗同样优先尝试：
文件验证
差别只在于，这次 go-dev 是独立 Go 应用，所以把验证文件统一放在：
/data/go-tour/verification/
再交给 Nginx 精确处理。
整个过程没有必要为了两个搜索引擎验证文件修改 Tour 应用。
这种做法也让我越来越确认：
对长期维护的项目来说，记录以前已经验证成功的生产经验很重要。下一次遇到同类问题时，真正提高效率的往往不是重新寻找“更聪明”的方案，而是直接复用已经走通过的路径。
十八、当前结果
经过这一轮处理，A Tour of Go 简体中文站上线后的搜索引擎基础工作已经完成。
现在生产环境已经拥有：
https://go-dev.shuijingwanwq.com/robots.txt
https://go-dev.shuijingwanwq.com/sitemap.xml
Sitemap 中：
首页：1
课程页：103
总 URL：104
并且：
Google ✅
Bing ✅
360 ✅
百度 ✅
搜狗 ✅
五个平台都已经完成当前阶段能够完成的接入。
下一步不需要继续频繁调整。
先让搜索引擎自然抓取、建立索引，再根据实际数据观察：
- 首页是否进入索引；
- 搜索品牌词和 Go 教程相关关键词时是否开始出现；
- 103 个课程页面能有多少被独立发现；
- 百度、360、搜狗对这种 JavaScript Tour 页面的抓取效果如何；
- 是否值得启动独立的搜索引擎 API 提交工具项目。
A Tour of Go 简体中文站已经从“能够正式访问”，继续向“能够被搜索引擎稳定发现”迈进了一步。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复