A anotação de língua alternativa indica aos motores que uma mesma página existe em várias versões linguísticas e qual servir a quem. É simples no princípio e temivelmente fácil de partir: um erro num só elemento invalida muitas vezes o grupo inteiro.
Aqui ficam dez erros, verificáveis em cerca de vinte minutos no seu site.
1. A ligação de retorno em falta
O erro mais frequente e o mais destrutivo.
A declaração tem de ser recíproca. Se a sua página portuguesa declara uma versão alemã, a página alemã tem de declarar a portuguesa em retorno. Sem essa reciprocidade, a declaração é ignorada.
O caso típico: uma tradução acrescentada sem que o modelo de página tenha sido regenerado, ou uma página despublicada apenas de um lado.
Verificação: abra uma página alemã, olhe para as anotações dela e confirme que aponta para a portuguesa.
2. A autorreferência ausente
Cada página tem de se declarar a si própria na lista, além das alternativas.
Uma página portuguesa que declara o alemão, o espanhol e o italiano mas não o português está incompleta. A autorreferência faz parte do grupo.
Verificação: conte as anotações numa página. Se tem cinco línguas, tem de ver cinco, não quatro.
3. A confusão com a etiqueta canónica
Erro mais lesivo para o tráfego internacional.
As versões linguísticas não são duplicados. Cada página tem de ter uma canónica para si própria, não para a versão de origem.
Apontar as traduções para a página de origem equivale a pedir a desindexação delas. O site parece corretamente traduzido e não recebe tráfego estrangeiro nenhum.
Verificação: numa página alemã, a canónica tem de ser o endereço alemão.
4. Os códigos de língua e de região misturados
O código pode designar uma língua sozinha, ou uma língua num país. Os dois são válidos e não querem dizer a mesma coisa.
Um código de língua sozinho visa todos os falantes dessa língua. Um código de língua e região visa essa língua nesse país preciso.
É um ponto especialmente sensível em português: se tem conteúdos distintos para Portugal e para o Brasil, use pt-PT e pt-BR. Se tem um único conteúdo em português europeu, pt sozinho chega e evita declarar uma versão que não existe.
Três erros clássicos: usar um código de país sozinho, que não é válido; inventar um código de região inexistente; ou misturar as duas formas de maneira incoerente dentro do mesmo grupo.
Ponto importante: o primeiro elemento é sempre a língua, o segundo a região. O inverso é inválido.
Verificação: reúna todos os seus códigos e compare-os com as normas correspondentes.
5. A segmentação por país sem conteúdo diferenciado
Erro de conceção e não de sintaxe.
Declarar uma versão para Portugal e outra para o Brasil só faz sentido se os conteúdos diferirem realmente: preços, moeda, condições de entrega, menções legais.
Se as duas páginas forem idênticas, cria duplicação sem benefício, e os motores escolhem eles próprios qual servir.
Verificação: para cada par de versões da mesma língua, identifique pelo menos uma diferença substancial. Caso contrário, funda-as.
Módulo Hreflang PrestaShop 8: Tags Alternate para SEO MultilingueTags hreflang corretas em todas as páginas do seu PrestaShop 8: URL nativos traduzidos, x-default, grupos multiloja e mais de 70 códigos hreflang.29,00€
6. As anotações em páginas não traduzidas
Situação frequente em catálogos parcialmente traduzidos.
Declarar uma versão alemã de uma ficha de produto cuja descrição ficou em português produz dois problemas: o visitante alemão chega a conteúdo que não percebe, e o motor constata que a página anunciada como alemã não o é.
A regra: declare apenas as versões realmente traduzidas. Um grupo com três línguas num produto e cinco noutro é perfeitamente válido.
Verificação: escolha três produtos ao acaso e leia as versões estrangeiras. Se encontrar português lá dentro, corrija.
7. O valor genérico mal usado
Um valor particular permite designar uma versão por omissão, servida aos visitantes cuja língua não corresponde a nenhuma versão declarada.
Dois erros. Tratá-lo como uma língua, julgando que visa o inglês: não visa língua nenhuma em particular. E esquecê-lo: sem ele, um visitante japonês num site com cinco línguas europeias não tem versão designada.
Este valor é facultativo. Se o usar, tem de designar uma única página, e essa página tem de existir no grupo como as outras.
8. Os endereços relativos ou incoerentes
Quatro problemas de endereço que invalidam as declarações.
Os endereços relativos. Têm de ser absolutos, com protocolo e domínio.
A mistura de protocolos, uma versão declarada em seguro e outra não.
Os endereços redirecionados. Uma declaração que aponta para um endereço que redireciona acrescenta uma etapa e baralha o sinal.
A incoerência com a canónica. Se a declaração aponta para um endereço e a canónica da página de destino aponta para outro, o grupo fica partido.
Verificação: um controlo automatizado numa amostra de páginas deteta estes quatro casos em poucos minutos.
9. As páginas em erro ou não indexáveis
Uma declaração que aponta para uma página que já não existe, que redireciona ou que tem uma diretiva de não indexação é inutilizável.
O caso acontece tipicamente depois de uma reformulação ou da eliminação de um produto numa só língua.
Consequência prática: quando retira uma página numa língua, tem de atualizar as anotações de todas as outras versões do grupo. É o que mais se esquece.
Verificação: um crawl do site com registo dos códigos de resposta nos endereços declarados.
10. O mapa do site e os cabeçalhos esquecidos
As anotações podem ser colocadas de três formas: no cabeçalho da página, nos cabeçalhos de resposta, ou no mapa do site.
Dois erros opostos.
Declará-las em vários sítios com valores diferentes, o que produz um conflito.
Não as declarar de todo nos documentos que não são HTML, como os PDF, para os quais só a via dos cabeçalhos de resposta é possível.
Num catálogo grande, a declaração no mapa do site tem uma vantagem: centraliza a informação e aligeira as páginas. Em contrapartida exige um mapa do site corretamente gerado e atualizado.
O método de verificação em vinte minutos
Cinco etapas.
1. Abra uma página em cada língua e compare as anotações. Têm de listar exatamente os mesmos endereços.
2. Verifique a canónica de cada uma: tem de apontar para si própria.
3. Reúna os códigos usados e valide o formato deles.
4. Leia o conteúdo de duas ou três páginas estrangeiras para confirmar que estão mesmo traduzidas.
5. Consulte o relatório internacional da Search Console, que reporta as ligações de retorno em falta e os códigos inválidos à escala do site.
Este último ponto é o mais eficaz para o acompanhamento contínuo: deteta as regressões depois de uma colocação em produção sem que tenha de repetir os controlos manualmente.
O que estas anotações não fazem
Três esclarecimentos úteis.
Não alteram o posicionamento. Indicam que versão servir, não qual posicionar melhor.
Não substituem a tradução. Uma página mal traduzida continua a ser uma má página, corretamente anotada.
Não redirecionam ninguém. Um visitante que chega à versão errada tem de poder mudar, o que pressupõe um seletor de língua visível.
Neste último ponto, uma prática a evitar: o redirecionamento automático conforme a língua do navegador. Impede um visitante de consultar outra versão e atrapalha a exploração dos motores. Propor, não forçar.
O módulo Hreflang para PrestaShop gere estas anotações no PrestaShop 8 e 9: geração automática com reciprocidade e autorreferência, exclusão do grupo das páginas não traduzidas, coerência com as canónicas autorreferentes e controlo dos endereços declarados em erro ou redirecionados.
