WordPress 多语言与翻译：插件方案与性能代价
多语言在 WordPress 里不是「装个插件」的事，是一次内容结构改造。装插件十分钟，把三千篇文章拆成两种语言、把菜单和表单都配上翻译、把 URL 和 hreflang 理顺，是几周到几个月的工作量。先想清楚为什么做，比先选插件重要。
这篇讲四件事：URL 结构怎么定、WPML 和 Polylang 差在哪、翻译工作流怎么跑、以及最容易被忽略的性能代价。
三种 URL 方案，先定结构
多语言的第一个技术决策是 URL 长什么样。这一步定错了，后面想换方案等于重建站点。
| 方案 | 示例 | 优点 | 代价 |
|---|---|---|---|
| 子目录 | example.com/en/ | 权重集中在一个域名，一套 SSL、一套 CDN，配置最简单 | 所有语言共用一个服务器，性能压力集中，语言切换靠 rewrite |
| 子域名 | en.example.com | 各语言可独立部署，能分服务器、分团队维护 | 搜索引擎视为不同站点，权重分散，每个子域都要配 SSL 和 CDN |
| 独立站 | example.de | 本地化最彻底，可以针对单一市场做合规和支付 | 成本最高，内容同步、运维、SEO 全部乘以语言数 |
| 参数 | example.com/?lang=en | 改动最小，不用配 rewrite | 不利于收录和分享，不建议做正式多语言站 |
外贸展示站、语言数在三个以内，子目录最划算。要做区域合规（税务、隐私政策）或者由当地团队运营，才考虑子域名和独立站。参数方案只适合临时演示。
WPML 与 Polylang 的差别
这两个是主流选择，结构思路接近：每种语言一条独立的文章记录，再用一张关联表把它们绑在一起。差别在成熟度、生态和维护成本。
| 对比项 | WPML | Polylang |
|---|---|---|
| 授权 | 商业授权，按年付费 | 基础功能免费，Pro 版付费 |
| 翻译管理 | 翻译管理界面成熟，支持对接翻译服务、按角色分配译员 | 基础版够用，复杂流程要 Pro |
| 兼容性 | 对电商、页面构建器、表单插件的适配更完整 | 主流插件基本支持，冷门插件可能要自己补字符串 |
| 性能 | 功能多，查询较重，大站必须配对象缓存 | 相对轻，但语言数多了同样吃查询 |
| 维护成本 | 版本更新稳，出问题有官方支持 | 免费版更新频繁，兼容问题多半要自己查 |
选型不看名气看场景：电商加多语言加多币种，倾向 WPML；内容站、两三种语言、预算有限，Polylang 够用。两者都别和另一个多语言插件同时装，关联表和语言 cookie 会互相打架，表现出来就是「切换语言后跳错页」。
翻译工作流：机器翻译只做初稿
把整站丢进机器翻译一键生成，是最常见也最贵的错误。机器翻译在术语、产品名、法律条款上几乎必错，而多语言站的读者恰恰靠这些内容判断专业度。可行的流程是：
- 先定「哪些内容要翻」。产品页、服务页、联系页必翻；时效性博客、内部公告、招聘信息可以不翻，用 noindex 或者干脆不生成该语言版本。
- 术语表先建。品牌名、型号、行业词固定译法，整理成对照表交给译员和机器翻译，能减少一半返工。
- 机器翻译出初稿，人工只做校对和润色。校对重点看数字、单位、链接、按钮文案，这几处错了最容易被发现。
- 原文更新时标记「待重译」，不要自动覆盖译文。WPML 和 Polylang 都有翻译过期提示，拿它当队列用。
- 导航、页脚、表单提示、按钮这些字符串单独维护。它们不在文章里，要走插件自带的字符串翻译界面，或者 .po 文件。
主题和插件的界面文字走 .po、.mo 文件。主题没做国际化（代码里写死中文）的话，多语言插件也翻不了，只能改代码或者换主题。判断方法很直接：看主题目录有没有 languages/ 文件夹和 .pot 文件，没有就是没做准备，这类主题找人定制时就要提出来，写法见 主题定制。
hreflang 与索引
多语言站最常见的收录问题是「几种语言互相竞争同一个关键词」，原因通常是 hreflang 没配或者配错。每个语言版本的页面头部都要输出一组指向所有版本（包括自己）的链接：
<link rel="alternate" hreflang="zh-CN" href="https://example.com/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />几个要点：必须自引用；语言代码用 ISO 639-1，地区用 ISO 3166-1 Alpha 2，zh-CN、pt-BR 这种写法才对；x-default 指向语言选择页或默认语言；不要只在首页输出，每个内容页都要有，而且各语言版本之间的链接必须互相对应，A 指向 B，B 也要指回 A。
另外，翻译页面不要用 noindex 来「避免重复内容」，那是错的做法。正确方式是 hreflang 配对加各自独立的标题描述。真正该 noindex 的是机翻完无人校对的页面，那种页面被收录反而拉低整体质量。这部分的判断标准和 SEO 优化 里的收录策略是一致的。
多语言的性能与数据库代价
这部分在评估阶段最容易被忽略。多语言不是「多几个页面」，是文章数乘以语言数：
- 文章表翻倍。1000 篇文章做 4 种语言，wp_posts 里就是 4000 条记录，加上修订版本，实际行数还要再翻几倍。
- postmeta 同步膨胀。每篇 20 到 40 条 meta，4000 篇就是十几万行，wp_postmeta 很容易过百万。
- 关联表额外开销。语言和文章的对应关系单独存表，列表查询要 join，语言越多 join 越重。
- 菜单、小工具、字符串都要按语言存一份，wp_options 里的序列化数据变大，autoload 数据一多，每个请求的启动成本都上升。
- 缓存命中率下降。每种语言一套页面缓存，缓存条目翻倍，1G 内存的机器很容易被挤爆。
实测差距：同样一篇 1500 字的文章页，单语言站查询 30 次左右，四语言站因为要判断语言、取关联、过滤列表，常见到 60 到 90 次。这个量级必须开对象缓存，否则数据库先扛不住。所以做多语言之前，先把 速度优化 和页面缓存做完，再上语言包，顺序反过来会很痛苦。
数据库层面还要做三件事：wp_posts 上加 post_type、post_status、post_name 的组合索引；wp_options 里非必要的行改成 autoload=no；翻译关联表定期清理孤儿行。具体 SQL 在 数据库优化 里有。
什么情况下不该做多语言
说几个明确不该做的场景，省下的预算比省下的技术债更值钱：
- 海外流量占比不到一成，也没有明确的海外获客计划。先做一个英文落地页就够，不用上整站多语言。
- 内容更新频繁但没人校对。翻译跟不上，半年后英文站全是过期信息，比没有英文站更伤品牌。
- 只是「想让网站看起来国际化」。语言切换器挂着，内容全是机翻，用户点一次就不会点第二次。
- 技术底子不稳：主题没国际化、缓存没配、数据库已经很大。多语言会把这些问题放大两到三倍。
- 业务只在本地，客户全用中文。多语言的收益基本是心理上的，成本是实打实的。
确实要做，建议按「英文首页加核心产品页」先做一小块，跑三个月看数据，再决定要不要扩到全站。多语言的正确做法是逐步加，不是一次铺满。整体方案和常见坑可以对照 WordPress 多语言方案，语言数超过三种时，还要提前想清楚译员怎么排期、术语表谁来维护，这两件事比插件选型更影响最终效果。