早在2021年，我在Seahawk为一个德国电商客户做上线准备。七种语言、WooCommerce、Elementor，还有一个已经延期的截止日期。我装了WPML，就像你一样，设置语言切换器，运行第一次翻译同步，然后看着首字节时间在£40/月的托管主机上爬到2.8秒以上。客户不满意。坦白说，我也不满意。
就从那一刻起，我开始真正测试其他选择，而不是假设WPML是答案。四年过去了，几百个多语言项目之后，我有了意见。很强烈的意见。
---
为什么人们在2026年开始放弃WPML
WPML并不差。让我把话说清楚。对于拥有内容团队在工作流中管理翻译的复杂编辑网站，它仍然真正很有能力。但有三件事一直在推动客户（和我）转向替代方案。
价格蔓延。多语言 CMS 方案——你实际需要的那个，用来处理 WooCommerce 或自定义文章类型——现在是 99 美元/年。这是按网站计算的。为中小企业做白标工作的代理机构不总是能把这笔费用转嫁给客户，不想进行那种讨论。
性能开销。WPML 在每次页面加载时会增加大量数据库查询。在一个有数千篇文章的大型网站上，这种影响会累积。我见过它在未针对它专门优化的网站上为 TTFB 增加 400-600ms。谷歌的 Core Web Vitals 指导让这种延迟越来越难以忽视。
简单需求的复杂性。如果客户只需要三种语言和二十个页面，WPML 的配置界面会令人生畏。你要点击字符串翻译、翻译管理、WooCommerce 多语言设置……有很多东西。有时你只需要能在一个下午搞定的东西。
---
Polylang：大多数代理机构忽视的主力工具
到目前为止，我在 200+ 个网站上使用过 Polylang。免费版本处理基础的文章/页面/分类法翻译，不需要花一分钱。Pro 版本（据我所知是 £99/年，无限网站）才是真正的竞争力所在，因为这个"无限网站"许可模式对代理机构来说是个完全不同的命题，相比 WPML 的按网站计费。
Polylang 的优势
UI 很清晰。语言分配直接在文章编辑器侧边栏进行，不会接管你的仪表板，性能影响比 WPML 明显要轻。按我在 2025 年 3 月在一个拥有 500 篇文章的暂存网站上运行的对标测试，WPML 对比 Polylang Pro，Polylang 减少了约 180ms 的 TTFB。不算巨大，但是切实的。
它能很好地与 Elementor、Bricks、ACF 以及 WooCommerce（通过 WooCommerce 插件，需要额外付费）集成。最后这点是问题所在：WooCommerce 支持需要插件，一旦加上这个，与 WPML 的成本差距就缩小了。
Polylang 的不足之处在于机器翻译。核心版本没有内置的 DeepL 或 Google Translate 集成。你需要第三方桥接，比如 WPML 自己的生态系统或者像 Linguise 这样的东西，这让我想到……
---
TranslatePress：速度优先项目的最佳选择
TranslatePress 改变了我对多语言 WordPress 的看法。它没有采用文章复制模型（每种语言有单独的文章），而是使用前端可视化编辑器，让你直接在渲染的页面上翻译文本。你看到你的网站，点击一个字符串，输入翻译。完成。
这对性能很重要。没有特定语言的文章复制膨胀你的数据库。翻译后的字符串存储在自定义表中，而不是作为单独的文章。在 Seahawk 于 2024 年末为一个法语比利时零售客户运营的项目中，我们在项目中途从 WPML 切换到 TranslatePress（我知道不理想，但客户改变了范围），每页的数据库查询数下降了约 40%。
DeepL 集成
TranslatePress Pro 内置了 DeepL API 集成。对于想要以机器翻译作为起点然后进行人工审校的客户，这个工作流程比我手工拼凑的任何东西都要好得多。你设置自动翻译发布，编辑审查和更正，完成。50 页网站的周转时间从几天缩短到一个下午。
价格约为个人计划 $89/年，商业版 $179（3 个站点），开发者版 $299（无限）。对于代理商，开发者版是要看的。
一个诚实的局限：非常复杂的 WooCommerce 商店，包含大量动态内容，可能会暴露字符串检测的漏洞。TranslatePress 能捕捉大多数内容，但如果你有高度定制的结账流程或来自晦涩插件的插件生成字符串，你可能会遗漏一些。预留几个小时进行手动字符串清理。
---
Weglot：当客户有预算并且想要零摩擦时
我直说了：Weglot 很贵。£99/年只能用一个语言对，最多 10,000 个词。一个真正的商业网站立刻就会超过这个限额，之后的价格上升得很快。对于有三种语言的中型网站，你可能每年要花 £300-400。
但关键是这样。设置大约需要 15 分钟。你安装插件，粘贴一个 API 密钥，选择语言，然后就能用了。没有配置的复杂流程，也不用担心和你的页面构建器的兼容性问题。它比这个列表中的任何其他选项都更好地处理 JavaScript 渲染的内容，如果你运行的是 React 密集或带有大量动态小部件的 Elementor 设置，这很重要。
我特别推荐 Weglot 的情况是：客户是有真实收入的初创公司，他们需要快速行动，多语言对他们的产品来说真的是边缘功能（不是重点）。对于一个从英文扩展到德文和法文的 SaaS 登陆页面，如果预算不是问题的话，这是显而易见的选择。
---
MultilingualPress：WordPress Multisite 设置的选择
如果你在运行 WordPress Multisite，而在 2026 年，multisite 对于企业和加盟客户来说正在经历一次小幅复兴，那么 MultilingualPress 就是你需要的插件。就这么简单。
它在你的网络中为每种语言创建一个单独的站点。这是一个与这个列表中其他选项相比从根本上不同的架构方法。每个语言站点都是独立的：有自己的数据库记录，有自己的 URL 结构（你可以用子域名或不同的域名），有自己的后台。它们通过关系连接，让你能在站点之间链接等效的内容。
Seahawk 在 2023 年有一个加盟客户，拥有 14 个地区站点、6 种语言，总部想要集中内容控制并支持本地编辑覆盖。WordPress Multisite 上的 MultilingualPress 确实是正确答案。没有其他选项能比得上。MultilingualPress 自己的文档如果你想看内容关系的工作方式的话实际上相当不错。
缺点是运营的复杂性。Multisite 更难维护，更难交接给非技术型的客户，而不支持 multisite 的插件（仍然还有一些）就成了你的问题。带着清楚的认识进去。
---
Linguise：面向无头架构和 API 驱动项目的黑马
Linguise 不是传统意义上的 WordPress 插件。它是一个代理层翻译解决方案，部署在你的网站前面，在边缘端处理翻译。这使它对前端采用 Next.js 或 Nuxt 构建的无头 WordPress 设置特别有吸引力。
我在 2025 年初的一个无头项目中测试了它，该客户使用基于 Gutenberg 的 CMS 为 Next.js 前端供应内容。WPML 和 TranslatePress 都不太合适，因为翻译需要在渲染输出中发生，而不是在 WordPress 内容字段中。Linguise 处理得很干净。
价格也不便宜，套餐起价约 €15/月，但对于合适的架构，没有其他方案能以相同的方式解决这个问题。
---
如何真正做出选择
这是我在构建了数千个多语言网站后总结的决策框架。不是一个严格的算法，而是一套能快速缩小范围的问题。
- URL 策略是什么？如果客户需要为每种语言使用单独的域名（example.de、example.fr），MultilingualPress 或 WPML 处理得最干净。TranslatePress 和 Polylang 也能做到，但需要更多配置。
- 涉及 WooCommerce 吗？如果是，请列入 WPML、Polylang Pro + WooCommerce 附加组件或 TranslatePress Business。在你的具体产品目录规模上测试每一个。
- 客户想要机器翻译吗？使用 DeepL 的 TranslatePress 或 Weglot 最简洁。WPML 的翻译管理也能用，但感觉更像企业级工具。
- 你的代理商需要覆盖多少个网站？Polylang Pro 的无限站点许可证在批量使用时对代理商来说是突出的价值选择。
- 前端是无头架构还是大量依赖 JavaScript？使用 Weglot 或 Linguise。不要在 Next.js 前端上与文章重复插件搏斗。
- 这是一个多站点网络吗？使用 MultilingualPress。就这样。
---
只使用区块编辑器的原生多语言功能怎么样？
WordPress 核心多年来一直在缓步走向原生多语言支持。Matt Mullenweg 曾多次公开提及过，自 2020 年以来 Gutenberg GitHub 上也有过相关讨论。截至 2026 年初，它仍然以任何有意义的、生产就绪的形式不存在。
我不会因为等待它而推迟插件决策。用今天存在的东西来构建。如果原生支持落地，迁移将是你很乐意处理的问题。
---
常见问题
WPML 在 2026 年还值得使用吗？
对于拥有专业翻译团队的大型编辑网站，绝对可以。翻译管理模块、XLIFF导出、与WordPress生态中几乎所有内容的兼容性，它仍然是最完整的选项。缺点是大规模部署时价格昂贵、大数据库性能不佳，以及对简单项目来说过于复杂。
我可以在项目进行中从WPML切换到另一个插件吗？
从技术上讲可以，实际上很痛苦。WPML将语言元数据存储在自己的表和文章元数据中。大多数其他插件无法本地读取这些数据。GitHub上有一些迁移工具和脚本，但你需要花时间在上面。我做过三次WPML迁移，每一次都需要自定义SQL工作。中等规模网站的最少计划时间是半天。
TranslatePress支持Elementor和Bricks吗？
Elementor：支持，而且配合得很好。TranslatePress的前端翻译器会渲染Elementor输出并可靠地捕获字符串。Bricks是较新的，兼容性在2024-2025年间已经改进，在提交到生产网站前我会对你的特定模板进行彻底测试。
哪个多语言插件最适合SEO？
所有主流插件（WPML、Polylang、TranslatePress）在正确配置时都能正确实现hreflang标签。差距不在hreflang实现上，而在于每个插件渲染页面的速度。2026年的SEO很大程度上权重于Core Web Vitals，所以臃肿的WPML安装和精简的TranslatePress安装之间的性能差异可能比hreflang配置更重要。
做多语言WordPress最便宜的方式是什么？
Polylang免费版加上每篇文章的手动翻译。零成本。适用于编辑人员有耐心的小网站。一旦你需要WooCommerce、机器翻译或50篇以上的文章，你就会想要为某样东西付费。
---
多语言WordPress生态已经真正成熟了。WPML长期垄断了这个领域，竞争让一切都变得更好。选择时要基于你的架构、你客户的预算，以及你自己愿意花多少精力去配置，而不是基于2018年的默认答案。