Montar bem um site multilingue

Q: Que estrutura de endereços é melhor para sites multilingues?

Subpastas como /en/ para quase todas as empresas: todas as versões linguísticas beneficiam da força do mesmo domínio e a gestão mantém-se simples. Os domínios de país próprios só compensam com presenças de mercado autónomas e equipa própria; os parâmetros de língua no endereço devem ser evitados.

O essencial

As subpastas (/en/) são a escolha certa para a maioria das empresas – mais simples do que domínios próprios, mais eficazes do que parâmetros.
O hreflang tem de ser recíproco: cada versão remete para todas as outras, para si própria e para uma versão predefinida.
Os endereços devem ser traduzidos também. Um texto em inglês sob um endereço em alemão é meia tradução.
O reencaminhamento automático pela língua do navegador é o erro grave mais frequente – exclui rastreadores e utilizadores.

A parte técnica de um site multilingue é simples quando se monta bem à primeira – e trabalhosa quando se corrige mais tarde. Por isso compensa a meia hora prévia.

A estrutura de endereços

Variante	Exemplo	Adequada a
Subpasta	`exemplo.pt/en/`	quase todos – um domínio, uma força
Subdomínio	`en.exemplo.pt`	sistemas ou operadores separados
Domínio de país próprio	`exemplo.de`	presenças de mercado autónomas com equipa própria
Parâmetro	`exemplo.pt/?lang=en`	nada – evitar

As subpastas ganham quase sempre, porque todas as versões linguísticas beneficiam da força do mesmo domínio. Os domínios de país próprios exigem que cada um seja construído isoladamente – isso só compensa com uma equipa por mercado.

Definir bem o hreflang

Quatro regras que têm de valer em conjunto. Se uma for violada, o grupo inteiro é muitas vezes ignorado.

Recíproco. Se a versão alemã remeter para a inglesa, a inglesa tem também de remeter para a alemã. As indicações unilaterais são descartadas.
Autorreferência. Cada página remete também para si própria. É frequentemente esquecido e não é opcional.
Indicar a versão predefinida. Um x-default para todas as línguas não cobertas.
Endereços absolutos. Completos, com protocolo e domínio, sem caminhos relativos.

Dica O código de língua é primeiro a língua, depois opcionalmente a região: pt para português em geral, pt-PT para português de Portugal. Quem tiver apenas uma versão em português usa pt – não pt-PT. Senão os visitantes brasileiros não recebem a versão atribuída.

Seis erros que tornam um site multilingue invisível

1. Reencaminhamento automático pela língua do navegador

O erro mais grave. Os rastreadores vêm normalmente com a configuração de língua americana e nunca chegam a ver as outras versões. Também os utilizadores deixam de chegar onde queriam ir.

Correto: mostrar um aviso com sugestão, mas não reencaminhar. Guardar a escolha.

2. Endereços não traduzidos

/en/impressum/ em vez de /en/legal-notice/. Parece uma versão por acabar – e desperdiça o termo de pesquisa no endereço.

Correto: traduzir os segmentos de endereço por língua, fixá-los de forma duradoura e não os voltar a mudar.

3. O canonical aponta para a língua principal

Se a página inglesa indicar como endereço canónico o alemão, estão a dizer: esta página é um duplicado, usa a outra. Ela desaparece do índice.

Correto: cada versão linguística é o seu próprio endereço canónico.

4. Falta o atributo lang

<html lang="pt"> falta ou está igual em todas as versões. Afeta não só os motores de busca, mas também os leitores de ecrã – aí leva a uma pronúncia incompreensível.

Correto: em cada versão o código adequado, definido automaticamente.

5. Um sitemap para tudo, sem indicações de língua

Sem indicações hreflang no sitemap, falta a ligação entre as versões precisamente no sítio em que seria mais fácil de reconhecer.

Correto: hreflang no sitemap ou no <head> – de forma consistente num só sítio.

6. Páginas traduzidas em parte

Títulos traduzidos, texto corrido em alemão. Para os motores de busca é uma página sem língua clara – e para os visitantes um problema de confiança.

Correto: antes menos páginas completas do que todas pela metade.

Sabia que…?

Traduzir por si só não chega – quatro coisas têm de ser adaptadas ao país, não apenas à língua: os valores na moeda local, a situação legal aplicável, os exemplos usuais no local e os formatos de data.

Uma versão inglesa que fala de francos suíços e da lei suíça revista de proteção de dados não é uma versão para o mercado britânico, é uma tradução da página suíça. Pode ser assim de propósito – mas deve ser uma decisão e não um descuido.

A manutenção é o verdadeiro problema

A construção é um esforço único. A manutenção é permanente – e é aí que os sites multilingues falham mais vezes do que na técnica.

Da prática

Ao fim de um ano, o quadro típico é este: a língua principal tem 40 páginas, a segunda 31, a terceira 22. As alterações foram feitas na língua principal e esquecidas nas outras – e já ninguém sabe qual é a versão atual.

Contra isso só ajuda uma decisão estrutural: uma alteração só conta como terminada quando estiver refletida em todas as línguas. Quem não conseguir aguentar isso deve oferecer menos línguas – três bem mantidas batem claramente oito desatualizadas.

Lista de verificação antes do arranque

Cada página remete por hreflang para todas as versões, para si própria e para x-default
Cada versão é o seu próprio endereço canónico
O <html lang> está corretamente definido em cada versão
Os segmentos de endereço estão traduzidos e fixados de forma duradoura
Não há reencaminhamento automático pela língua do navegador
A escolha de língua está visível e funciona sem JavaScript
Os valores, as indicações legais e os exemplos estão adaptados, não apenas traduzidos
Existe um processo fixo que reflete as alterações em todas as línguas

Prompt

Verifica a configuração multilingue do meu site.

Dados:
- Domínio: [endereço]
- Línguas: [lista com códigos de língua]
- Estrutura de endereços: [subpasta / subdomínio / domínio
  próprio]
- Bloco hreflang de uma página de exemplo:
  [colar bloco]
- Indicação canonical da mesma página: [colar]
- Atributo lang da mesma página: [colar]
- Existe reencaminhamento automático pela língua do navegador?
  [sim / não]
- Os segmentos de endereço estão traduzidos? [exemplo por língua]

Tarefas:
1. Verifica as quatro regras do hreflang: recíproco,
   autorreferência, x-default presente, endereços absolutos.
   Indica cada violação isoladamente.
2. Verifica se os códigos de língua estão bem escolhidos – em
   especial se alguma indicação de região está demasiado
   restrita.
3. Verifica o canonical e o atributo lang quanto a contradições
   com a versão linguística.
4. Indica os pontos dos meus dados que podem tornar uma versão
   linguística invisível, ordenados por gravidade.
5. Devolve-me o bloco hreflang corrigido por completo.

Não inventes endereços – marca o que falta como [a completar].

Conclusão

Tecnicamente, um site multilingue decide-se em quatro pontos: estrutura de endereços, hreflang recíproco, endereço canónico próprio por versão, sem reencaminhamento automático. Se estes quatro estiverem certos, o resto funciona.

A verdadeira questão a seguir é organizativa: conseguem refletir cada alteração em todas as línguas? Se não, menos línguas é a melhor decisão.

Perguntas frequentes

Que estrutura de endereços é melhor para sites multilingues?

Subpastas como /en/ para quase todas as empresas: todas as versões linguísticas beneficiam da força do mesmo domínio e a gestão mantém-se simples. Os domínios de país próprios só compensam com presenças de mercado autónomas e equipa própria; os parâmetros de língua no endereço devem ser evitados.

O que é preciso ter em conta no hreflang?

Quatro regras em simultâneo: as indicações têm de ser recíprocas, cada página tem de remeter também para si própria, é preciso um x-default para as línguas não cobertas, e todos os endereços têm de ser absolutos. Se uma regra for violada, todo o grupo é muitas vezes ignorado.

Deve reencaminhar-se automaticamente os visitantes para a sua língua?

Não. Os rastreadores vêm normalmente com a configuração de língua americana e nunca veem as outras versões; os utilizadores não chegam onde queriam ir. O correto é um aviso com sugestão que guarde a escolha feita – sem reencaminhamento automático.

Os endereços têm de ser traduzidos?

Sim. Um texto em inglês sob um endereço em alemão parece inacabado e desperdiça o termo de pesquisa no endereço. Os segmentos de endereço devem ser traduzidos por língua e depois fixados de forma duradoura – as alterações posteriores custam a visibilidade já construída.

Quantas línguas fazem sentido?

Tantas quantas se consiga manter de forma duradoura. O estado mais frequente ao fim de um ano são versões de completude diferente em que já ninguém sabe qual está atual. Três línguas bem mantidas atuam claramente melhor do que oito desatualizadas – decisivo é um processo fixo que reflita cada alteração em todas as versões.

Marketing que se configura sozinho

A beta do Studio Engine está aberta. Reserve o seu lugar e participe desde o início.

Participar na beta →

← Voltar à lista