Idiomas

Hreflang

O que é hreflang, as três formas de implementá-lo, as regras recíprocas e autorreferenciais, códigos válidos de idioma/região e como auditar clusters em escala.

Publicado pela primeira vez: 25 de jun. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
1 sinal de evidência nesta página

Hreflang informa aos mecanismos de busca qual versão de idioma/região de uma página mostrar para qual usuário. Você o declara de uma de três maneiras — tags no head do HTML, cabeçalhos HTTP ou sitemap XML — usando códigos de idioma ISO 639-1 + códigos de região ISO 3166-1 alpha-2. Ele só funciona como um cluster recíproco: cada página deve linkar para si mesma e para todas as suas alternativas, e se algum link de retorno estiver faltando, o Google ignora o par. É uma dica, não uma diretriz — hreflang incorreto é ignorado, não penalizado. Também é frágil: no meu estudo de 374 756 domínios que usam hreflang, mais de 67% tinham pelo menos um problema. O Bing quase não o usa (content-language é o sinal mais forte lá). Este hub explica tudo e aponta para os mergulhos profundos.

TL;DR — Hreflang é um sinal de cluster recíproco: cada página lista a si mesma e todos os alternates, e uma tag de retorno ausente anula o par. Declare-o de uma única forma — head HTML, cabeçalhos HTTP Link (PDFs) ou sitemap XML (melhor em escala). Os códigos são ISO 639-1 idioma + ISO 3166-1 alpha-2 região; en-UK está errado, é en-GB. É uma dica, não uma diretiva (Mueller) — hreflang errado é ignorado, não penalizado, e o Google pode substituí-lo para consolidação no mesmo idioma ou por motivos de indexação. Ele quebra constantemente: no meu estudo da Ahrefs com 374 756 domínios, mais de 67 % tinham pelo menos um problema. O Bing trata isso como um sinal muito mais fraco do que content-language. Audite clusters visualmente em vez de em planilhas.

Hreflang é um cluster, não uma tag

Hreflang sits between one piece of content and the right version showing up for each market's search. Fonte: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

A hreflang cluster is a bidirectional graph — one missing return link breaks just that pair. Fonte: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

O modelo mental que resolve a maior parte da confusão sobre hreflang: não é uma tag por página, é um grafo bidirecional. O requisito do próprio Google é direto — “Each language version must list itself as well as all other language versions,” e “if two pages don’t both point to each other, the tags will be ignored.” (tradução) «Cada versão de idioma deve listar a si mesma, bem como todas as outras versões de idioma» e «se duas páginas não apontarem uma para a outra, as tags serão ignoradas». Então, se a página X aponta para Y, mas Y não aponta de volta para X, essa aresta é silenciosamente descartada. Uma única tag de retorno ausente pode fazer com que as anotações afetadas sejam ignoradas ou interpretadas incorretamente — mas o Google diz que ainda pode processar os pares que são corretamente recíprocos, então uma relação quebrada não necessariamente derruba todas as anotações em um cluster maior.

Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelines

Dois pontos inegociáveis decorrem disso:

  • Reciprocidade. Cada referência deve ser retornada. É aqui que as implementações quebram em escala — no momento em que um template, um campo de CMS ou as páginas de uma região saem de sincronia, os links de retorno desaparecem.
  • Autorreferência. Cada página lista a si mesma. Mueller chama isso de “optional—but good practice”; (tradução) «opcional—mas boa prática»; na prática, um conjunto autorreferencial é a maneira mais limpa de manter clusters consistentes e é sinalizado como um problema quando ausente.

URLs absolutas e totalmente qualificadas também são necessárias — https://example.com/foo, nunca //example.com/foo ou /foo.

Três métodos — e os trade-offs

O Google trata tags HTML, cabeçalhos HTTP e sitemaps XML como equivalentes — não há benefício de Search em implementar mais de um. Escolha um método por site com base no que sua stack consegue manter de forma confiável; misturá-los convida a conflitos.

  • Tags <head> HTML. Mais simples, mais visíveis. Desvantagem: em um site com dezenas de locales, cada página carrega um grande bloco de tags <link>, adicionando peso de markup, e qualquer página no <body> (de HTML malformado ou injeção de JS) é inválida — hreflang só conta no <head> da página como o Google renderiza/parseia.
  • Cabeçalhos HTTP Link. A única opção para recursos não-HTML como PDFs. Enviados na resposta, então não incham o documento.
  • Sitemaps XML. A escolha certa em escala. As anotações vivem centralmente (filhos xhtml:link sob cada <url>, com o namespace xmlns:xhtml="http://www.w3.org/1999/xhtml"), então você pode regenerar todo o cluster a partir de um banco de dados sem reimplantar páginas. Não há método “mais rápido” — tanto HTML quanto sitemaps são resolvidos no momento do crawl — mas sitemaps são muito mais fáceis de fazer QA porque você pode validar o grafo inteiro em um arquivo em vez de rastrear cada página.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions

Linkagem recíproca em escala — onde ela quebra

Em um site com 5 locales, isso é uma matriz 5×5 de referências por conjunto de páginas, regenerada toda vez que você adiciona ou remove um locale, corrige um slug ou migra uma URL. Os modos de falha são previsíveis:

  • Formatos de URL inconsistentes. Barra final vs. sem, http vs. https, www vs. apex, ou caminhos em maiúsculas vs. minúsculas — qualquer incompatibilidade entre a URL no hreflang e a URL que o Google realmente indexa quebra a correspondência do link de retorno.
  • Apontando para URLs redirecionadas ou quebradas. Uma URL de locale muda, o redirecionamento entra, mas o hreflang ainda aponta para a URL antiga. O cluster agora referencia um 301 ou um 404.
  • Deriva de código. jp em vez de ja para japonês, códigos de três letras onde dois é obrigatório, en-UK em vez de en-GB. Códigos inválidos são ignorados.

Exemplo de implantação trabalhado: a tag de retorno aponta para a URL de ontem

Suponha que a página de produto do Reino Unido mudou de /gb/shoes/ para /uk/shoes/. A página dos EUA não foi regenerada, então ela ainda publica:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />

A URL antiga do Reino Unido redireciona para /uk/shoes/, enquanto a nova página do Reino Unido linka de volta para a página dos EUA a partir de sua URL canônica final. Isso deixa dois problemas distintos: a anotação dos EUA tem como alvo um redirecionamento, e a URL final do Reino Unido não é a mesma URL que a página dos EUA declarou. Corrija o gerador para que ambas as páginas publiquem o conjunto completo usando URLs finais, indexáveis:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />

Valide ambas as direções após a implantação; verificar apenas a tag de origem dos EUA perderia a falha da tag de retorno. Este é um cluster .example ilustrativo.

A lição de minhas palestras em conferências permanece: automatize a geração de hreflang a partir de uma única fonte de verdade. Hreflang mantido manualmente em escala é uma garantia de apodrecimento da tag de retorno.

Conflitos de canonicalização

Hreflang depende do que está indexado, não do que está canonicalizado — mas os dois interagem, e errar nisso quebra clusters:

  • Canônicos autorreferentes são o padrão seguro. Cada versão de idioma deve canonicalizar para si mesma. Se sua página em espanhol canonicaliza para a página em inglês, você está dizendo ao Google que a URL em espanhol não é a que deve ser indexada — e hreflang apontando para uma URL não canônica é um dos erros mais comuns.
  • O caso extremo de mesmo idioma e vários países. Quando você tem, digamos, páginas en-us e en-gb quase idênticas, o Google pode consolidá-las e indexar uma — mas ainda pode trocar a URL exibida na SERP para a versão correta do país por meio dos links hreflang. Portanto, uma URL “canonicalizada para longe” ainda pode aparecer para o usuário certo. Isso é um recurso, não um bug, mas surpreende quem audita a cobertura de indexação.
  • noindex e robots.txt. Uma página bloqueada de indexação não pode participar de um cluster — seu hreflang não pode ser aplicado, e apontar para uma URL noindexed/bloqueada quebra o link de retorno. Não bloqueie nem aplique noindex em variantes de idioma que você deseja servir.

É uma dica, não uma diretriz

Este é o enquadramento a internalizar. Em maio de 2025 no Bluesky, John Mueller respondeu a um caso de páginas fr-be aparecendo em resultados fr apesar do hreflang correto: “hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed,” e “I suspect this is a ‘same language’ case where our systems just try to simplify things for sites.” (tradução) «hreflang não garante indexação, então também pode ser apenas que nem todas as variações estejam indexadas» e «suspeito que este seja um caso de “mesmo idioma” em que nossos sistemas apenas tentam simplificar as coisas para os sites». O Google reserva o direito de substituir o hreflang para consolidação de mesmo idioma, lacunas de indexação ou suas próprias escolhas canônicas.

A orientação de canonicalização do Google é o outro lado disso: ela recomenda escolher um canônico no mesmo idioma da página (ou o melhor substituto disponível), e diz que prefere URLs que fazem parte de um cluster hreflang recíproco completo em vez de URLs semelhantes fora dele. Isso é uma preferência, não uma promessa — estar em um cluster construído corretamente melhora suas chances de a URL certa ser selecionada, mas não garante indexação nem qual URL aparece.

A consequência prática: hreflang errado é ignorado, não penalizado. Se seu cluster está quebrado, o Google recorre à própria detecção de idioma/região. O custo é oportunidade (a URL errada aparece para alguns usuários), não uma penalidade de ranqueamento. Então “meu hreflang está errado” raramente é uma emergência — mas também raramente está fazendo algo útil.

Bing e os outros mecanismos usam uma pilha diferente

Hreflang é um sinal do Google (e do Yandex). A pilha de sinais do Bing é completamente diferente. Fabrice Canel, Gerente Principal de Programa no Microsoft Bing, disse claramente que “hreflang is indeed a far weaker signal than content-language at Bing.” (tradução) «hreflang é de fato um sinal muito mais fraco do que content-language no Bing». O Bing depende do cabeçalho HTTP / meta tag content-language, do atributo <html lang="">, de links de entrada, geografia do visitante e localização do servidor/ccTLD, e Canel aconselhou contra “duplicating URLs just to have them tagged with these language-markets” na maioria dos casos. (tradução) «duplicar URLs apenas para tê-las marcadas com esses idiomas-mercados». Baidu não suporta hreflang de forma alguma (ele se baseia na localização do hosting, registro de domínio chinês, licenciamento ICP e content-language). Portanto, uma configuração internacional robusta combina hreflang para o Google com um content-language / html lang correto para todos os demais.

A taxa de erro é a história

Over 67% of domains using hreflang have at least one issue — missing x-default is the top offender. Fonte: Data: Ahrefs

Quando executei o maior estudo de hreflang até hoje na Ahrefs — 374 756 domínios, quase 10× maior que qualquer estudo anterior — mais de 67% dos domínios que usam hreflang tinham pelo menos um problema. A distribuição:

Problema% dos domínios
x-default ausente56,3 %
Tags autorreferentes ausentes18,0 %
Referência a páginas quebradas/redirecionadas16,9 %
Tags recíprocas ausentes15,3 %
Apontando para URLs não canônicas8,0 %
Códigos de idioma/país incorretos4,6 %
Atributos de idioma inconsistentes3,2 %
Múltiplas páginas para o mesmo idioma2,5 %
Mesma página para vários idiomas2,5 %

O resumo do meu estudo continua válido: hreflang é complexo e difícil de acertar, e pode quebrar de várias maneiras diferentes.

Auditoria em escala — visualize o cluster, não leia uma planilha

Veja seu próprio cluster com o returntag:

  1. Cole a URL de uma página, a URL de um sitemap ou uma lista de URLs de páginas na ferramenta.
  2. Clique em Validar cluster.
  3. Leia a visualização GRÁFICO — links de retorno quebrados ou ausentes se destacam pela cor de severidade — ou mude para MATRIZ para uma visão linha por linha, e exporte um CSV de lista de correções se precisar entregá-lo a outra pessoa.

O motivo pelo qual os erros de hreflang se escondem é que um problema de tag de retorno é um relacionamento entre páginas, e relacionamentos são quase impossíveis de ler em linhas de uma planilha. O Ahrefs Site Audit foi a primeira ferramenta a renderizar o cluster de hreflang como um grafo — abra os detalhes de URL de qualquer página e a aba Hreflangs desenha todo o cluster como uma rede, com as páginas quebradas e os links ausentes/incorretos destacados em vermelho. Você pode ver rapidamente qual tag de retorno está faltando ou qual link foi adicionado por engano — e é muito mais fácil mostrar para uma parte interessada do que um CSV. O Site Audit também executa as verificações subjacentes (anotação inválida, autorreferência ausente, mais de uma página por idioma, incompatibilidade hreflang/html lang, tag recíproca ausente, destino não canônico, destino quebrado) que mapeiam diretamente para a lista de erros do estudo.

Além disso:

  • GSC URL Inspection confirma como uma única URL foi rastreada e indexada. Observe que o antigo relatório de Segmentação internacional foi descontinuado em 22 de setembro de 2022 — o Google disse que ele “tinha pouco valor para o ecossistema.” As tags hreflang em si ainda funcionam; apenas o relatório desapareceu.
  • Teste manual de SERP com os parâmetros &hl= (idioma do host) e &gl= (geolocalização) em uma URL de pesquisa do Google permite visualizar como os resultados de uma determinada localidade se parecem.

Hreflang também é uma preocupação de auditoria técnica de SEO

Embora o lar do hreflang seja o SEO internacional, ele aparece em quase todas as auditorias técnicas de SEO de um site multilíngue ou multirregional — ele fica ao lado das verificações de canonização, indexação e acessibilidade de rastreamento, e é um dos itens com maior probabilidade de estar silenciosamente quebrado. Se você está realizando uma auditoria técnica e o site tem mais de uma localidade, o cluster de hreflang pertence à lista de verificação.

Onde ir a seguir

Este hub é o mapa para o subcluster de hreflang. O primeiro mergulho profundo:

  • x-default — o valor de fallback para usuários cuja localidade não corresponde a nenhuma das suas tags explícitas (um seletor de país ou uma página inicial global). Não é obrigatório, mas foi a omissão mais comum no meu estudo (56,3 % dos sites). O subtópico dedicado aborda quando usá-lo, quando ignorá-lo e como ele interage com o resto do cluster.

Para a estratégia mais ampla que isso implementa, veja o pilar de SEO internacional — hreflang é a camada técnica de uma estratégia internacional; ele não substitui a localização genuína (intenção local, conteúdo local, autoridade local).

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.