早在2021年，我在Seahawk为一个德国电商客户做上线准备。七种语言、WooCommerce、Elementor，还有一个已经延期的截止日期。我装了WPML，就像你一样，设置语言切换器，运行第一次翻译同步，然后看着首字节时间在£40/月的托管主机上爬到2.8秒以上。客户不满意。坦白说，我也不满意。
就从那一刻起，我开始真正测试其他选择，而不是假设WPML是答案。四年过去了，几百个多语言项目之后，我有了意见。很强烈的意见。
---
为什么人们在2026年开始放弃WPML
WPML并不差。让我把话说清楚。对于拥有内容团队在工作流中管理翻译的复杂编辑网站，它仍然真正很有能力。但有三件事一直在推动客户（和我）转向替代方案。
价格蔓延。多语言 CMS 方案——你实际需要的那个，用来处理 WooCommerce 或自定义文章类型——现在是 99 美元/年。这是按网站计算的。为中小企业做白标工作的代理机构不总是能把这笔费用转嫁给客户，不想进行那种讨论。 The Multilingual CMS plan, the one you actually need for WooCommerce or custom post types, sits at $99/year now. That's per site. Agencies doing white-label work for SMEs can't always pass that on without a conversation they'd rather not have.
性能开销。WPML 在每次页面加载时会增加大量数据库查询。在一个有数千篇文章的大型网站上，这种影响会累积。我见过它在未针对它专门优化的网站上为 TTFB 增加 400-600ms。谷歌的 Core Web Vitals 指导让这种延迟越来越难以忽视。 WPML adds a non-trivial number of database queries per page load. On a large site with thousands of posts, that compounds. I've seen it add 400-600ms to TTFB on sites that weren't tuned specifically around it. Google's Core Web Vitals guidance makes that kind of drag increasingly expensive to ignore.
简单需求的复杂性。如果客户只需要三种语言和二十个页面，WPML 的配置界面会令人生畏。你要点击字符串翻译、翻译管理、WooCommerce 多语言设置……有很多东西。有时你只需要能在一个下午搞定的东西。 If a client needs three languages and twenty pages, WPML's configuration surface is intimidating. You're clicking through String Translation, Translation Management, WooCommerce Multilingual setup... it's a lot. Sometimes you just need something that works in an afternoon.
---
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 这样的东西，这让我想到……WPML's own ecosystem or something like Linguise, which brings me to...
---
TranslatePress：速度优先项目的最佳选择
TranslatePress 改变了我对多语言 WordPress 的看法。它没有采用文章复制模型（每种语言有单独的文章），而是使用前端可视化编辑器，让你直接在渲染的页面上翻译文本。你看到你的网站，点击一个字符串，输入翻译。完成。
这对性能很重要。没有特定语言的文章复制膨胀你的数据库。翻译后的字符串存储在自定义表中，而不是作为单独的文章。在 Seahawk 于 2024 年末为一个法语比利时零售客户运营的项目中，我们在项目中途从 WPML 切换到 TranslatePress（我知道不理想，但客户改变了范围），每页的数据库查询数下降了约 40%。
DeepL 集成
TranslatePress Pro 内置了 DeepL API 集成。对于想要以机器翻译作为起点然后进行人工审校的客户，这个工作流程比我手工拼凑的任何东西都要好得多。你设置自动翻译发布，编辑审查和更正，完成。50 页网站的周转时间从几天缩短到一个下午。DeepL API integration built in. For clients who want machine translation as a starting point and human review after, this workflow is miles better than anything I've patched together manually. You set it to auto-translate on publish, your editor reviews and corrects, and you're done. The turnaround on a 50-page site goes from days to an afternoon.
价格约为个人计划 $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 自己的文档如果你想看内容关系的工作方式的话实际上相当不错。MultilingualPress's own documentation is actually decent if you want to see how the content relationships work.
缺点是运营的复杂性。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 也能做到，但需要更多配置。 If the client needs separate domains per language (
example.de,example.fr), MultilingualPress or WPML handle this most cleanly. TranslatePress and Polylang can do it but need more config. - 涉及 WooCommerce 吗？如果是，请列入 WPML、Polylang Pro + WooCommerce 附加组件或 TranslatePress Business。在你的具体产品目录规模上测试每一个。 If yes, shortlist WPML, Polylang Pro + WooCommerce add-on, or TranslatePress Business. Test each on your specific product catalogue size.
- 客户想要机器翻译吗？使用 DeepL 的 TranslatePress 或 Weglot 最简洁。WPML 的翻译管理也能用，但感觉更像企业级工具。 TranslatePress with DeepL or Weglot are the cleanest. WPML's translation management also works but feels more enterprise-y.
- 你的代理商需要覆盖多少个网站？Polylang Pro 的无限站点许可证在批量使用时对代理商来说是突出的价值选择。 Polylang Pro's unlimited-sites licence is the standout value for agencies at volume.
- 前端是无头架构还是大量依赖 JavaScript？使用 Weglot 或 Linguise。不要在 Next.js 前端上与文章重复插件搏斗。 Weglot or Linguise. Don't fight with post-duplication plugins on a Next.js frontend.
- 这是一个多站点网络吗？使用 MultilingualPress。就这样。 MultilingualPress. That's it.
---
只使用区块编辑器的原生多语言功能怎么样？
WordPress 核心多年来一直在缓步走向原生多语言支持。Matt Mullenweg 曾多次公开提及过，自 2020 年以来 Gutenberg GitHub 上也有过相关讨论。截至 2026 年初，它仍然以任何有意义的、生产就绪的形式不存在。Gutenberg GitHub discussions about it going back to 2020. As of early 2026, it still isn't here in any meaningful production-ready form.
我不会因为等待它而推迟插件决策。用今天存在的东西来构建。如果原生支持落地，迁移将是你很乐意处理的问题。
---
常见问题
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配置更重要。hreflang tags correctly when configured properly. The gap isn't in hreflang implementation, it's in how fast each renders the page. SEO in 2026 is heavily weighted toward Core Web Vitals, so the performance difference between a bloated WPML install and a lean TranslatePress setup can matter more than the hreflang configuration.
做多语言WordPress最便宜的方式是什么？
Polylang免费版加上每篇文章的手动翻译。零成本。适用于编辑人员有耐心的小网站。一旦你需要WooCommerce、机器翻译或50篇以上的文章，你就会想要为某样东西付费。
---
多语言WordPress生态已经真正成熟了。WPML长期垄断了这个领域，竞争让一切都变得更好。选择时要基于你的架构、你客户的预算，以及你自己愿意花多少精力去配置，而不是基于2018年的默认答案。