Sites multilingues: CMS, URL e fluxo de trabalho
Um site multilingue não é um site multiplicado pelo número de idiomas. É um modelo de conteúdo com relações de tradução, um padrão de URL que nunca mais vai querer mudar, e um fluxo de trabalho que determina se as traduções se mantêm atuais ou envelhecem em menos de um ano.
Este guia cobre as decisões por ordem de quanto custa revertê-las.
Escolha primeiro o padrão de URL#
É a decisão mais cara de mudar, porque se liga a hreflang, canónicos e a todos os redirecionamentos que alguma vez vai escrever.
| Padrão | Exemplo | Compromisso |
|---|---|---|
| Subpasta | site.pt/en/servicos | O mais simples; um domínio acumula toda a autoridade |
| Subdomínio | en.site.com/servicos | Separação mais limpa; mais configuração, sinais divididos |
| Domínio por país | site.es/servicios | Sinal local mais forte; um site separado para gerir |
| Parâmetro | site.com/servicos?lang=en | Evitar — sinais fracos e risco de duplicação |
Para a maioria dos projetos, subpastas são a escolha certa. Domínios por país só compensam quando constrói mesmo presença local, com equipa por mercado.
O idioma, e as partes que se traduzem#
Uma versão de idioma é mais do que o texto. Estas partes são as mais esquecidas e são visíveis para os visitantes.
- Nomes de URL: traduzidos para relevância local, ou iguais para manutenção mais simples. Ambos defensáveis; escolha de propósito.
- Metadados: títulos e descrições por idioma, não derivados automaticamente do original.
- Datas, números e moeda no formato local.
- Formulários: etiquetas, mensagens de erro, confirmações, e os e-mails que se seguem.
- Imagens com texto embutido — intraduzíveis sem ficheiros separados.
- Páginas legais: política de privacidade e termos têm diferenças reais por jurisdição.
- Pesquisa e páginas de erro, que ficam quase sempre esquecidas no idioma original.
- Direção de escrita nos idiomas da direita para a esquerda — isso é layout, não só texto.
Configurar hreflang corretamente#
O hreflang diz aos motores qual versão corresponde a que idioma. É mecânico e falha de formas mecânicas.
- Cada página declara todas as versões de idioma de si própria, incluindo ela mesma.
- As referências têm de ser recíprocas. Se faltar a de retorno, o grupo inteiro é anulado.
- Use códigos corretos: pt, en, pt-br. Um código inventado é ignorado.
- Use o mesmo código no HTML e no mapa do site; dois códigos diferentes partem o grupo.
- Acrescente x-default para visitantes que não caem em nenhum idioma.
- Gere tudo a partir de uma só fonte para que HTML e mapa do site não divirjam.
- Se uma página não existir num idioma, não declare esse idioma — não aponte para um substituto.
A última regra é importante em tradução faseada: um site parcialmente traduzido está perfeitamente bem desde que o hreflang só declare o que existe.
Fluxo de trabalho: onde encalha na prática#
A configuração técnica é a parte fácil. Manter as traduções atuais é onde os projetos multilingues param.
| Problema | O que acontece | Abordagem |
|---|---|---|
| Original muda, tradução não | Os idiomas divergem em silêncio | Marcar traduções como desatualizadas ao alterar o original |
| Sem dono por idioma | As traduções envelhecem sem ninguém notar | Nomear um responsável por idioma |
| Traduzir tudo | O custo escala com páginas, não com valor | Traduzir só o que aquele mercado precisa |
| Tradução automática sem revisão | Erros que prejudicam a marca e posicionam mal | Automática como primeira versão, sempre revista |
| Tradutores sem contexto | Textos literais mas errados | Enviar capturas de ecrã e notas |
| Sem rascunhos por idioma | Meias traduções publicadas | Estado de publicação separado por idioma |
Decida antecipadamente que idiomas ficam completos e quais recebem apenas um núcleo. Um site com cinco idiomas bons desempenha melhor do que um com quinze desatualizados.
Perguntas frequentes
Devo usar subpastas ou domínios separados?
Subpastas para a maioria dos projetos: um domínio acumula toda a autoridade, a configuração é mais simples e há um só site para manter. Domínios por país compensam quando constrói mesmo presença local com equipa por mercado — aí compra um sinal local forte e paga com carga de gestão.
A tradução automática é aceitável?
Como primeira versão revista por uma pessoa, sim — é hoje uma prática normal e poupa bastante. Publicada sem revisão é arriscada: erros em termos técnicos prejudicam a credibilidade junto precisamente dos leitores que quer alcançar, e os textos posicionam mal porque não correspondem à forma como as pessoas realmente procuram.
Tenho de traduzir todas as páginas para todos os idiomas?
Não, e tentar fazê-lo é como os projetos multilingues encalham. Traduza o que aquele mercado precisa: as páginas centrais, os serviços que oferece lá, e o conteúdo que é procurado naquele idioma. Desde que o hreflang só declare o que existe, um site parcialmente traduzido está tecnicamente correto.
O que corre mal com mais frequência em sites multilingues?
Duas coisas. Tecnicamente: hreflang não recíproco, o que anula o grupo de idiomas inteiro. Organizacionalmente: não haver dono por idioma, pelo que o original avança e as traduções ficam paradas. A segunda é a mais fatal, porque não é uma avaria que alguém reporte — a degradação é gradual.
site multilinguehreflangtradução cmsseo multilinguesite internacionalversões de idioma
