双语站、产品页与预发布路径的 robots.txt 检查清单

robots.txt 看起来很小，所以很多团队会把它拖到最后再处理。等真正上线后才发现，该放开的页面被挡住了，不该暴露的路径却还在公网里。

对开发者工具站点和跨境卖家来说，真正的风险通常不是这一个文件本身，而是生产站、预发布环境、双语页面和历史路径之间出现了互相冲突的抓取信号，最后只能在流量掉下去之后再回头排查。

像 GhostNode 这种体量不大的双语站，robots.txt 不需要写得复杂，但一定要写得有边界感。

1. 先把 robots.txt 当成抓取提示，不要把它当成隐私保护

最常见的误区，是把 robots.txt 当成“隐藏入口”的办法。

它做不到这一点。它只是告诉遵守规则的爬虫哪些路径可以抓、哪些路径不建议抓。凡是必须真正保密的内容，都应该用认证、网络隔离，或者根本不要发布到公网，而不是只写一条 Disallow。

双语站尤其容易踩这个坑，因为草稿翻译页、预览路由、后台入口、历史测试路径，常常都和正式内容放得很近。如果唯一的“保护”只是 robots.txt，那这个边界从一开始就是脆的。

2. 生产规则和预发布规则必须分开

很多搜索问题，都是因为 staging 规则被带进了生产，或者生产规则被复制到了 staging。

更稳妥的做法是：

• 正式站对真实公开内容保持可抓取
• staging 要么不公开，要么明确阻止收录
• preview 链接不要长期处于“半公开但规则混乱”的状态

如果 staging 为了内部验收必须公网可访问，那也应该同时配合页面级 noindex 和发布前检查。预发布页、测试页与预览链接的 noindex 检查清单 处理的是这一层。单靠 robots.txt，约束力不够。

3. 真正希望被收录的页面，要确认它们没有被误挡

这件事看起来很显然，但在路由改名、目录调整、临时热修之后最容易出问题。

至少要重新看一遍，这个文件是否仍然允许：

• 产品页
• 博客文章
• 页面正常渲染所需的静态资源
• 应该公开的双语或本地化路径

很多站点不是“没写收录策略”，而是某个目录曾经为了测试被整段挡住，后来正式上线时忘了拿掉。双语站尤其要小心某个语言路径曾被临时屏蔽，然后一路带到了正式环境。

4. 不要误挡会影响页面理解的 CSS、JS 和图片资源

现在的搜索引擎并不只看原始 HTML，它们也会看页面渲染后的结果。

如果关键资源被挡住，搜索引擎对页面布局、导航、结构化数据注入、语言切换行为的理解都可能变得不完整。对双语页面尤其如此，因为同一个公开路由可能会根据语言状态呈现不同内容。

如果你正在排查双语渲染和元数据问题，最好把这一步和 产品页、工具页与双语站的结构化数据检查清单 一起看。页面 URL 能抓到，不代表搜索引擎就一定能正确理解页面。

5. robots.txt 要和 canonical、hreflang、sitemap 一起对齐

robots.txt 不应该和其他索引信号互相打架。

最常见的矛盾包括：

• sitemap 里列出了一个 URL，但 robots.txt 把它挡住了
• hreflang 指向了一个语言版本，但爬虫根本抓不到
• canonical 偏向某个页面，但那个页面被误拦截
• 改名后的新旧路径在不同地方各自保留了一半

所以这类文件不应该孤立修改，而应该作为同一次发布检查的一部分。活动页、重复路径与双语站的 canonical URL 清单、双语产品页与博客文章的 hreflang 检查清单、双语站、产品页与新内容发布的 XML Sitemap 清单 都和这里直接相关。

6. 旧规则要么说得清楚，要么删掉

robots.txt 很容易堆积“临时处理”。

几个月后，没人还记得某条规则为什么存在：

• 某个历史活动目录
• 某个测试集合页
• 某次语言实验留下的路径
• 某个已经废弃的旧 blog 路由

如果规则仍然有意义，就要保持足够清晰，让后来的人能快速判断它为什么存在。如果已经没有意义，就删掉。否则这个文件会慢慢变成一层层过期运维决策的沉积物。

页面改名时尤其要检查这一点。页面改名但不丢搜索流量的实战清单 解释了跳转那一侧，而 robots.txt 也应该在同一次发布里一起复查，避免新旧路径继续互相冲突。

7. 把 sitemap 地址明确写出来

sitemap 不能替代 robots.txt，robots.txt 也不能替代 sitemap。

两者配合会更稳。把公开 sitemap 地址明确写在文件里，能让爬虫更快发现当前内容集合，尤其是在新文章发布、路径变更或站点结构刚调整之后。

对 GhostNode 来说，这一点很实际，因为新的双语文章应该在同一个发布窗口里同时通过文章页、博客列表页和 /sitemap.xml 被看到。

8. 部署后要验证公网文件，而不是只看本地源文件

本地看起来没问题，不代表公网就已经是最新版本。

部署后至少检查：

• https://ghostnode.dev/robots.txt 返回 200
• 期望的 sitemap 行已经出现
• 生产环境应有的放行规则还在
• staging 才该存在的拦截规则没有被带到生产
• 新文章 URL 仍然返回 200
• /api/health 依旧健康

如果源站已经正确、但边缘缓存还在返回旧文件，那就把它当成普通缓存问题处理。发布新页面后的 Cloudflare 缓存清理清单 在这里同样适用。

9. 一份够用的 robots.txt 发布清单

在把这个文件视为“已完成”之前，至少确认：

• 敏感路径有真实访问控制，而不是只靠 robots.txt
• staging 和 production 规则没有混在一起
• 关键公开页面和资源仍然可抓取
• canonical、hreflang 与 sitemap 没有和抓取规则冲突
• 历史迁移阶段留下的过期拦截规则已经清理
• 部署后已经验证过公网 robots.txt

结论

robots.txt 做得好，不是因为它写得多聪明，而是因为它不制造矛盾。

对双语站、产品页和预发布流程来说，最稳的做法很简单：该公开抓取的页面继续公开，该非公开的路径真正不要暴露出来，然后在每次发布后，把生产 robots.txt、sitemap、文章页和健康接口一起验证一遍。