多语言网站到底应该做多少种语言？

两个真实参照摆在一起会更有说服力。Omni Calculator 做了 30 多种语言，2026 年 6 月估算月访问约 1429 万。Inch Calculator 只做尺寸和工程量估算，面向的几乎全是美国市场——英尺、英寸、磅这些英制单位——同期访问 459 万。

Omni Calculator 首页写着 3925 个免费计算器，Finance 一个分类就占 616 个。

一个 30 种语言，一个基本单语，都做成了。这说明"应该做多少种语言"没有通用答案，取决于内容和地区的绑定强度。

先看内容和地区绑得多紧

强绑定的内容，不做本地化等于没做。税务计算、贷款利率、社保缴纳、装修报价——这些的数值口径本身就是按国家定的。一个只按美国税法算的工资计算器，翻译成日语没有任何价值，因为日本用户算的不是同一个东西。

弱绑定的内容，语言只是界面。图片格式转换、PDF 合并、文本去重、单位换算——核心逻辑与地区无关，用户不会因为界面是英文就不用。

Omni Calculator 属于典型的强绑定。它的计算器涉及税率、货币、度量单位，30 多种语言不是"翻译了 30 遍"，是"为 30 个市场各做了一套参数"。Inch Calculator 则选择了把单一市场做透——只服务用英制单位的那一批人，459 万访问说明这个选择完全成立。

很多人算的是"翻译一遍多少钱"，实际成本是乘在页面数上的。

N 个页面 × M 种语言 = N×M 个 URL。一个 3000 页的站做 10 种语言就是 3 万个 URL，sitemap 会逼近单文件 5 万条的上限，构建时间翻十倍，hreflang 的对应关系要维护 3 万组。

更麻烦的是内容更新。你改了一个计算公式，10 种语言版本的说明文字都要跟着改。改不过来的那部分就会变成"同一个计算器，中文版说明和英文版说明算出来的不一样"——这种错误在搜索结果里表现得特别糟，用户点进来发现和自己的算法对不上，立刻返回。

Helpful Content 系统在 2025 年升级成了整站级信号，不再按页面单独打分。这个变化的实际含义是：一批质量很差的翻译页面不会自己烂掉，它们会把整个站的评级往下拽。

政策口径在 Google Search Central 里写得很清楚——奖励原创、对人有实际帮助的内容；AI 生成本身不违规，违规的是为了操纵排名而规模化生产没有增量的内容。机翻页面如果加上了本地参数、本地示例、本地单位，它是有增量的；只是把英文原文过一遍翻译 API 就发出去，属于后者。

先看现有流量里非目标语言的占比。 TinyWow 的数据很典型：美国 20.17%、印度 14.63%、英国 3.22%。前三全是英语地区，说明它的通用工具需求不需要翻译也能覆盖——它没有因此去做几十种语言。如果你后台里某个国家的流量已经占到了两位数，那才是加语言的信号。

选一个市场做到底，别一次上十种。 挑流量占比最高的那个国家，把单位、货币、示例、日期格式全部本地化，跑两三个月看索引率和展示数。这一种都做不好，说明你的内容结构不适合多语言，加再多也没用。

只有本地化是数据驱动的，才继续加。 理想状态是每种市场一套参数配置、页面由模板生成，加一种语言等于加一份配置文件，而不是加一批需要人工维护的副本。

页面数据用一张表按 lang 分组。 放 SQLite 里，pages 表加 lang 和 i18n_group 两个字段，i18n_group 相同的记录互为翻译版本。构建时按 group 生成 hreflang 组，天然不会漏掉单向声明。

每种语言一份 sitemap。 好处是可以分别看索引率——日语版索引率只有 30%，一眼就能判断这是翻译质量问题还是抓取问题。提交时用一个 index 文件把它们串起来。

语言切换链接必须是真实 <a href>。 用 JS 下拉框做语言切换，爬虫抓不到其他语言版本的入口。这个链接要出现在每个页面的 HTML 里，指向对应语言版本的同一页面，而不是跳回首页——跳回首页等于把所有变体的权重都堆在根路径上。

判断标准其实就一句话：如果这个页面翻译成日语之后，日本用户算出来的数字和美国用户一模一样，那这个页面大概不需要翻译。

Omni Calculator 30+ 语言、1429 万月访问与 Inch Calculator 459 万月访问均为 2026 年 6 月第三方估算；TinyWow 地区分布为 2026 年上半年估算。