Polylang vs WPML vs TranslatePress: Comparativo de 2026

Você está prestes a construir um site WordPress multilíngue. Você abre o Google, digita "melhor plugin de tradução WordPress" e, em dez minutos, está afogado em avaliações de afiliados, tabelas comparativas que parecem copiadas e coladas, e conselhos conflitantes sobre Polylang, WPML e TranslatePress. Cada avaliação convenientemente conclui com "O Plugin X é o vencedor", e você não tem como saber qual deles realmente funcionará para o seu projeto.

Aqui está a resposta honesta: esses três plugins resolvem o mesmo problema superficial – exibir seu site em vários idiomas – mas adotam abordagens fundamentalmente diferentes. O WPML armazena traduções em posts duplicados. O Polylang faz o mesmo, mas mantém seu núcleo gratuito. O TranslatePress traduz HTML renderizado em tempo real. Cada arquitetura apresenta compensações reais em termos de desempenho, SEO, fluxo de trabalho de conteúdo e manutenção a longo prazo.

Este comparativo elimina o ruído dos afiliados, trazendo os detalhes que realmente afetam seu site em 2026: preços a partir deste ano, como cada plugin impacta seus Core Web Vitals, o que quebra quando você troca de plugin e por que um número crescente de equipes está ignorando os três e traduzindo arquivos .po diretamente.

O Que Esses Plugins Realmente Fazem (Eles Não São Iguais)

Antes de comparar os recursos, você precisa entender que esses plugins usam três arquiteturas diferentes. Escolha a arquitetura errada e nenhuma configuração de plugin irá salvá-lo.

WPML: Modelo de Post Duplicado

O WPML cria uma cópia separada de cada post, página, termo de taxonomia e item de menu para cada idioma. Sua tabela posts cresce linearmente com o número de idiomas. Um site com 500 posts e 5 idiomas acaba com 2.500 linhas em wp_posts, além de postmeta correspondentes, relacionamentos de termos e revisões.

Isso oferece estruturas de URL limpas (/es/producto/, /fr/produit/), compatibilidade total com a maioria dos plugins e edição independente por idioma. O custo são o tamanho do banco de dados e a complexidade das consultas – cada consulta de arquivo precisa filtrar por idioma, e sites complexos começam a desacelerar em torno de 10.000+ posts traduzidos.

Polylang: Também Post Duplicado (Com Núcleo Gratuito)

O Polylang usa a mesma abordagem de post duplicado que o WPML, mas vem com um plugin principal gratuito e um complemento Pro pago para recursos avançados, como tradução de strings para plugins e suporte a WooCommerce. Nos bastidores, a arquitetura é quase idêntica à do WPML – as mesmas características de desempenho, o mesmo comportamento de escalonamento.

TranslatePress: Reescrita de HTML Front-End

O TranslatePress adota uma abordagem completamente diferente. Em vez de duplicar posts, ele traduz o HTML renderizado em tempo real. Você visita seu site em francês, e o TranslatePress intercepta a saída, busca as traduções em sua própria tabela e substitui as strings antes de enviar a resposta ao navegador.

Isso significa que você não duplica posts. Mas também significa que cada renderização de página executa consultas extras para buscar strings traduzidas. Para sites com alto tráfego, isso cria um limite de desempenho que os outros plugins não possuem.

Detalhamento de Preços e Licenciamento (2026)

Os preços são a coisa mais fácil de verificar e o lugar mais difícil para as avaliações de afiliados serem honestas. Aqui estão os números de 2026, conforme publicados no site de cada fornecedor.

Alguns pontos que as tabelas de comparação geralmente escondem:

• A tradução automática custa extra. O Editor de Tradução Avançada do WPML usa DeepL ou Google, cobrado por palavras. O Polylang se integra com Lingotek ou DeepL, também cobrado por palavras. O TranslatePress cobra por "créditos de tradução automática" além da licença.
• O suporte a WooCommerce é restrito. O Polylang exige o plano Business para WooCommerce. O WPML exige o plano Multilingual CMS. O TranslatePress Personal não inclui tradução de strings do WooCommerce.
• Os preços de renovação sobem. Algumas avaliações citam o desconto do primeiro ano. O custo de vários anos é o que importa.

Para um detalhamento completo de como esses custos se acumulam em relação às taxas de freelancers e à tradução em nuvem, veja nosso comparativo de custos de tradução para WordPress.

Desempenho e Impacto na Velocidade do Site

É aqui que as diferenças arquitetônicas mais importam. Os Core Web Vitals afetam seu SEO diretamente, e os plugins de tradução são uma das causas ocultas mais comuns de pontuações baixas de LCP e INP.

WPML e Polylang: Peso do Banco de Dados

Ambos os plugins adicionam joins à maioria das consultas de front-end. O WP_Query precisa filtrar por idioma, o que significa term_taxonomy e term_relationships extras em cada página de arquivo. Em um site pequeno, você não notará. Em um site com mais de 5.000 posts em 5 idiomas, você verá o TTFB aumentar em 200-500ms sem cache agressivo.

TranslatePress: Reescrita Por Requisição

O TranslatePress executa a busca de strings em cada página renderizada. Mesmo com cache de objetos, o plugin impõe um limite à velocidade com que seu site pode responder, pois ele precisa interceptar, analisar, reescrever e reemitir o HTML. Medimos isso em detalhes em nosso benchmark de arquivos .mo estáticos vs. plugins de tradução – a reescrita de front-end foi consistentemente classificada como a abordagem mais lenta em todos os cenários de teste.

A Questão Composta: Pilhas de Plugins

Raramente você executa um plugin de tradução isoladamente. Adicione WooCommerce, um construtor de páginas, um plugin de SEO e uma camada de cache, e cada plugin de tradução terá seus próprios shims de compatibilidade. O WPML fornece adaptadores para dezenas de plugins. O Polylang é um pouco mais leve. O TranslatePress tem a menor pegada de compatibilidade, mas reescreve o HTML depois que todos os outros plugins terminam, o que pode anular as otimizações de cache do restante da sua pilha.

Qualidade e Fluxo de Trabalho da Tradução

A qualidade da tradução automática depende do motor que cada plugin utiliza, e não do próprio plugin. O WPML usa DeepL, Google ou Microsoft. O Polylang usa DeepL, Google ou Lingotek. O TranslatePress usa DeepL ou Google.

Mais importante é como a tradução é entregue e armazenada:

• WPML e Polylang armazenam traduções em suas próprias tabelas e as servem via PHP. A edição exige fazer login, abrir o editor avançado e salvar string por string.
• TranslatePress usa um editor visual de front-end. Você clica em uma string na página e edita diretamente. Usuários não técnicos gostam disso, mas não escala para centenas de páginas.

Nenhum desses três plugins protege placeholders ou tokens de código por padrão. Se você executar tradução automática em suas strings, ainda terá a mesma corrupção de %s, quebra de tags HTML e erros de forma plural que atormentam a tradução bruta por IA. Nosso guia sobre tradução manual vs. IA para WordPress aprofunda as compensações de segurança.

A Alternativa Escondida: Arquivos .mo Estáticos (Sem Plugin)

Todo tema e plugin WordPress vêm com arquivos de template .pot. Um arquivo .po devidamente traduzido, compilado para .mo e colocado em wp-content/languages/, é lido uma vez por carregamento de página pelo core do WordPress – com zero consultas extras ao banco de dados, zero sobrecarga de plugin e compatibilidade total com CDN.

É assim que a comunidade do core do WordPress tem localizado o próprio WordPress em mais de 70 idiomas há 20 anos. É rápido, estável e não o prende ao ecossistema de nenhum fornecedor.

A única razão pela qual a maioria dos proprietários de sites usa plugins é que traduzir arquivos .po manualmente é tedioso – você abre o Poedit, traduz 2.000 strings à mão e torce para não ter quebrado um placeholder. Ferramentas de tradução em nuvem removem essa barreira por completo. Faça upload do .po, baixe o .po + .mo traduzido, coloque em wp-content/languages/themes/your-theme-es_ES.mo, pronto.

Sem licença de plugin. Sem penalidade de desempenho. Sem aprisionamento de fornecedor (vendor lock-in). Se o tema for atualizado e adicionar novas strings, traduza o novo .pot e implante o arquivo .mo atualizado.

Essa abordagem funciona lindamente para conteúdo que vive no código (UI do tema, strings de plugin, mensagens de erro, rótulos de botões). Para conteúdo que vive no banco de dados (posts, páginas, descrições de produtos), você ainda precisa de um plugin ou de um fluxo de trabalho manual de post duplicado. Muitas equipes combinam os dois: arquivos .mo estáticos para UI, WPML ou Polylang para conteúdo. O resultado é mais rápido, mais barato e mais fácil de manter do que depender de apenas um plugin.

Quando Escolher Cada Abordagem

Guia rápido de decisão com base no tipo de projeto:

• Blog pequeno, 2-3 idiomas, principalmente conteúdo de UI: Arquivos .mo estáticos. Ignore o plugin.
• Site com muito conteúdo, equipe editorial, muitos posts: Polylang ou WPML. Escolha Polylang se precisar de um ponto de partida gratuito e recursos Business posteriormente; escolha WPML se precisar de custom post types e taxonomias multilíngues em escala.
• Fluxo de trabalho de edição visual para usuários não técnicos: TranslatePress, mas aceite a desvantagem de desempenho e evite-o em lojas WooCommerce de alto tráfego.
• Loja WooCommerce com grande catálogo: WPML Multilingual CMS mais arquivos .mo para a UI do tema. Polylang Business também funciona.
• Agência gerenciando mais de 20 sites de clientes: Mova o máximo de tradução possível para arquivos .mo. Veja nosso fluxo de trabalho de localização ideal para agências para a arquitetura completa.

Juntando Tudo

Polylang, WPML e TranslatePress são todas ferramentas legítimas. Cada uma tem usuários reais que lançam sites multilíngues com sucesso. O erro é tratá-las como alternativas intercambiáveis e escolher uma com base em uma tabela comparativa. São arquiteturas fundamentalmente diferentes, com limites de desempenho e fluxos de trabalho de conteúdo distintos.

A questão mais profunda que a maioria dos proprietários de sites nunca faz é se eles realmente precisam de um plugin de tradução. Uma grande parte do que esses plugins traduzem – rótulos de botões, mensagens de erro, UI do tema, strings de checkout – vive em arquivos .po que o core do WordPress pode ler nativamente. Traduzir esses arquivos uma vez e colocar o .mo compilado em wp-content/languages/ elimina toda uma classe de sobrecarga de plugins, renovações de licenças e problemas de desempenho.

Pronto para traduzir seus arquivos .po do WordPress sem adicionar outro plugin à sua pilha? Experimente o SimplePoTranslate gratuitamente – não é necessário cartão de crédito. Faça upload do .po, baixe o .po + .mo traduzido, implante.