WordPress multilingue em 2026: WPML, Polylang, MultilingualPress e headless
O WordPress multilingue é uma daquelas questões em que a resposta “depende” é honesta e útil. Em 2026 coexistem quatro estratégias comprovadas, cada uma com um equilíbrio diferente entre experiência editorial, SEO, desempenho e custo operacional. Este guia escolhe a estratégia certa para os perfis de cliente mais comuns e assinala o que corre mal quando a escolha é errada.
Este artigo liga-se ao pilar de serviços de WordPress headless para os casos em que o SEO e as Core Web Vitals decidem a escolha.
WordPress multilingue em 2026 em resumo
- Polylang Pro: escolha segura por defeito para WordPress editorial num único site, com equipas pequenas ou médias.
- WPML: padrão para lojas WooCommerce com fluxos de tradução complexos.
- MultilingualPress: adequa-se a redes Multisite onde cada idioma é um site separado.
- Headless com Astro 5+ ou Next.js 15: a melhor opção quando o controlo de SEO e o desempenho pesam mais do que a comodidade editorial.
- As quatro exigem hreflang correto, sitemaps por idioma e uma estrutura de URL limpa.
O que o WordPress faz com vários idiomas sem plugins
O núcleo do WordPress traduz a interface, não o conteúdo. Uma instalação nova funciona num único idioma do site, escolhido nas definições gerais, e o núcleo descarrega os pacotes de idioma correspondentes a partir de translate.wordpress.org para si próprio e para os plugins e temas do diretório do WordPress.org.
Desde o WordPress 4.7 cada utilizador pode escolher no perfil o idioma do painel de administração. O núcleo guarda-o como metadado do utilizador na chave locale e recorre ao idioma do site quando o campo está vazio (make.wordpress.org/core, 2016). A mesma versão acrescentou switch_to_locale() e restore_previous_locale(), que os plugins usam para enviar um e-mail no idioma do destinatário e não no idioma do pedido que o desencadeou.
O WordPress 6.5 substituiu o mecanismo que carrega as traduções. Os pacotes de idioma do WordPress.org passaram a incluir ficheiros .l10n.php ao lado dos .mo e .po, e quando existem ambos o núcleo carrega o ficheiro PHP, que o OPcache pode manter em memória. Os sites só com ficheiros .mo continuam a funcionar, e o filtro translation_file_format a devolver 'mo' desliga os ficheiros PHP (make.wordpress.org/core, 2024). Os plugins comerciais distribuídos fora do WordPress.org têm de gerar os ficheiros PHP por conta própria, por exemplo com wp i18n make-php do WP-CLI 2.10.
O que o núcleo não tem é uma ligação entre dois artigos que dizem o mesmo em dois idiomas. O roteiro do WordPress coloca os sites multilingues na fase 4 do projeto Gutenberg, depois da edição, da personalização e da colaboração, sem data de lançamento (roteiro do WordPress). Até essa fase chegar ao núcleo, cada uma das estratégias seguintes acrescenta a tradução de conteúdo através de um plugin, de uma rede Multisite ou de um front end separado.
Quais são as quatro estratégias de WordPress multilingue
1. Polylang (Pro) num único site WordPress
Como funciona: cada artigo, página, taxonomia e item de menu existe uma vez por idioma dentro de uma única instalação WordPress. O plugin liga as entradas correspondentes entre si. O editor de blocos mostra um seletor de idioma e os editores traduzem no mesmo painel.
Quando escolher:
- A equipa é pequena ou média e os fluxos editoriais são simples.
- O site tem até uma dúzia de idiomas, com uma estrutura partilhada.
- O orçamento de alojamento é modesto; manter uma única instalação WordPress é bastante mais barato do que Multisite.
- O WooCommerce não existe ou tem um papel limitado.
Compromissos: o WPML tem uma experiência ligeiramente mais polida para editores que mudam de idioma com frequência. O Polylang Pro dá menos problemas de compatibilidade com temas e plugins fora do ecossistema WooCommerce.
O que cobre a versão gratuita e o que acrescenta a Pro, segundo a ficha do Polylang no WordPress.org: a versão gratuita traduz artigos, páginas, multimédia, categorias, etiquetas, tipos de conteúdo personalizados e taxonomias, e lê o idioma a partir de um código no URL, de um subdomínio ou de um domínio próprio. A Pro acrescenta duplicação e sincronização de conteúdo entre traduções, slugs de URL traduzidos, tradução automática com DeepL e exportação e importação em XLIFF para tradutores externos. O WooCommerce precisa do add-on separado Polylang for WooCommerce, que traduz a loja, o carrinho, o checkout e a conta do cliente e envia os e-mails do WooCommerce no idioma do cliente.
2. WPML num único site WordPress
Como funciona: modelo de arquitetura semelhante ao do Polylang (um site, muitas entradas por idioma), mas com uma camada de gestão de traduções mais elaborada, que inclui memória de tradução, integração com tradutores profissionais e uma integração mais completa com o WooCommerce.
Quando escolher:
- O site é uma loja WooCommerce com produtos, categorias, atributos e textos do checkout traduzidos.
- A equipa recorre a serviços de tradução externos através de um sistema de gestão de traduções (TMS).
- Os plugins de que o site depende indicam o WPML como parceiro oficialmente suportado.
Compromissos: a licença do WPML é paga, com escalões consoante o número de sites. Algumas versões do WordPress e do WooCommerce causaram atritos no passado; o atraso de compatibilidade do WPML é real, mas normalmente curto.
3. MultilingualPress em WordPress Multisite
Como funciona: cada idioma é um site separado numa rede Multisite. O MultilingualPress liga os artigos entre sites e dá ao editor um seletor. A arquitetura é “uma rede, muitos sites” e não “um site, muitos idiomas”.
Quando escolher:
- Os idiomas funcionam de forma operacionalmente distinta: equipas editoriais separadas, calendários de publicação separados, conjuntos de plugins separados.
- Razões de marca ou legais exigem uma separação visível entre os sites de cada idioma (domínios diferentes, identidade visual diferente).
- O desempenho por idioma é importante e isolar os plugins de um idioma dos restantes ajuda.
Compromissos: o Multisite é um modelo operacional mais pesado. A compatibilidade de plugins diminui. A pesquisa e os relatórios entre sites exigem trabalho adicional.
4. WordPress headless com Astro 5+ ou Next.js 15
Como funciona: o WordPress (com Polylang ou WPML para a criação de conteúdo) passa a ser o back end. O site público é renderizado pelo Astro ou pelo Next.js, que obtém o conteúdo de cada idioma através da WordPress REST API ou do WPGraphQL. O hreflang, o sitemap, os dados estruturados e a cache na edge ficam a cargo do front end.
Quando escolher:
- O SEO e as Core Web Vitals influenciam diretamente a receita (comércio eletrónico, geração de leads, setores regulados).
- O conteúdo vai além da web (aplicação móvel, superfícies de agentes de IA, sindicação).
- O cliente quer controlo explícito sobre a estrutura de URL por idioma, a cache na edge e a precisão do hreflang.
- A jurisdição da UE é inegociável; Cloudflare Workers + uma origem WordPress alojada na UE é o padrão habitual.
Compromissos: a equipa editorial lida com uma ligeira camada intermédia (as pré-visualizações passam por um domínio separado). Há duas stacks para manter. As vantagens de arquitetura acumulam-se ao longo dos próximos cinco anos; o custo vê-se nos primeiros seis meses.
Este é o caminho descrito em detalhe no pilar de serviços de WordPress headless.
Como escolher uma estratégia de WordPress multilingue
| Critério | Polylang | WPML | MultilingualPress | Headless |
|---|---|---|---|---|
| Experiência editorial | Forte, um só painel | Forte, um só painel, TMS mais completo | Obriga a mudar de site | Indireta via REST ou GraphQL |
| Adequação ao WooCommerce | Boa com o add-on Polylang for WooCommerce | A melhor | Possível, mais configuração | Exige integração à medida |
| Controlo de SEO | O plugin emite hreflang | O plugin emite hreflang | O plugin emite hreflang | O front end controla totalmente o hreflang |
| Teto de desempenho | Limitado pelo WordPress | Limitado pelo WordPress | Limitado pelo WordPress | Limitado pela edge, muito mais alto |
| Custo operacional | Baixo | Baixo a médio (licença) | Médio (Multisite) | Médio a alto |
| Ideal para | Sites editoriais | Lojas online | Redes com várias marcas | Sites críticos em desempenho ou regulados |
Como o Polylang e o WPML guardam as traduções na base de dados
O modelo de armazenamento decide quão difícil será uma migração posterior, uma consulta própria ou uma exportação para headless.
O Polylang usa taxonomias do núcleo do WordPress. O código do plugin regista quatro: language e term_language guardam o idioma de um artigo ou de um termo, enquanto post_translations e term_translations agrupam os elementos que são traduções uns dos outros. Um artigo em alemão é um artigo normal com um termo language associado, por isso o WP_Query, as exportações e as cópias de segurança veem dados normais do WordPress.
O WPML usa tabelas próprias. Os idiomas e as ligações de tradução ficam em icl_translations: element_id é o ID do artigo ou o term_taxonomy_id, element_type indica o tipo de objeto, trid agrupa os elementos que são traduções uns dos outros, language_code é o idioma do elemento e source_language_code fica vazio no original (tabelas da base de dados do WPML). Os textos que não pertencem a artigos, como o slogan do site, vão para icl_strings e icl_string_translations, e os trabalhos de tradução para icl_translate_job e tabelas relacionadas. Uma consulta própria ou um script de migração tem de juntar estas tabelas, porque a tabela de artigos, sozinha, não diz em que idioma está cada artigo.
Como migrar do WPML para o Polylang
Nesta direção existe uma ferramenta dedicada. O WPML to Polylang, mantido pelos programadores do Polylang, importa idiomas, idiomas e traduções de artigos e termos (incluindo tipos de conteúdo e taxonomias personalizados), menus multilingues, traduções de strings e as definições de tradução dos campos ACF. Não apaga os dados do WPML. A ordem documentada: cópia de segurança da base de dados, desativar o WPML, ativar o Polylang e o importador sem criar nenhum idioma no Polylang, correr a importação a partir do ecrã do importador no menu de ferramentas e, por fim, acrescentar um seletor de idioma. O importador não tem gestão de erros própria, e os autores relatam um teste bem-sucedido num site com cerca de 9000 artigos e ficheiros multimédia. As ligações, os redirecionamentos e as integrações de plugins continuam a precisar de verificação manual depois, e por isso a troca deve acontecer antes do lançamento e não depois.
Como configurar o WordPress Multisite para uma rede de sites por idioma
O MultilingualPress funciona sobre uma rede Multisite, por isso as decisões da rede vêm primeiro. O Multisite ativa-se com define( 'WP_ALLOW_MULTISITE', true ); no wp-config.php, o que desbloqueia o ecrã de configuração da rede. Esse ecrã pede a escolha entre subdomínios e subdiretórios. A documentação do WordPress diz que a rede pode ser reconfigurada para a outra opção depois da instalação, mas que isso pode não ser fácil (criar uma rede). Escolha a estrutura que corresponde ao plano de URL dos idiomas antes de existir o primeiro subsite.
Domínios próprios por idioma não precisam de plugin. O mapeamento de domínios é nativo desde o WordPress 4.5: o administrador da rede edita o subsite e introduz o domínio completo, com o esquema, como endereço do site. Cada domínio adicional tem de apontar para a rede no DNS, cada domínio precisa de um certificado SSL (o SNI serve vários domínios a partir de um único servidor), e um início de sessão que falha em silêncio num subsite mapeado costuma resolver-se com define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); no wp-config.php (mapeamento de domínios no Multisite).
Como consultar conteúdo traduzido em WordPress headless
Um front end headless tem de pedir ao WordPress o conteúdo num idioma e os ID das respetivas traduções, porque constrói ele próprio o conjunto de hreflang e o seletor de idioma.
Com o Polylang isto funciona através da REST API, mas só no Polylang Pro. GET /wp/v2/posts?lang=fr lista os artigos em francês, e artigos e termos recebem dois campos adicionais: lang com o código do idioma e translations, um objeto que associa cada código de idioma ao ID do elemento traduzido (REST API do Polylang).
Com o WPML o caminho documentado é o GraphQL. O add-on WPML GraphQL requer o WPGraphQL, o WPML e o WPML String Translation. Acrescenta o argumento language às consultas de listas (where: { language: "de" }, ou "all" para todos os idiomas) e o campo translations a artigos e termos, de forma que um único pedido devolve uma página com as respetivas versões de idioma (WPML GraphQL). Os menus e as páginas de opções do ACF aceitam o mesmo argumento.
Em ambos os casos o front end assume o que antes era produzido pelo plugin: o hreflang construído a partir do campo translations, uma entrada no sitemap por idioma e os metadados traduzidos. As estruturas de URL, as regras de hreflang da Google e os sistemas de gestão de traduções são tratados no guia de estratégia global de conteúdo, por isso este artigo não os repete.
Hreflang, sitemaps, URL e metadados no WordPress multilingue
Cinco elementos que qualquer estratégia de WordPress multilingue tem de entregar corretamente:
Tags hreflang. Cada página tem de declarar as suas alternativas por idioma, mais uma entrada autorreferencial, mais um x-default. Teste com ferramentas reais (Sitebulb, Screaming Frog ou um crawler feito à medida).
Sitemap por idioma. O Yoast, o Rank Math e os front ends headless suportam a geração de sitemaps por idioma. Valide o resultado manualmente antes de o submeter na Google Search Console.
Estrutura de URL limpa. Use subdiretórios (/en/, /de/) ou subdomínios (en.example.com) de forma consistente. Os parâmetros de consulta (?lang=en) são um antipadrão em 2026 e causam problemas de indexação.
Dados estruturados traduzidos. Os blocos JSON-LD de Schema.org precisam de name, description e inLanguage traduzidos em cada página. A tradução automática de dados estruturados é uma falha silenciosa comum.
Metadados traduzidos. O título SEO, a meta description, os títulos Open Graph e os Twitter cards traduzem-se de forma independente do corpo do texto. O Polylang e o WPML tratam disto; os front ends headless exigem templates explícitos por idioma.
Erros comuns no WordPress multilingue
Três padrões que estragam o WordPress multilingue em produção:
Mudar de estratégia a meio do caminho. Começar com Polylang e passar para WPML, ou o contrário, costuma obrigar a reescrever ligações, redirecionamentos e integrações de plugins. Escolha uma vez, com profundidade, antes de crescer.
Tradução automática como único fluxo de tradução. Texto editorial produzido por máquina lê-se como texto de máquina. Use a tradução automática apenas para primeiros rascunhos; a versão pública é revista por um falante nativo.
Ignorar o índice do motor de pesquisa. Os sites multilingues têm N vezes mais URL. Os problemas de indexação acumulam-se. Analise a Search Console todas as semanas durante os primeiros três meses após o lançamento e novamente sempre que chegar uma atualização importante de um plugin ou tema.
Melhor configuração de WordPress multilingue por tipo de site
Para um WordPress editorial num único site em 2026: o Polylang Pro é o ponto de partida certo, a menos que o WooCommerce ou requisitos de conformidade o levem para outro lado.
Para uma loja WooCommerce: o WPML é o ponto de partida certo.
Para uma rede com várias marcas ou regiões: MultilingualPress em Multisite.
Para um site crítico em desempenho ou regulado: headless com Astro ou Next.js, com o WordPress como back end editorial. O pilar de serviços de WordPress headless e o guia de Cloudflare Workers e WordPress na edge cobrem os detalhes de arquitetura.
