Como Implementar Tags hreflang para WordPress Multilíngue
Você traduziu todo o seu site WordPress para seis idiomas. Os arquivos .po estão limpos, os arquivos .mo estão compilados, e cada string é renderizada perfeitamente em francês, alemão e japonês. No entanto, semanas após o lançamento, você verifica o Google Search Console e encontra algo intrigante: sua página em francês está classificando para pesquisas em alemão, sua página em espanhol-México está sendo exibida para usuários na Espanha, e duas das suas versões de idioma estão canibalizando-se mutuamente nos rankings. O conteúdo está bom. O problema é que o Google não tem ideia de qual versão pertence a qual público.
Isso é exatamente o que as tags hreflang WordPress foram projetadas para corrigir. Hreflang é o sinal que informa aos motores de busca qual idioma e versão regional de uma página servir a cada usuário. Se você errar, sofrerá diluição de conteúdo duplicado, resultados no idioma errado e desperdício de orçamento de rastreamento. Se você acertar, cada página traduzida alcançará o público para o qual foi escrita. Este guia aborda a sintaxe, a diferença entre códigos de idioma e idioma-região, o x-default obrigatório, a reciprocidade das tags de retorno e três maneiras práticas de implementá-lo no WordPress.
O Que o hreflang Realmente Faz
Hreflang não traduz nada. É um mapa de relacionamentos. Quando você tem a mesma página em vários idiomas, as anotações hreflang dizem ao Google "esta URL é a versão em inglês, esta é a versão em alemão, esta é para falantes de espanhol no México." O Google usa esse mapa para servir a versão correta nos resultados de pesquisa com base nas configurações de idioma e localização do usuário.
A anotação reside no <head> do seu HTML como um conjunto de elementos <link>. Cada elemento nomeia uma página de destino e o idioma (e, opcionalmente, a região) que ela atende. Aqui está um conjunto correto de tags hreflang para uma página disponível em inglês dos EUA, inglês do Reino Unido e espanhol mexicano, com um fallback padrão:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Cada página no conjunto deve exibir este mesmo bloco, listando todas as alternativas, incluindo ela mesma. Este último ponto confunde a maioria das pessoas, e voltaremos a ele.
Por Que Isso É Importante para SEO
Sem hreflang, o Google trata suas páginas traduzidas como quase-duplicatas competindo pelas mesmas palavras-chave. O resultado é a diluição: sinais de ranking divididos entre versões em vez de consolidados. Com hreflang correto, cada versão herda a autoridade do conjunto como um todo e aparece para os pesquisadores certos. Esta é uma das ações de SEO de maior alavancagem que um site multilíngue pode fazer, e complementa, em vez de substituir, a tradução real do conteúdo em seus arquivos .po. Cobrimos o lado do conteúdo em profundidade em nosso guia sobre como a tradução de arquivos PO impacta os rankings do Google.
Códigos de Idioma vs. Idioma-Região
Qual você deve usar, en ou en-GB? Use o código mais simples que seja verdadeiro. Se o seu conteúdo em inglês é genérico e você não mantém versões britânicas e americanas separadas, use apenas en. Adicione um subcódigo de região apenas quando você realmente serve conteúdo diferente para países diferentes.
Os valores hreflang seguem o formato idioma ou idioma-região. A parte do idioma é um código ISO 639-1 (en, es, de, pt). A região opcional é um código de país ISO 3166-1 Alpha 2 (US, GB, MX, BR). Assim:
endireciona todos os falantes de inglês, independentemente do país.en-GBdireciona falantes de inglês no Reino Unido.esdireciona todos os falantes de espanhol.es-MXdireciona especificamente falantes de espanhol no México.
Um detalhe crítico: o subcódigo de região é um país, não uma variante de idioma. es-MX não significa "dialeto espanhol mexicano", significa "espanhol, exibido para usuários no México." O Google ainda o serve com base na localização do usuário. Se você mantém dialetos regionais em suas traduções, o código de região é como você os direciona. Aprofundamos o lado linguístico disso em nosso guia sobre variantes regionais de espanhol e português.
Um Exemplo Comum de Erro
Aqui está um bloco hreflang incorreto que vemos constantemente:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Três erros. en-uk é inválido porque o código de país para o Reino Unido é GB, não UK. sp não é um código de idioma; espanhol é es. E pt-PT_BR mistura duas regiões com um underscore que não tem significado em hreflang. Os motores de busca ignoram silenciosamente valores malformados, então você não recebe nenhum erro e nenhum benefício, apenas horas de depuração se perguntando por que nada mudou.
Observe que hreflang usa um hífen (en-GB), enquanto os arquivos de localidade do WordPress usam um underscore (en_GB). Não copie os códigos de nome de arquivo .po diretamente para as tags hreflang.
O x-default e a Reciprocidade das Tags de Retorno
Duas regras causam mais falhas silenciosas de hreflang do que qualquer outra coisa: o x-default ausente e a reciprocidade quebrada.
O valor x-default informa ao Google qual página servir quando nenhum outro idioma corresponde ao usuário. É o seu fallback, tipicamente o seu seletor de idioma ou a página inicial do seu mercado primário. Não é estritamente obrigatório pela especificação, mas na prática você deve sempre incluí-lo. Sem ele, um visitante de língua portuguesa para quem você não tem uma versão em português recebe uma escolha aleatória em vez de um padrão deliberado.
A reciprocidade das tags de retorno não é negociável. Cada página em um conjunto hreflang deve apontar de volta para todas as outras páginas, incluindo ela mesma. Se sua página em inglês lista o alemão como uma alternativa, sua página em alemão deve listar o inglês como uma alternativa. Se a página em alemão omitir a referência de retorno, o Google desconfia de todo o relacionamento e ignora as anotações.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
A auto-referência (de apontando para a página em alemão enquanto visualiza a página em alemão) é obrigatória, não opcional. Um conjunto de cinco versões de idioma significa que cada uma das cinco páginas exibe todas as cinco tags <link> mais o x-default.
Três Formas de Implementar hreflang no WordPress
Você tem três opções práticas, que variam de controle manual total a totalmente automatizado.
Método 1: Manual via wp_head
Para um pequeno conjunto estático de páginas, você pode injetar tags hreflang diretamente através da ação wp_head no functions.php do seu tema:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Isso lhe dá controle preciso, mas não escala. Manter a reciprocidade manualmente em centenas de posts é uma armadilha de manutenção.
Método 2: Um Plugin Multilíngue
Se você usa Polylang, WPML ou TranslatePress, o hreflang é gerado automaticamente com base nos seus relacionamentos de tradução. Esta é a resposta certa para a maioria dos sites porque o plugin já sabe qual post é a tradução de qual, então a reciprocidade e o x-default são tratados para você. O custo é a sobrecarga de tempo de execução que esses plugins adicionam, que é o trade-off que examinamos em nossa comparação de abordagens de tradução manual versus IA.
Método 3: Sitemap XML com xhtml:link
Em vez de colocar hreflang no <head> de cada página, você pode declarar os relacionamentos no seu sitemap XML usando o namespace xhtml:link. Cada entrada <url> lista todas as suas alternativas de idioma:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Isso mantém o HTML da sua página enxuto e centraliza o mapa de idiomas em um único arquivo rastreável, que o Google lê sem problemas. A maioria dos plugins de SEO pode gerar isso automaticamente.
hreflang Complementa a Tradução, Não a Substitui
Aqui está o ponto que todos perdem: hreflang é inútil se as páginas subjacentes não estiverem realmente traduzidas. A tag diz ao Google "esta é a versão em alemão", mas se a URL alemã ainda mostra strings de plugin em inglês, rótulos de checkout não traduzidos ou arquivos .po semi-acabados, você simplesmente disse ao Google para servir conteúdo quebrado aos usuários alemães com total confiança.
O SEO multilíngue real tem duas camadas. A camada de conteúdo são seus arquivos .po, .pot, .json e .xliff traduzidos, levando cada string de tema e plugin para o idioma de destino. A camada de sinal é o hreflang, que direciona cada versão finalizada para seu público. Ambas precisam ser sólidas. Um conjunto hreflang impecável em cima de um site 40% traduzido apenas garante uma experiência pior mais rapidamente.
É aqui que manter a camada de tradução limpa é mais importante. Ao traduzir seus arquivos de interface, placeholders como %s, %1$s e {name} devem permanecer intactos, ou sua página alemã "traduzida" será renderizada com tokens %s literais que parecem quebrados tanto para usuários quanto para motores de busca. Um pipeline de tradução compatível com gettext e com Syntax Locking protege esses tokens automaticamente, para que cada página alternativa para a qual você aponta o hreflang esteja genuinamente pronta para produção. Como ele funciona na nuvem com Smart Batching, você pode enviar um site multilocal completo através dele sem instalar plugins de tradução que incham o tempo de execução que servem essas mesmas páginas.
Primeiro, faça o conteúdo certo, depois deixe o hreflang fazer o seu trabalho. Os dois juntos são o que consolidam os sinais de ranking, eliminam resultados em idioma errado e colocam cada página traduzida na frente das pessoas que podem lê-la.
Pronto para corrigir os resultados de pesquisa em idioma errado na origem? Experimente o SimplePoTranslate gratuitamente — não é necessário cartão de crédito. Traduza seus arquivos
.po,.pote.jsonno plano gratuito e, em seguida, aponte suas tags hreflang para páginas que estão realmente prontas para todos os mercados.