Expandir um negócio globalmente é um empreendimento massivo. O seu website é a embaixada digital da sua marca em cada novo país onde entra.
Em 2026, lançar um novo mercado não é apenas instalar um plugin de tradução. Trabalho uma estratégia global de conteúdo como três linhas paralelas: encaminhamento técnico e hreflang, automação em torno da memória de tradução, e revisão cultural de terminologia e UX.
Este guia mostra como construir uma arquitetura WordPress que suporte escala global sem caos operacional. As regras de pesquisa citadas abaixo vêm do Google Search Central, e o comportamento dos plugins da documentação do Polylang e do WPML.
Subdiretórios, subdomínios ou ccTLD para sites multilingues
A primeira decisão que toma é a estrutura de URL mais permanente.
- Subdiretórios (
example.com/pt-pt/): O padrão de ouro. Melhor para consolidar a equidade de links (autoridade SEO) num único domínio. Mais fácil de gerir numa única configuração WordPress Multisite ou Polylang. - Subdomínios (
pt.example.com): Útil se a sua equipa portuguesa precisar de autonomia total ou se o site português correr num cluster de servidores fisicamente diferente. Mais difícil de construir autoridade SEO. - ccTLDs (
example.pt): O Google descreve um domínio de país como um sinal forte de segmentação para esse país, mas é a opção mais cara de manter. Começa com zero autoridade SEO para cada novo país.
Vantagens e desvantagens de cada estrutura
Os subdiretórios mantêm todo o site num só domínio, por isso os links que uma versão linguística conquista também ajudam as outras. A gestão fica centralizada e o custo de infraestrutura é o mais baixo. No WordPress, uma rede Multisite com subsites em subdiretórios é uma forma comum de o fazer: cada subsite tem o seu próprio conteúdo, definições de tema e opções, e todos partilham uma instalação do WordPress.
Os subdomínios separam claramente as versões linguísticas. Cada subdomínio pode ficar alojado noutro servidor ou noutra região, o que ajuda quando equipas diferentes gerem cada mercado. O preço é mais trabalho de gestão, e os links que um subdomínio recebe valem menos para os outros do que num único anfitrião.
Domínios de país como example.es, example.com.mx ou example.com.br enviam o sinal geográfico mais forte e podem ganhar a confiança local. Fazem sentido para empresas com presença legal em cada país. Cada domínio começa sem autoridade, os custos de link building multiplicam-se e a operação fica mais complexa.
O que a documentação do Google diz sobre cada estrutura de URL
O guia do Google sobre sites multilingues e multirregionais compara quatro opções:
| Estrutura | Exemplo | Vantagens segundo o Google | Desvantagens segundo o Google |
|---|---|---|---|
| ccTLD | example.pt | Segmentação geográfica clara, localização do servidor irrelevante, sites fáceis de separar | Caro, disponibilidade limitada, mais infraestrutura, regras de ccTLD rígidas, apenas um país |
| Subdomínio num gTLD | pt.example.com | Fácil de configurar, várias localizações de servidor possíveis, fácil de separar | O utilizador não percebe pelo URL se “pt” é um idioma ou um país |
| Subdiretório num gTLD | example.com/pt/ | Fácil de configurar, pouca manutenção no mesmo anfitrião | O utilizador não reconhece a segmentação pelo URL, uma só localização de servidor, mais difícil de separar |
| Parâmetro de URL | example.com?loc=pt | Nenhuma | Não recomendado: segmentação difícil, alvo pouco claro para o utilizador |
A mesma página pede URLs diferentes para versões linguísticas diferentes e desaconselha mudar o idioma de um só URL com cookies ou definições do navegador.
Recomendação: Para a maioria das empresas, os subdiretórios são a escolha correta.
Como o Polylang e o WPML associam idiomas a URLs
Os dois plugins principais suportam as três estruturas, por isso a escolha é uma definição e não uma reconstrução.
As modificações de URL do Polylang oferecem o código do idioma como parâmetro (?lang=en) com ligações permanentes simples, o idioma como nome de diretório (/en/my-post/), a predefinição com ligações permanentes legíveis, e subdomínios ou vários domínios. Com subdomínios ou domínios, todos os anfitriões têm de apontar para o mesmo diretório raiz do WordPress. O Polylang pode ainda esconder o código do idioma predefinido, o que preserva os URLs antigos num site existente.
Os formatos de URL de idioma do WPML são idiomas em diretórios, um domínio diferente por idioma (domínios separados ou subdomínios) e o nome do idioma como parâmetro. Os diretórios exigem ligações permanentes legíveis e o módulo rewrite do Apache. O WPML desaconselha criar diretórios reais ou instalar o WordPress várias vezes, e também acrescentar regras de redirecionamento próprias ao .htaccess, porque o WPML cria os seus próprios redirecionamentos. Um domínio por idioma exige configuração de DNS e do servidor. O formato com parâmetro não exige alterações no servidor, e é precisamente esse o formato que o Google não recomenda.
Diferença entre localização e tradução
Tradução é mudar palavras. Localização é mudar significado.
- Moeda: Não converta apenas $100 para 92€. Torne-o 99€. O preço psicológico importa.
- Datas: 05/04/2026 é 4 de maio nos EUA, mas 5 de abril em Portugal. Use ISO (2026-05-04) ou meses por extenso no código.
- Imagens: Use fotos que reflitam a demografia local. Uma foto de um jogo de futebol americano não irá ressoar no Brasil (ou em Portugal).
Lista de verificação de formatos, moeda e adaptação cultural
Formatos e convenções a verificar em cada mercado:
- Formatos de data: DD/MM/AAAA em grande parte da Europa e da América Latina, MM/DD/AAAA nos EUA
- Separadores numéricos: 1.000,50 em muitos países europeus, 1,000.50 nos EUA e no Reino Unido
- Moeda: o símbolo, a posição e o formato mudam consoante a região
- Direção do texto: da esquerda para a direita nos alfabetos latinos, da direita para a esquerda em árabe e hebraico
- Unidades de medida: métricas ou imperiais
Adaptações culturais a planear:
- Paletas de cores e o seu significado local
- Imagens e modelos que reflitam o público local
- Tom e nível de formalidade (tú ou usted em espanhol, du ou Sie em alemão)
- Referências, exemplos e analogias locais
- Cumprimento regulamentar (RGPD, CCPA ou LGPD, conforme a região)
As cinco camadas da localização de um website
- Camada linguística: tradução do texto com as suas nuances culturais.
- Camada visual: imagens, cores e layout.
- Camada funcional: moedas, métodos de pagamento, formatos locais.
- Camada SEO: palavras-chave locais, hreflang, dados estruturados.
- Camada regulamentar: cumprimento das regras locais.
Erros comuns de hreflang no WordPress
Hreflang é a tag html que diz ao Google: “Esta página é a versão portuguesa daquela página inglesa.”
Links recíprocos em falta, conflitos canónicos e x-default
- Links recíprocos em falta: Criar um link de EN para PT, mas esquecer o link de PT de volta para EN. O Google ignora cadeias quebradas.
- Conflitos canónicos: Apontar o URL canónico da página portuguesa para a versão inglesa. Assim pede ao Google que indexe a página inglesa em vez da portuguesa. A auto-referência canónica deve apontar para o URL português.
- x-default: Esquecer de definir um fallback para utilizadores que falam um idioma que não suporta (ex: um utilizador do Japão a visitar o seu site).
Exemplo de tags hreflang com x-default
Cada página lista todas as versões linguísticas, incluindo ela própria:
<link rel="alternate" hreflang="es" href="https://example.com/es/pagina/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="pt" href="https://example.com/pt/pagina/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/strona/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />hreflang="pt" é português genérico, hreflang="pt-PT" é português para Portugal e hreflang="pt-BR" é português para o Brasil. O mesmo vale para es, es-MX e es-ES.
Regras de hreflang do Google Search Central
A página do Google sobre versões localizadas das suas páginas define as regras que a maioria das auditorias verifica:
- Há três formas equivalentes de indicar alternativas: elementos
<link rel="alternate">no head, um cabeçalho HTTPLink(útil para PDFs e outros ficheiros que não são HTML) ou entradasxhtml:linknum sitemap XML. Usar as três ao mesmo tempo não traz qualquer benefício. - Cada versão linguística tem de se listar a si própria e a todas as outras.
- Se duas páginas não apontarem uma para a outra, as tags são ignoradas.
- Os URLs alternativos têm de ser completos, com protocolo, ou seja
https://example.com/fooe não//example.com/foonem/foo. Não precisam de estar no mesmo domínio. - O código do idioma segue a ISO 639-1 e a região opcional segue a ISO 3166-1 Alpha 2. Uma região sozinha não é válida, e códigos reservados como
UKouEUnão têm efeito (o Reino Unido éGB). x-defaulté a alternativa para utilizadores cujo idioma não corresponde a nenhuma versão, e foi pensado para páginas de seleção de idioma.
O Google indica também que não usa o hreflang nem o atributo HTML lang para detetar o idioma de uma página. Lê o conteúdo visível. Um modelo português com o texto principal em inglês é, para o Google, uma página inglesa, digam as tags o que disserem.
Como o Polylang e o WPML geram o hreflang
No WordPress, quem trata do hreflang costuma ser o plugin multilingue, não o plugin de SEO. O artigo do próprio Polylang sobre atributos hreflang diz que acrescenta as tags automaticamente. Os códigos vêm do locale do WordPress e o sublinhado passa a hífen, por isso en_ZA passa a en-ZA. O Polylang gera x-default apenas para a página inicial. Nas outras páginas acrescenta-o com o filtro pll_rel_hreflang_attributes.
O guia do WPML sobre como adicionar hreflang no WordPress diz que o WPML insere as tags hreflang automaticamente e as atualiza quando o site muda. Um código regional como fr-ca vai para o campo hreflang na linha do idioma em WPML, Settings, Languages. O WPML não avisa sobre valores inválidos, por isso confirme-os nas listas ISO.
Em ambos os casos, as tags só ficam corretas se cada tradução estiver ligada ao original no plugin. Um artigo traduzido que foi criado como artigo independente não recebe hreflang nenhum.
Como validar o hreflang em CI/CD
Acrescente ao pipeline de implementação verificações automáticas que confirmem que:
- cada página tem um conjunto de hreflang completo e bidirecional
- cada URL referido devolve 200
- a tag x-default está presente
- os códigos de idioma e de região são válidos
Como automatizar a tradução do WordPress com um TMS
Já lá vão os dias de enviar documentos Word por e-mail para tradutores.
Ligar o WordPress ao Phrase, Lokalise ou Crowdin
O WordPress moderno liga-se diretamente a sistemas como Phrase, Lokalise ou Crowdin via API.
- Editor escreve em inglês no Gutenberg.
- Clique em “Pedir tradução”: O conteúdo é enviado via API para o TMS.
- IA + humano: O DeepL faz a primeira passagem (instantâneo). Um editor humano em Lisboa revê (1 hora).
- Importação automática: O texto português aprovado é enviado de volta para o WordPress como rascunho, notificando o editor.
Isto reduz o tempo de resposta de semanas para horas.
Uma memória de tradução guarda cada segmento aprovado. Quando uma frase semelhante aparece num artigo seguinte, a memória sugere a tradução anterior, e os revisores dedicam o tempo ao texto novo. Os revisores nativos olham para o que a tradução automática deixa escapar: nuances culturais, terminologia do setor, tom da marca e o registo certo.
Plugins de tradução para WordPress
- WPML: o plugin de tradução mais maduro, com ligação a serviços de tradução profissional.
- TranslatePress: tradução visual diretamente no frontend do site.
- Weglot: um SaaS que traduz automaticamente e permite revisão manual.
- DeepL API com plugin próprio: controlo total sobre o fluxo de tradução.
Tradução automática e as políticas de spam do Google
As políticas de spam do Google definem o abuso de conteúdo em escala como muitas páginas geradas sobretudo para manipular a classificação nos resultados e não para ajudar os utilizadores. Um dos exemplos indicados é conteúdo alheio transformado em muitas páginas através de transformações automáticas, incluindo a tradução, com pouco valor para quem lê. Uma tradução revista do seu próprio artigo é outro caso, mas publicar o resultado bruto da máquina em todos os idiomas e em grande escala aproxima-se dessa definição.
O guia sobre sites multirregionais acrescenta um segundo aviso: não traduza só o texto do modelo (menus, rodapé, botões) enquanto o conteúdo principal fica num só idioma. O Google chama a isto uma má experiência para o utilizador, porque o mesmo conteúdo aparece então nos resultados de pesquisa com idiomas de interface diferentes.
Deve redirecionar visitantes pela localização do IP
Visita um site. Ele deteta que está em França. Redireciona-o instantaneamente para /fr/. Não faça isto.
Porque o redirecionamento por IP prejudica o Googlebot e quem viaja
- Problemas de bots: O Googlebot rastreia geralmente a partir de um endereço IP dos EUA. Se redirecionar IPs dos EUA para inglês, o Googlebot pode nunca ver o seu conteúdo francês.
- Viajantes: Sou um utilizador britânico de férias em Paris. Quero ler em inglês, mas força-me para francês. Frustrante.
A página do Google sobre páginas adaptáveis à localização confirma o primeiro ponto: os endereços IP predefinidos do Googlebot parecem estar nos EUA e os pedidos não incluem o cabeçalho Accept-Language. O Google também rastreia a partir de alguns IPs fora dos EUA, por isso, se bloquear conteúdo por país, trate o Googlebot como qualquer visitante desse país e mantenha as meta tags robots e o robots.txt iguais em todas as versões. A recomendação do Google são URLs separados por versão, anotados com hreflang. O guia sobre sites multirregionais di-lo de forma mais curta: não use análise de IP para adaptar o conteúdo e evite redirecionamentos automáticos entre versões linguísticas.
A solução: Um banner “Global Gateway”. “Achamos que está em França. Continuar para o site ou mudar para a versão francesa?” Deixe o utilizador escolher.
O que fazem os redirecionamentos por navegador do WPML e do Polylang
O redirecionamento por idioma do navegador do WPML está desligado até o ativar. Tem dois modos: redirecionar só quando existe tradução, ou redirecionar sempre, usando a página inicial no idioma predefinido como recurso. Funciona em JavaScript no navegador, por isso a página carrega duas vezes na primeira visita, e dispara uma vez por sessão, reposta a cada 24 horas por predefinição. A própria documentação do WPML refere que o Google também segue redirecionamentos em JavaScript, o que pode levar o Google a tratar o seu conteúdo como redirecionado para outro idioma.
A deteção do idioma do navegador do Polylang é mais restrita. Envia o visitante que chega pela primeira vez para a página inicial num idioma que corresponda às preferências do navegador, apenas quando os idiomas são definidos por diretório ou subdomínio, e grava um cookie para que quem volta chegue à página inicial no último idioma consultado. As páginas de conteúdo não são redirecionadas.
Se mantiver uma destas opções ativa, limite-a à página inicial e teste com os cookies apagados.
Boas práticas para o seletor de idioma
- Um seletor visível no cabeçalho ou no rodapé, com os nomes dos idiomas na própria língua (Español, English, Português) em vez de bandeiras.
- Deteção do idioma do navegador que sugere a versão certa sem a impor.
- Uma escolha memorizada, guardada num cookie.
- URLs legíveis que mostram o idioma (/es/, /en/, /pt-pt/).
As bandeiras representam países, não idiomas. O espanhol fala-se em mais de 20 países e o português no Brasil e em Portugal. Um seletor escondido estraga a experiência multilingue mesmo quando tudo o resto está certo.
Como fazer SEO internacional para cada país
Traduzir o conteúdo não chega para posicionar em mercados locais. Cada mercado precisa do seu próprio trabalho de SEO e GEO.
Pesquisa local de palavras-chave
As traduções literais de palavras-chave raramente coincidem com o que os utilizadores locais escrevem. A pesquisa inglesa “WordPress developer” aparece em espanhol como “desarrollador WordPress” e como “programador WordPress”, e “website speed optimization” como “optimizar velocidad web” ou “acelerar página web”. A pesquisa de palavras-chave feita por nativos para cada mercado tem em conta:
- variantes dialetais (espanhol de Espanha, do México e da Argentina)
- termos técnicos locais face a anglicismos
- intenção de pesquisa que muda entre culturas
- concorrentes locais diferentes
Sinais que o Google usa para identificar o país-alvo
O guia sobre sites multirregionais lista os sinais que o Google usa para perceber a que país um site se dirige: o ccTLD, o hreflang em tags, cabeçalhos ou sitemaps, e a localização do servidor (não decisiva, porque as CDN a distorcem). Outros sinais são moradas e números de telefone locais nas páginas, o idioma e a moeda locais, links de sites locais e um Perfil da Empresa no Google. O Google ignora meta tags de localização como geo.position e outros atributos HTML de segmentação geográfica, por isso não acrescentam nada.
Link building local
Posicionar num mercado local exige links de sites locais: meios de comunicação nacionais, diretórios regionais de empresas, associações profissionais e blogs do setor no idioma local.
Que conteúdo traduzir e que conteúdo criar localmente
Nem tudo precisa de ser traduzido.
- Conteúdo global: Proposta de valor, características do produto, “Sobre nós”. (Traduzir para todas as regiões).
- Conteúdo local: Estudos de caso de clientes locais, eventos locais, páginas regulamentares. (Criar especificamente para esse mercado).
O conteúdo local de cada mercado pode incluir estudos de caso de empresas locais, regulamentação específica do país, eventos e conferências locais, integrações e ferramentas populares nesse mercado, e preços na moeda local.
Estratégia de fallback: Se um post de blog ainda não foi traduzido para alemão, deve mostrar um 404? Não. Mostre a versão em inglês com uma nota: “Este artigo ainda não está disponível em alemão.”
Que métricas medir num site multilingue
Configure dashboards separados para cada versão linguística e acompanhe:
- Tráfego orgânico por idioma e país
- Posições das palavras-chave em cada mercado
- Taxas de conversão por região
- Taxa de rejeição, que pode indicar problemas de qualidade da tradução
- Tempo na página, em que um envolvimento baixo pode sinalizar conteúdo pouco relevante localmente
- Velocidade de carregamento por região (CDN e alojamento regional)
Uma estratégia global de conteúdo não tem data de fim. Precisa de uma revisão mensal dos resultados por mercado, de atualizações baseadas em dados locais, de expansão gradual a novos mercados conforme a oportunidade e os recursos, e de melhoria contínua do fluxo de tradução.
Conclusão
Uma estratégia global de conteúdo não é sobre alcançar mais pessoas; é sobre ressoar profundamente com elas. Ao respeitar o seu idioma, cultura e preferências técnicas (velocidade, moeda), transforma-se de uma “empresa estrangeira” num parceiro local.
A construir uma arquitetura WordPress global? A WPPoland especializa-se em escala multimercado.
Veja os meus serviços de SEO e GEO.







