# 网站应该先做中文版还是直接多语言？

URL: https://caijiao.org/posts/136
Source: docs/posts/136.md
Description: Omni Calculator 现在覆盖 30 多种语言、2026 年 6 月估算访问约 1429 万，但顺序是反的：它先做了"计算器即配置、页面由模板生成"，多语言才变成配置里多一个字段。没做这层抽象就上多语言，翻译只是最便宜的部分。

Omni Calculator 覆盖 30 多种语言，2026 年 6 月的估算访问约 1429 万。看到这两个数字，很容易得出"多语言带来了流量"的结论。但顺序其实是反的：它先把计算器抽象成一份配置、页面由模板渲染，多语言才变成这份配置里多出来的一个字段。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页没有弹窗也没有注册引导，主体就是一张分类网格。*

## 先抽模板，语言才只是配置里的一个字段

如果你的站是"同一个结构重复 N 遍"——工具、计算器、词典、对照表——那么多语言的工程量不在翻译，在于结构能不能被抽象。

抽象之后，加一门语言是：复制一份配置、翻译其中的字符串、生成一批页面。没抽象之前，加一门语言是：把已有的 100 个页面手工翻一遍，之后每次改版再翻一遍。

Omni Calculator 能撑住 30 多种语言还保持全站一致，靠的就是这层抽象。它的广告负责人 Alexander Utz 说过一句很硬的话："页面速度对我们没有商量余地，我们的整个增长都依赖 SEO，Core Web Vitals 直接影响排名。"这句话放在多语言语境里更成立：30 种语言意味着 30 倍的页面数，如果每个页面都要实时渲染、实时查库，速度会先崩。预渲染在这里不是优化项，是前提。

## 先把一个语言的收录跑通，再谈第二个

我见过太多次"一次上线五种语言、结果五种都没收录"的站。搜索引擎对新站的第一反应是观察，页面数量适中、更新稳定的站更容易通过这段观察期；一次性铺开几千个页面，反而会把信任建立拖长。判断有没有被收录，靠猜不行，得先配好 Search Console，看索引覆盖率报告里的实际数字，而不是在搜索框里敲 site: 看心情。

Gusto 那个工资计算器是个有用的参照：英文词 "wage calculator" 月搜索量约 17000，页面月访问约 17776。它的价值来自"词足够具体"，而不是"语言足够多"。做中文站也一样——先确认你要覆盖的那批中文词真实存在、量级值得，再考虑开英文版。

技术上要先把单语言的 URL 结构定死：目录层级、分页怎么处理、参数要不要出现在路径里。这个顺序能省下大量返工，因为语言前缀加在路径里（example.com/en/...）还是做成子域名（en.example.com），对站点地图和索引的处理完全不同，中途改一次要补一整批 301。

我一般选路径前缀，理由很实际：同一个域名下的所有语言版本共享同一份域名权重积累，也共用一套证书、一份日志、一份缓存配置；子域名等于把这件事拆成好几个站来养，对一个人维护的项目来说没有收益。等某个语言的流量真的独立大到需要分开运营，再拆也不迟。

## 多语言真正的三件技术活

第一件是路由与 hreflang。每个语言版本都要互相标注，告诉搜索引擎"这些页面是彼此的对应版本"，否则多语言页面会被当成互相重复的内容处理。

第二件是站点地图要按语言分组列出全部版本的 URL，并标注每个 URL 的语言。写法在 Google Search Central 文档里有明确规范，其中 [sitemap 与 robots](/google-search-central/04-sitemaps-robots) 的部分单独占了一节，值得照着改一遍，而不是照抄别人的模板。

hreflang 本身也有几个容易写错的地方。标注必须是双向的：中文页引用英文页，英文页也要指回中文页，只写一半等于没写。每个语言版本还要把指向自己这一条也写进去，缺了这条，整组标注都可能被判为无效。另外要为"没有匹配语言"的情况留一个 x-default 指向兜底页，否则来自其他地区的用户可能落到一个完全不对的语言版本上。语言代码也要全站统一，今天写 zh-CN、明天写 zh-Hans-CN，混用会让标注被忽略——这种错误不会有任何提示，只会表现为"多语言一直没生效"。

第三件是结构化数据里的语言字段。如果页面标了 [JSON-LD](/json-ld/) 结构化数据，`inLanguage` 必须跟着语言版本变，否则会出现"页面是中文、结构化数据标着英文"的错配，而这种错配不会报错，只会安静地影响展示。

翻译本身反而是最便宜的一环——机器初翻加人工校对就能解决，前提是术语表先定好。

## 翻译之外，还有本地化这堆细活

字符串翻完只是开始。工具站尤其明显：日期格式（2026-09-24 还是 24/09/2026）、数字千分位、小数点、货币符号位置、单位是公制还是英制，这些都要跟着语言走。

金额类的工具在这上面最容易出错。汇率换算、税费计算、时薪折算，都是浮点运算，用原生 `Number` 一路算下去，几分钱的误差会被用户一眼看出来，而"算错了"对一个计算器站是致命的。这类计算应该用 [decimal.js](/decimaljs/) 之类的库做定点十进制运算，而不是在浮点数上凑合。这一层和语言无关，但它决定了你的多语言版本是不是每一版都可信。

排版也别忘了：中文字体文件通常比拉丁字体大一个数量级，多语言站点如果按语言动态加载字体子集，首屏能省下几百 KB；中文的行高和字重也和英文不同，同一套 CSS 直接套上去，中文版会显得挤。

## 机翻直出的风险，比想象中大

Google 的 Helpful Content System 在 2025 年升级成了整站级别的信号。这意味着一批低质量的机翻页面不再是"它们自己没流量"这么简单，它们会参与整站质量评估，把本来表现不错的中文页面一起拖下去。

我的顺序因此是：中文版先做到 50 个页面、收录稳定、索引覆盖率没问题，再抽 i18n 层；抽的时候只抽 UI 字符串——按钮、提示、导航、错误文案。工具的输入输出格式和专业术语不翻。一个 JSON 格式化工具，界面翻成了中文而输出还是 `{"key": "value"}`，用户的困惑比全英文时更多。

等这些跑顺了再开第二语言，你加的只是配置里的一列；没跑顺就开，你加的是两份永远对不齐的维护工作。

---

*Omni Calculator 访问量为 2026 年 6 月第三方估算数据；Gusto 页面数据同为第三方估算。*