Quando as Tags Canônicas Apontam Entre Idiomas, o Hreflang Quebra

Uma página pode carregar 2 tags no mesmo <head> que se dirigem ao mesmo rastreador sobre o mesmo URL e dizem coisas opostas. Em https://example.com/fr/pricing, isso indica que a página é o membro francês de um cluster:

<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />

E isso, linha 1 abaixo, indica que a página é uma variante que deve ser incorporada ao original em inglês:

<link rel="canonical" href="https://example.com/pricing" />

Sites reais enviam ambos, do mesmo modelo, em todas as rotas localizadas que possuem. Esta é a falha que permanece após a que documentamos em julho — a referência própria hreflang ausente, ainda falhando 58% de 88 avaliações hreflang em nossos dados atuais. Um site pode fechar esse ciclo, acertar todas as referências próprias e ainda ter cada página localizada pedindo para ser substituída por seu gêmeo em inglês.

Um canônico entre idiomas pede ao Google que incorpore o local URL ao original

Uma tag canônica é um pedido de consolidação: trate este URL como uma variante daquele, e indexe aquele. Uma anotação hreflang é uma reivindicação de roteamento: este URL é a versão para este idioma. Direcione‑os para URLs diferentes e o site emite uma solicitação que anula sua própria reivindicação — o slot francês no cluster é preenchido por uma página que se desmarca.

O Google tem sido explícito ao dizer que hreflang é uma dica e não uma diretiva, e a canonização funciona da mesma forma: o site fornece sinais, o Google os resolve. Essa resolução é todo o problema. Com uma página localizada auto-canônica, o editor decide qual URL atende aos buscadores franceses. Com um canônico entre idiomas, o editor delegou a decisão enquanto acreditava que o cluster estava configurado — e o resultado que é relatado depois é uma página localizada que não aparece em seu próprio mercado enquanto a página em inglês aparece em seu lugar.

Os geradores que produzem isso são ordinários. Um auxiliar canônico construído a partir de uma definição de rota em vez do caminho da solicitação emite o URL sem prefixo para cada localidade. Um CMS cujo ajuste hreflang é por localidade, mas cujo ajuste canônico é global, faz o mesmo. Então há uma migração que adicionou prefixos de localidade aos URLs e deixou o canônico apontando para onde o conteúdo originalmente residia. Em cada caso a página renderiza perfeitamente, as anotações parecem completas em view-source, e a contradição é 2 atributos apart.

O conjunto de dados

Metodologia: último snapshot de auditoria concluída por domínio do nosso conjunto atual, aproximadamente maio 23 – August 31, 2026, anonimizado. Os denominadores diferem por verificação — 34 a 49 sites — porque uma verificação só é executada quando suas entradas existem: a verificação de referência própria não gera veredicto em uma página inicial sem anotações hreflang, razão pela qual seu contador de sites é o menor. Taxas de nível de avaliação e de site diferem porque alguns domínios foram auditados mais de uma vez na janela. A amostra é auto-selecionada — proprietários que realizaram uma auditoria — e tende a pequenos a médios, então trate as taxas como direcionais para esse segmento.

A segunda linha é o risco mais silencioso. Uma página sem canônico não contradigiu sua anotação hreflang, mas também não defendeu a anotação: nada na página indica qual URL ela considera autoritário, então uma variante de localidade acessível em mais de 1 endereço é resolvida inteiramente por inferência. Chegar a um cluster correto passa primeiro pela higiene canônica, razão pela qual nosso guia canônico é o pré-requisito para o guia de implementação hreflang, não um companheiro dele.

A contradição é visível apenas de ambos os lados do cluster

Uma única página não pode relatar essa falha sobre si mesma. /fr/pricing parece internamente consistente — um conjunto hreflang, um canônico, ambos bem formados. O defeito aparece quando você mantém a anotação e a página anotada lado a lado, razão pela qual verificá-lo significa buscar o cluster em vez de ler 1 documento.

Siga cada anotação hreflang até o seu alvo e registre o que volta: o código de status, se a requisição redirecionou, se há uma diretiva noindex presente e se o próprio canônico do alvo nomeia o URL para o qual a anotação apontava. Um alvo cujo canônico nomeia um URL diferente é o canônico entre idiomas de que trata este artigo.

O atributo lang é uma segunda testemunha. Uma página cujo html lang nomeia um idioma diferente da localidade que sua própria entrada hreflang afirma está se contradizendo da mesma forma, e muitas vezes é o primeiro sinal visível de que uma rota localizada está servindo o conteúdo do original.

Um alternativo que não pode ser buscado é uma lacuna de evidência, não prova de um defeito. Registre-o como não verificado e tente novamente antes de declarar o cluster quebrado.

graph TD
    FR["/fr/pricing — html lang=fr"]
    EN["/pricing — original em inglês"]
    FR -->|"hreflang=fr, auto-referencial"| CLAIM["Reivindicação: servir este URL a buscadores franceses"]
    FR -->|"rel=canonical"| EN
    EN -->|"hreflang=fr"| FR
    CLAIM --> Q{"Qual URL responde a uma consulta francesa?"}
    EN --> Q
    Q -->|"o site parou de decidir"| OUT["Google seleciona — geralmente o URL em inglês"]

Nossos próprios prefixos de local serviam inglês até August 17, 2026

Nós mesmos falhamos nessa classe de defeito em seoreport.dev. Ahrefs Site Audit relatou um hreflang e HTML desajuste de idioma em 184 URLs em nosso próprio site. O atributo lang era o sintoma; o conteúdo também era inglês, em cada um dos 9 prefixos de local, o que fez cada URL localizado ser um duplicado de seu gêmeo em inglês — o mesmo resultado que um canônico cross-language produz, alcançado a partir da outra direção.

A causa foi 1 fronteira de função. O shell do documento pegou seu idioma de um helper que retorna o idioma padrão sempre que window está indefinido. No servidor, /fr/pricing portanto renderizou lang="en" e semeou o bundle de tradução em inglês, enquanto o componente que emite os links head — que lê o caminho, não o runtime — emitia um fr self-hreflang correto diretamente ao lado. Um efeito de cliente mudou o idioma após hidratação, então toda verificação baseada em navegador passou e nenhum humano viu isso. Crawlers não executam esse efeito.

Corrigido em August 17, 2026: o shell deriva seu idioma do caminho, o layout localizado resolve o bundle de local em um loader para que renderização no servidor e hidratação compartilhem, e um local suportado sem bundle lança erro em vez de servir silenciosamente inglês sob seu prefixo. Direção de texto também estava errada — o árabe estava servindo ltr.

O teste de regressão é uma execução em HTML bruto sem JavaScript, porque a verificação do navegador é cega a esta classe inteira de falha. Executar red-first contra produção reportou 440 falhas em 128 URLs localizadas, cada página em 100% carryover em inglês. Contra a build corrigida: 0 falhas em 144 URLs. Uma comparação de lang com hreflang teria reprovado o nosso próprio site primeiro.

x-default herda o que a página de fallback declarar

Nossa amostra de sites que declaram x-default é muito pequena para publicar uma taxa de falha. O HTML também prova menos do que parece: mostra que uma anotação x-default é declarada, não qual público o editor pretendia atender. Os fatos verificáveis são os vizinhos — forma do URL, saúde do alvo, anotações recíprocas e alinhamento canônico.

O que o mecanismo implica vale a pena declarar de qualquer forma. x-default é o fallback para buscadores cujo idioma o site não serve, então normalmente aponta para a página de mercado principal. Se essa página carrega um canônico cross-language, o fallback para cada buscador não correspondido no planeta herda a contradição, e a contradição aparece na saúde do alvo em vez de na própria linha x-default.

Verifique em raw HTML, por localidade, em ambas as direções

Busque a página do jeito que um crawler faz e leia 3 coisas:

curl -s -A "Googlebot" https://example.com/fr/pricing | grep -iE '<html|rel="canonical"|hreflang'

O atributo lang, a entrada hreflang auto-referenciando, e o canônico devem concordar em 1 localidade e 1 URL:

<!-- On https://example.com/fr/pricing -->
<html lang="fr">
<link rel="canonical" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Em seguida repita em 1 página por localidade, e busque cada URL que a anotação nomeia para confirmar que cada um canoniza para si mesmo. A regra é curta o suficiente para entregar a um desenvolvedor: todo membro de um cluster hreflang canoniza para si mesmo. Um canônico cross-language é correto em exatamente 1 situação — quando o URL localizado não está localizado de forma alguma e serve o mesmo idioma que o original — e nessa situação o URL não pertence ao cluster também.

A Inspeção URL do Search Console dá a segunda opinião autoritária sobre qual canônico Google foi realmente selecionado, por URL. Um diagnóstico pago do SEOReport executa o loop sobre o cluster e lista cada par contraditório com a página onde foi encontrado. Os prefixos de localidade 9 em seoreport.dev passam agora, e eles passam porque enviamos o defeito primeiro, em um site cujo produto inteiro está encontrando-o.