SEO

Erros vitais do site multilíngue e Hreflang feitos pela maioria dos webmasters

Google+ Pinterest LinkedIn Tumblr

A Internet dá às empresas o poder de competir globalmente. Longe vão os dias em que seu único concorrente era a outra loja do outro lado da estrada. Se você vende seus produtos ou serviços em um site, tem o poder de expandir-se rapidamente além das fronteiras do seu país, sem gastar milhões de dólares para abrir novas lojas físicas.

Mas para fazer isso, você deve falar a língua materna ou a língua preferida. E, para falar o idioma deles, você precisa traduzir seu site. Aparentemente, a criação de um site multilíngue é uma das coisas mais delicadas do marketing digital. Referências internacionais são bastante difíceis! Além da tradução correta, você pode encontrar muitos outros problemas técnicos, a maioria deles relacionados à indexação e exibição incorretas das versões de idiomas do Google.

Erros vitais em sites multilíngues

Além disso, o Google mudou recentemente a maneira como publica sites internacionalmente. Você não pode ver os resultados em outro país simplesmente visitando sua versão do Google. Em vez disso, você deve percorrer os parâmetros de pesquisa e selecionar o país e o idioma específicos. Isso mostra o interesse do Google em tornar os resultados de pesquisa mais relevantes por local. Portanto, é mais importante do que nunca fazer tudo!

Neste pequeno guia internacional de SEO, tentaremos resolver alguns dos problemas mais complexos relacionados a sites multilíngues e, esperançosamente, lançar alguma luz sobre os erros mais comuns do hreflang e outros problemas gerais relacionados a sites multilíngues. que os webmasters colocam quando começam a crescer internacionalmente.

  1. Questões técnicas relacionadas a SEO e Hreflang multilíngue
    1. Implementação incorreta dos atributos rel = "alternative" e hreflang
    2. Conflitos, aplicação incorreta e confusão sobre a tag rel = "canonical"
    3. Problemas geográficos e de redirecionamento de IP
    4. Usando tags Robots.Txt ou No-Index nas páginas traduzidas
    5. URL do seletor de idioma
    6. URL em inglês para outros idiomas
    7. Pense também em outros mecanismos de pesquisa
    8. Concentre todos os links apenas na versão principal
  2. Problemas multilíngues de exibição e conteúdo que afetam o UX
    1. Usando o software de tradução automática do site
    2. Não pesquise por palavra-chave
    3. Não tem consciência cultural
    4. Não converter completamente captchas
    5. Tente classificar uma página em inglês em qualquer lugar usando o HREFlang
    6. Fontes e diacríticos
    7. Negligenciar a mídia social

Questões técnicas relacionadas a SEO e Hreflang multilíngue

Problemas técnicos em sites multilíngues são mais comuns em versões personalizadas. Talvez nem sempre seja culpa do webmaster, mas desde que você tenha as informações e deixe os problemas no lugar, você não tem desculpa. Aqui estão alguns dos problemas técnicos mais comuns encontrados na Web e como resolvê-los corretamente.

Implementação incorreta dos atributos rel = "alternative" e hreflang

Oh, droga! Estudos mostram que cerca de 75% das implementações do hreflang têm erros. Para ser sincero, enquanto procurava exemplos on-line, muitos sites multilíngues nem sequer implementaram o hreflang!

Essa é uma preocupação, pois não apenas impede que você seja um dos melhores em outros países, mas também dilui o conteúdo do seu site, tornando-o menos relevante para o Google.

Então, qual é esse atributo hreflang? Bem, em teoria, é bem simples:

O atributo hreflang é uma maneira de dizer ao Google "Ei, eu tenho outra versão localizada do meu site. aquie está em esta o idioma ".

Aqui está um vídeo do SEJ, onde Bill Hunt explica exatamente o que é o HREFlang e como usá-lo corretamente.

Obviamente, se você não o usar, o Google provavelmente poderá consertar tudo sozinho. Porém, sabe-se que os sites multilíngues que ajudam o Google a entender as coisas com mais facilidade são impulsionados pelas classificações! Aqui está um bom exemplo de SeerInteractive que mostra o crescimento do tráfego depois que o atributo hreflang foi implementado corretamente:

Gráfico interativo Seer mostrando o crescimento do tráfego após a implementação correta do HrefLang

Gráfico interativo Seer mostrando o crescimento do tráfego após a implementação correta do HrefLang

Aqui estão os erros mais comuns cometidos pelos usuários ao implementar o atributo hreflang:

Nenhum atributo hreflang: Obviamente, a primeira regra seria ter a anotação hreflang no seu código HTML. Como eu disse, encontrei muitos exemplos que não contêm o atributo. Aqui está um:

nenhum atributo hreflang em html

Hreflang em falta no fbcareers.com

Embora você possa ver claramente que eles oferecem o site em vários idiomas, o atributo hreflang não aparece em nenhum lugar do código-fonte HTML:

nenhum atributo hreflang

Saia, saia, onde quer que esteja! Oi? Sr. Hreflang? Esta aqui …

Nenhum URL de referência própria: Na página oficial do Google dedicada a sites multilíngues, é claramente indicado que você deve usar um atributo de auto-referência rel = "substitute" -hreflang.

Se você tiver várias versões de idioma de um URL, cada página de idioma deverá identificar versões de idiomas diferentes, incluindo a própria. Por exemplo, se seu site fornece conteúdo em francês, inglês e espanhol, a versão em espanhol deve incluir um rel = "alternativo" hreflang = "x" link para si mesmo além de links para as versões em francês e inglês. Da mesma forma, as versões em inglês e francês devem incluir as mesmas referências às versões em francês, inglês e espanhol.
Logotipo do Google Google
https://support.google.com/webmasters/answer/189077?hl=fr

Aqui está um exemplo de site que não possui a tag hreflang de referência automática.

hreflang de auto-referência ausente

O site elcorteingles.es não possui o atributo hreflang em espanhol que se refere a si mesmo.

Em outro exemplo, você pode ver no título que o texto está em inglês e que o atributo inglês hreflang está ausente na página. No entanto, a página indica claramente a versão em espanhol do site.

nenhum atributo hreflang de referência própria

Atributo hreflang em inglês ausente na referência própria em cricketwireless.com

O que é ainda pior neste caso é que a tag de link que contém a versão em espanhol é estática e implementada no modelo principal do site como um todo. Isso significa que cada página terá o mesmo atributo hreflang, enganando continuamente o Google e afetando o site.

mesmo hreflang em todos os lugares

Versão em espanhol do site com hreflang autorreferido, mas hreflang ausente em inglês

Como você pode ver acima, desta vez, temos o atributo de auto-referência configurado, mas agora perdemos o atributo que especifica a versão em inglês que vimos anteriormente.

Nesse caso, a implementação correta incluiria as duas versões, assim:

Para provar que uma implementação ruim não o levará aonde você quer estar, escolhi EUA como região do Chrome, espanhol como idioma e, em seguida, procurei a palavra "cricketwireless".

exibição ruim do google

Google exibe a versão em inglês da pesquisa em espanhol

Como você pode ver, o resultado não é o subdomínio espanhol desejado. Embora o webmaster tenha especificado a versão em espanhol, ele perdeu as outras regras. Também fiz essa pesquisa na região espanhola e os resultados de pesquisa do Google foram os mesmos.

Portanto, se você deseja que seu site tenha uma boa classificação em todas as regiões e idiomas, verifique se as tags de referência hreflang estão configuradas para que o Google possa determinar quais páginas da web estão vinculadas entre si.

Não está no cabeçalho: Se as tags de retorno do atributo hreflang não aparecerem no cabeçalho, o Google realmente digitalizará a página inteira para tentar descobrir por si mesmo antes de perceber que a resposta estava bem debaixo do nariz dele. Certifique-se de tê-lo entre as etiquetas de abertura e fechamento.

Um atributo hreflang que especifica a versão francesa de um site deve ter a seguinte aparência:

Parece tags de link que inserem arquivos JavaScript ou CSS. Você também pode usar um sitemap ou cabeçalho HTTP para arquivos não HTML. No entanto, a tag do link no seção do seu site é a versão recomendada.

Aqui está uma implementação realmente estranha, onde as tags estão fora da seção principal e dentro de um

  • tag em vez de um a. Estranho e interessante, mas certamente não é o caminho certo para fazê-lo.

        má implementação do hreflang fora do cabeçalho

    Implementação linguística estranha em semver.org

    Não faça isso! Use a tag de link como mencionado acima!

    URLs relacionados: O Google pode interpretar mal os URLs relativos. Portanto, certifique-se de torná-los absolutos (https://yoursite.com/specific-page em vez de apenas / página específica /). Se a página for um URL 404 ou relativo, pode ser que a indexação global da sua versão do idioma seja problemática.

    Não encontrei outro exemplo, mas você pode dar uma olhada no exemplo acima no semver.org, onde os URLs hreflang mal implementados são relativos (/ lang / ar) em vez de absolutos.

    A implementação correta neste caso seria .

    Não aponta para uma página específica: Cada página deve apontar para a contraparte específica em outro idioma e não para a versão completa em idioma estrangeiro. Não encontrei outro exemplo, mas podemos usar um precedente. Como existe apenas um atributo hreflang em todo o site, páginas diferentes apontam para a raiz da versão desse idioma, independentemente da página ou versão do idioma em que você está.

    atributo específico hreflang da URL

    O atributo hreflang da página específica aponta para a raiz da versão do idioma

    Se você implementar uma tag de link não dinâmico no modelo de cabeçalho do site, todas as páginas terão o mesmo HREFlang. É uma péssima ideia!

    Em alguns casos, como este, é melhor não possuir o atributo hreflang do que implementá-lo incorretamente.

    A implementação correta nesse caso seria https://www.cricketwireless.com/support/apps-and-services.html com um atributo rel = "substitute" em https://espanol.cricketwireless.com/ayuda/27g / aplicaciones-y-servicios.html.

    Além disso, lembre-se de que ele deve ter um atributo hreflang de referência própria.

    Códigos de idioma / país incorretos: Muitas vezes, o código do idioma está incorreto. Geralmente, os webmasters e desenvolvedores da web usam o código do país em vez do código do idioma. Aqui estão algumas informações oficiais do Google:

    códigos de idioma hreflang corretos

    Declaração oficial do Google sobre códigos de país no atributo hreflang

    Portanto, normalmente, você deve inserir o código do idioma, não o código do país. O código do país é opcional e pode ser adicionado para segmentar idiomas específicos em regiões específicas. Por exemplo, você pode segmentar o público que fala espanhol nos Estados Unidos ou que fala inglês na França. Isso é útil?

    Não sei … digo que os britânicos visitam a Itália e querem comprar lembranças. Eles não sabem italiano e, portanto, digitam "comprar lembranças em Veneza" no Google. É isso: você só tem um público-alvo que fala inglês em uma região italiana.

    A lista completa de códigos de idioma pode ser encontrada aqui, e a lista opcional completa de códigos de países pode ser encontrada aqui.

    Nenhum atributo x-default para a página de seleção de idioma: O Google recomenda o uso de uma tag adicional, colocada após todos os outros idiomas, para especificar a página de seleção de idioma, se houver. Por exemplo, se a página inicial mostrar apenas uma lista de idiomas para escolher, será a versão do idioma x-padrão.

    No caso a seguir, você pode ver que a página inicial do nunnauuni.com é uma página de seleção de idioma. A página está bem configurada e redireciona os usuários na segunda visita de acordo. Embora o site possua todos os outros atributos de idioma, incluindo o atributo de referência automática, está faltando a tag x-default que especifica a página de seleção geral de idioma.

    nenhum atributo x-default hreflang para a página de escolha de idioma

    Tag x-default ausente em nunnauuni.com

    Ele também perde todas as outras tags na página inicial. Em vez disso, deve incluí-los e também ter uma tag x-default auto-referente. O código correto a ser adicionado após a lista de idiomas nesse caso é .

    Se você usar 301 para geolocalizar usuários por IP, poderá especificar a versão padrão no cabeçalho HTTP. Para fazer isso no WordPress, você precisará usar um plug-in HTTP Headers. O código, no entanto, é um pouco diferente: Link: http://www.example.es; rel = "alternativa"; hreflang = "es-ES".

    As páginas não traduzidas são exibidas na página inicial: Esse é um grande problema, especialmente se sua página inicial é uma página importante para o seu site. Isso geralmente acontece devido à maneira como as metatags do hreflang foram implementadas, geralmente como resultado de um plug-in.

    A maioria dos plugins parece ter esse problema. Se uma página ou postagem de blog não for traduzida, o plug-in realmente não saberá o que adicionar ao atributo de link hreflang; portanto, apenas adicionará a página inicial ou um " / "Que pode ser interpretado como um URL relativo para a página inicial.

    Polylang, o plug-in de tradução de minha escolha para sites multilíngues no WordPress não parece ter esse problema. Você pode configurá-lo para não exibir o atributo hreflang errado quando a página não estiver traduzida. Você também deve remover links internos que alteram o idioma do menu se não houver uma versão traduzida disponível.

    Conflitos, aplicação incorreta e confusão sobre a tag rel = "canonical"

    As pessoas ainda não entendem o que o farol canônico faz. Eles têm uma vaga idéia sobre isso, mas costumam usá-la da maneira errada. Em poucas palavras, eis o que a tag canônica faz:

    A tag rel = "canonical" informa aos mecanismos de pesquisa qual página exibir nas páginas de resultados.

    Para entender melhor a tag, imagine assim: se você tiver 10 páginas da web sobre o mesmo assunto, elas começarão a competir nos mecanismos de busca. Isso confunde o Google, então você pode usar a tag canônica para ajudar a entender a situação e apontar para a página exata que você prefere que apareça nos mecanismos de pesquisa.

    A etiqueta canônica deve sempre ser uma referência automática, o que significa que a página A deve apontar para si mesma, exceto quando você deseja exibir algo diferente da página A do SERPS. Ter uma tag canônica autorreferenciada ajudará a eliminar o risco de problemas de conteúdo duplicado gerados por parâmetros dinâmicos, como filtros? Replytocomm ou comércio eletrônico.

    O farol canônico funciona! Vou compartilhar uma história. Há algum tempo, publiquei um artigo no meu blog pessoal, que foi distribuído por outra editora. Não consegui indexá-lo no meu blog e, como o outro editor era mais popular, o Google indexou seu artigo primeiro. Assim, em poucas semanas, eles se classificaram bem no top 5 do meu artigo. Entrei em contato com eles, pedi educadamente que adicionassem a tag canônica e, cerca de uma semana depois, o Google a pegou e começou a postar minha página.

    Não tente fazer com que o Google exiba apenas uma página de destino ou uma página estranha que realmente não atenda à intenção do usuário. Não vai funcionar e você pode ser penalizado.

    Para retornar a sites multilíngues, a etiqueta canônica deve se referir à página em que é exibida, a menos que especificado de outra forma. Um erro comum é:

    A maneira errada de fazer isso é: www.yourwebsite.com/defile-mode/ com um URL canônico para seu equivalente em inglês, www.youtwebsite.com/fashion-show/.

    Se você combinar isso com um atributo HREFlang, mexer no Google para alternar de EN para FR para FR para EN.

    Uma boa implementação seria: www.votrewebsite.fr/defile-mode/ com uma tag canônica apontando para www.votrewebsite.fr/defile-mode/ (em si) ou, se desejar, www.votrewebsite.fr/some -other -french-page /.

    Nunca use o parâmetro hreflang rel = "alternative" para resolver problemas de conteúdo duplicado, pois esse não é seu objetivo. Somente solicitará ao Google que mostre esta versão da página para um local e idioma diferentes em um navegador.

    Problemas geográficos e de redirecionamento de IP

    Eu estava discutindo isso recentemente com alguém em uma reunião. Um de seus clientes insistiu que a home page em inglês de seu site fosse exibida em francês por padrão, em vez de em inglês. O motivo? Com o navegador em francês, a página principal em inglês foi automaticamente redirecionada por um plugin do WordPress.

    Agora, Matt Cutts disse em seu vídeo de camuflagem que o redirecionamento geográfico não era uma preocupação. Ele também disse que usuários vindos da França ou de um país de língua francesa ficariam felizes em poder postar seu conteúdo diretamente em francês.

    No entanto, lembre-se de que, embora você possa enviar usuários da França para a versão francesa, não é possível garantir que todos na França usem um endereço IP francês ou tenham seu navegador em francês.

    Muitas pessoas usam o navegador em inglês, por exemplo. Isso significa que eles serão constantemente redirecionados, não importa o que façam. Além disso, com as VPNs cada vez mais populares, o IP também não é uma medida infalível.

    Definir-se como redirecionamento geográfico não ajuda a se classificar melhor em outros idiomas. Na minha opinião, a melhor maneira de direcionar o usuário para a versão correta é usar o atributo HREFlang para exibir corretamente a página desejada em seu mecanismo de pesquisa. Obviamente, se eles usarem um endereço IP diferente com VPNs, o mecanismo de pesquisa sempre exibirá a versão errada, pensando que o usuário mora em outro lugar, mas qualquer usuário que use uma VPN deve estar ciente disso.

    redirecionamento geográfico em vez de hreflang

    Inglês e francês

    Se alguém quiser acessar diretamente o site da sua empresa, ele o acessará pelo URL do país apropriado ou pela página inicial. Se você possui um seletor de idioma claramente visível, considero que atualmente qualquer usuário é inteligente o suficiente para obter a versão correta.

    Se o seu site já fornecer redirecionamento automático e você optar por mantê-lo, defina também o atributo xre-hreflang. Isso informará ao Google onde está a página de seleção de idioma e a exibirá sempre que você não souber o local ou o idioma de escolha real do usuário.

    Verifique se os indicadores de seleção de idioma estão claramente visíveis na área de trabalho e no celular.

    Usando tags Robots.Txt ou No-Index nas páginas traduzidas

    Outro problema comum ao traduzir páginas é esquecer a tag sem índice ou deixá-la de propósito. Entendo esquecê-lo porque você não deseja que o Google indexe sua versão do site em outro idioma antes do final.

    Mas se você deixar de propósito, realmente não faz sentido. Eu li rumores de que as pessoas temem penalidades duplas por conteúdo. Embora não haja penalidade de conteúdo duplicado, eu entendo o problema.

    Você pode pensar "Como alguém poderia pensar que as versões em francês e inglês são duplicadas?" No começo eu pensei, mas depois percebi que teve que agir a partir do mesmo idioma exibido em lugares diferentes. Por exemplo, in-us e in-gb.

    Embora você possa simplesmente usar o seletor de idioma para exibir a mesma versão nas duas regiões, pode ser útil ter versões separadas.

    Dessa forma, você pode ter diferentes controles deslizantes, produtos ou ofertas em diferentes regiões. Por exemplo, se você vende camisetas com mensagens, alguns textos podem corresponder aos Estados Unidos e apenas alguns ao Reino Unido.

    Se você possui várias versões em inglês, usar a tag no-index é uma má idéia se todas as anotações do HREFlang estiverem configuradas corretamente. Se você se refere a uma versão do HREFlang e depois usa o no-index, basicamente diz ao Google "Ei, olhe aqui!", Então "Ha ha, estou brincando, não há nada para rastrear aqui, não é? no! "

    Não mexa com o Google!

    URL do seletor de idioma

    Um erro comum que ocorre é ter uma implementação estática do botão ou sinalizador de mudança de idioma. Os usuários esperam ver o que estão procurando. Se você se encontrar em uma subpágina do site, a mudança de idioma não deve levar o usuário à página inicial desse idioma. Pelo menos não o tempo todo. Isso deve trazê-los, de preferência, para esta página específica, no idioma desejado.

    O problema aqui é que nem sempre é fácil de fazer. Você pode ter, por exemplo, 10 páginas em inglês, mas apenas 8 são traduzidas para o francês. O que você está fazendo com os outros dois? Bem, você tem três opções:

    • A primeira opção é enviar o usuário para a página francesa mais relevante sobre o assunto.
    • A segunda opção é enviá-los para a página inicial
    • A terceira opção é especificar para o usuário que não há versão traduzida para esta página específica.

    A opção três é a pior da minha opinião, porque os usuários provavelmente sairão do site assim que receberem a mensagem. Ele basicamente diz: "Este site não contém o que você está procurando".

    A opção de página inicial não é um grande problema em um site pequeno, onde você só possui Quem Somos, Serviços e Entre em Contato. As pessoas encontrarão facilmente em que página estavam antes. Isso ainda pode afetar um pouco a experiência do usuário, mas tudo ficará bem.

    No entanto, se você tiver um blog ou site enorme com milhares de páginas e artigos, os usuários terão dificuldade em descobrir em que artigo eles estavam se você os enviar para a página inicial .

    Um bom exemplo de implementação de seleção de idioma que sempre o envia para a página inicial pode ser encontrado em clinlife.com.

    Seletor de página inicial estática no menu de seleção de idioma

    URL em inglês para outros idiomas

    Como acabamos de ver a estrutura de URL não traduzida no exemplo acima, vamos falar sobre isso. Por que não traduzir todos os seus URLs estrangeiros? Todos sabemos que o uso de determinadas palavras-chave no URL pode ajudá-lo a ter uma classificação melhor. Obviamente, "estudos" serão menos úteis no Brasil do que "estudos". Sabemos que o conteúdo não é dinâmico em uma estrutura de URL estática, porque o URL pai muda (/ brpt # / en / caen # /).

    Se você deseja traduzir seu site, traduza seus URLs também.

    Isso geralmente é esquecido nos criadores de sites de comércio eletrônico e até nas ferramentas de otimização de mecanismos de pesquisa; muitos exemplos podem ser dados. Aqui está um site de comércio eletrônico:

    nenhuma tradução url hreflang

    Nenhuma tradução de URL em antrhropologie.com

    E aqui está outra loja online que comete o mesmo erro:

    nenhuma tradução de URL para o site

    Nenhuma tradução de URL em thenorthface.com

    Pense também em outros mecanismos de pesquisa

    Google aqui e google lá, mas a verdade é que em outros países, o Google não é o mecanismo de pesquisa mais popular! A Rússia, por exemplo, usa Yandex e a China tem Baidu. Diferentes países também usam diferentes mecanismos de pesquisa em diferentes proporções.

    uso de mecanismos de pesquisa em todo o mundo

    Fonte: www.martinkovac.com

    O Google é censurado em alguns países. Pense com cuidado antes de gastar tempo traduzindo o conteúdo dessas regiões. Além disso, considere que outros mecanismos de pesquisa não possuem os mesmos algoritmos que o Google. É bom saber, por exemplo, que o Yandex não usa links em seu algoritmo.

    Concentre todos os links apenas na versão principal

    Essa é uma das coisas que sempre mantém os concorrentes internacionais muito atrás dos concorrentes locais. O Google realmente gosta de links locais / regionais. Portanto, se você possui uma tradução de site em espanhol, é melhor ter links de domínio de nível superior .es do que links de domínio .com.

    Os concorrentes locais sabem disso e é muito mais fácil para eles adquirir links .es do que para um concorrente internacional. Eles não devem apenas confiar no desenvolvimento de links, eles podem interagir e participar de reuniões, conhecer novas pessoas e promover seus sites de uma maneira diferente.

    Também é muito comum que um site internacional não se concentre em suas versões traduzidas. Mas desde que você passou muito tempo traduzindo, não deveria se concentrar em promovê-lo?

    Se pegarmos um de nossos exemplos anteriores e passá-lo ao explorador de sites, podemos ver a diferença:

    Os backlinks regionais ajudam a classificar nesta região

    Orestimers do ISIONSHIBITORCROSSCROFILESHIFS, o site

    O pior de 0,7% é que todos esses links .fr apontam para a versão em inglês do site:

    backlinks regionais apontam para a versão errada

    Links regionais apontam para a versão errada

    Chame-o de SEO local, se desejar, mas concentre-se em criar backlinks regionais e certifique-se de criá-los para a versão correta.

    Problemas multilíngues de exibição e conteúdo que afetam o UX

    Embora os problemas de experiência do usuário ainda possam ser atribuídos à falta de conhecimento, os problemas de conteúdo provavelmente estão mais relacionados à ignorância. De qualquer forma, aqui está o que você deve prestar atenção:

    Usando o software de tradução automática do site

    Vamos começar com algo muito comum … Todos sabemos que o Google Tradutor nem sempre faz as coisas corretamente. De fato … isso não acontece com frequência (no momento).

    A maioria das pessoas usa essa técnica para obter conteúdo em inglês em outros idiomas (geralmente com o Google Translator ou um aplicativo Android / iOS), porque os mecanismos de pesquisa não são muito eficientes na detecção automática de conteúdo traduzido. É certo que o Google pode não ser tão bom para entender idiomas como o inglês, mas os usuários ainda são. E como o UX é um parâmetro tão importante, é um desperdício de tempo e dinheiro tentar fazer isso em larga escala.

    má tradução para sites

    As traduções humanas são definitivamente melhores, pois conhecem bem os dois idiomas (e um deles é de preferência a língua materna). Embora o conteúdo traduzido manualmente seja mais caro, fornecer uma tradução ruim do idioma para os usuários afetará sua marca e, possivelmente, a capacidade de atingir esse mercado-alvo no futuro. Se você deseja criar algo sólido, use um tradutor humano profissional.

    Não pesquise por palavra-chave

    Não basta traduzir as palavras-chave e esperar resultados. Um tradutor profissional não pode fazer tudo. Este é um bom começo, mas também é necessário entrar em contato com uma pessoa com o idioma nativo e a otimização do mecanismo de pesquisa para identificar e adicionar corretamente as frases apropriadas ao seu conteúdo.

    Também seria inútil comparar os números, já que o inglês é, por exemplo, muito mais usado que o italiano, os números em inglês sempre serão mais altos. No entanto, espero que você tenha a ideia de que as pessoas estão procurando coisas diferentes em diferentes países, mas querem o mesmo produto. Faça a pesquisa!

    Ne pas avoir de conscience culturelle

    Si vous voulez vraiment avoir un impact, vous devez étudier un peu la culture. Un traducteur peut aider, mais vous pourriez avoir besoin de plus que cela. Vous aurez besoin d’un représentant régional, d’une personne qui y a vécu et qui peut vous donner des idées. Bien sûr, cela se situe à un niveau supérieur, mais cela vaut la peine de le faire si vous avez les ressources.

    Un bon exemple simple pour commencer est le format de date. Certains pays utilisent jj / mm / aa, alors que d'autres utilisent mm / jj / aa. Un autre bon exemple serait de montrer un article sur la viande de porc dans une région musulmane. Pas une idée très brillante. Non seulement cela sera complètement hors de propos, mais cela fera également que beaucoup de gens se sentent mal.

    Traduire pas complètement les captchas

    C'est quelque chose de commun. De nos jours, beaucoup de gens utilisent Google Recaptcha, mais très peu le traduisent. Le résultat ressemble à ceci:

    pas de traduction recaptcha

    Tout le contenu en français, mais le captcha est en anglais

    Maintenant, pour vous, ce n’est pas un problème, puisque vous lisez cet article. Mais pour quelqu'un d'autre qui ne parle pas anglais, ça pourrait être. S'ils ne savent pas quoi faire, ils ne pourront pas vous contacter.

    Les webmasters ont pris des mesures pour y remédier en affichant le message suivant: Cochez la case «Je ne suis pas un robot» et suivez les instructions. Ce service nous protège des spammeurs.

    Problème résolu, non? Pas assez! Cela vous semble familier?

    pas de problème de traduction recaptcha lors de la traduction de sites Web

    Deuxième vérification occasionnelle. Cela peut aussi être différent à chaque fois.

    Ouais… ça peut être un peu frustrant.

    pas de traduction rend les utilisateurs malheureux

    Aucune traduction captcha ne rend les utilisateurs malheureux

    Mais la solution à ce problème est en réalité très simple. Recaptcha fonctionne à l'aide d'un fichier JavaScript. Ce fichier JS peut être traduit avec un paramètre ULR. Si le plug-in que vous utilisez n'autorise pas cela, vous pouvez rechercher dans le code le script suivant:

    https://www.google.com/recaptcha/api.js

    Ensuite, ajoutez simplement? Hl = xx après l’URL, où xx est le code de langue, comme pour les annotations HREFlang (fr, es, en). Pour le traduire en français, par exemple, il devrait ressembler à ceci:

    https://www.google.com/recaptcha/api.js?hl=fr

    Essayer de classer une page anglaise PARTOUT en utilisant HREFlang

    Je ne parle pas des personnes qui essaient de cibler des sites Web anglais aux anglophones d’Espagne, mais des personnes qui essaient de cibler des sites Web anglais partout, indépendamment de leur langue ou de leur lieu de résidence. Cela pourrait être fait avec intention ou par erreur.

    Commençons par l’erreur. Dites que je sais pertinemment que les Espagnols recherchent mon produit en anglais. Je veux cibler ce marché, alors j'ajoute HREFlang comme ceci:

    Comme mentionné précédemment au début de l'article, c'est faux! Por quê? Comme il s’agit d’un code de langue, je cible maintenant les utilisateurs hispanophones de partout pour leur afficher une page en anglais.

    La bonne façon de le faire serait d'utiliser à la fois le code de langue et le code de région. Par exemple, si vous souhaitez cibler les résidents anglophones d’Espagne, vous devez utiliser en-ES:

    Mais maintenant, de toute évidence, quelqu'un pourrait vouloir abuser de cela… il serait donc louche de cibler séparément les résidents anglais de partout, comme ceci:

    etc.

    Notez que j'ai utilisé la même URL à chaque fois dans l'exemple ci-dessus. Si j’avais une version différente pour chaque région (ce qui n’était pas une duplication complète), cela aurait du sens:

    etc.

    Ceci n'est acceptable que s'il existe vraiment des offres différentes pour différentes régions.

    Si toutes les versions sont identiques, c’est une perte de temps et d’espace disque dur. Il serait peut-être bon de cibler quelques marchés ou plus, mais pas tous. Si je veux cibler tous les anglophones de toutes les régions, je peux simplement spécifier la langue et laisser le reste à Google:

    (Ceci cible tous les utilisateurs anglophones, quelle que soit leur région ou leur localisation)

    Les gens vont toujours essayer de trouver un moyen de spam. Ils ne modifieront que les titres, par exemple, en laissant le reste du contenu en anglais et ils utiliseront HREFlang pour cibler toutes les régions. J'ai vu multilingue sites essayant de cibler toutes les langues, sans régions, sur la même page, comme ceci:

    etc.

    Unfortunately, I was unable to find a specific example, but I’m sure there are some out there.

    But Google isn’t stupid. Don’t try to rank a single page everywhere using the HREFlang attribute. Not only will this not work, but it would be against Google’s guidelines and might actually hurt your rankings.

    The HREFlang attribute should only be used if you truly have something unique/specific to display to that audience, in that language and in that region.

    Fonts and Diacritics

    Fonts can always be a problem when translating a website. You have to make sure that your current font supports all the special characters in the language you’re translating the site to. Otherwise they can mess up the web design by displaying a default font only for the missing characters and will usually look horrible! Something like this:

    font issues when translating to other languages

    “When the utilized font doesn’t contain a specific character, the software will use another font for it.”

    A good thing to look for is what happens on your mobile device. Sometimes, the characters display properly on your desktop but fail to display correctly on mobile devices. Also, your computer might display the font properly if it has it installed, but other computers might not. Using your mobile device to test this is a good idea.

    Usually it’s a font implementation issue, so make sure you check with your web designer before deciding to replace the font completely.

    Neglecting Social Media

    Last but not least, don’t forget or ignore social media. If you went through all the effort of translating the soon to be multilanguage websites, you might as well put in some effort into promoting it. If you’ve already registered different social media accounts for other countries, put them to good use by posting relevant content there as well.

    Keep in mind that in some countries, different social media platforms are popular. For example, don’t spend time trying to promote your website on Twitter in East European countries for instance. (I can tell you for a fact that people don’t really use the platform). On the other side, in other countries, Facebook doesn’t even exist (China).

    Things also vary depending on the niche you’re in. Tech images and news don’t work well on Pinterest, but cooking recipes and healthy lifestyle/motivational messages do. Thing is, your target audience might be in different places.

    Having an active social media account is a sign of authority. It means the brand is real and, most importantly, alive. It will help you gain the traction you need in order to rank well in Google with the translated version.

    Conclusion

    A multilingual website with properly performed international SEO is definitely something not easy to set up but, hopefully, this article helped you understand how to avoid the most common HREFlang mistakes if you’re planning to translate your website.

    Make sure you don’t set up the hreflang meta tags wrong or you will create more issues than not adding them at all. If you’re on a custom platform or you’re using a custom website builder and want to make sure your implementation is correct, you can try Aleyda Solis’ Tool. Use it to generate the correct HREFlang tags and then add them or compare them to your current ones. Remember, they need to be in your section.

    Keep in mind that your business website is alwaays better off if it’s manually translated by a professional. When the user changes the language from the language switcher, send them to the right page or make it clear that there is no translation available. Don’t trust translation plugins out of the box and make sure you check how they implement everything.

    Also, since you’re here, make sure you check out our article about using subdomains vs using subfolders when building multiple website sections. They might come in handy but, long story short, better have domain.com/en than en.domain.com.

    Thanks so much for reading this till the end! If you have any comments, ideas or opinions, feel free to share them with us in the comments section.


    Start Your Free 7-Day Trial

  • Comments are closed.