O sintoma que leva as pessoas a este tema é quase sempre o mesmo: a empresa tem uma seção em japonês, ela está indexada e, ainda assim, quem pesquisa no Japão continua caindo na página em inglês. Às vezes a página em inglês chega a superar a japonesa numa consulta feita em japonês.

O hreflang costuma fazer parte dessa história. Nem sempre é a história inteira — uma página em japonês que ninguém procura não vai ranquear, não importa como esteja anotada —, mas é a parte que você consegue corrigir de forma determinística, e vale corrigi-la antes de concluir qualquer outra coisa.

O que o hreflang realmente faz

O hreflang não faz uma página ranquear. Ele informa ao Google que várias URLs são versões alternativas, por idioma ou região, do mesmo conteúdo, para que, quando uma delas se qualificar para um resultado, o Google possa substituí-la pela versão que corresponde ao idioma e à localização do usuário.

Duas consequências decorrem dessa definição, e a maioria dos erros de hreflang vem de ignorar uma delas.

Primeiro, é um mecanismo de substituição, não de reforço. Se a sua página em japonês não tem visibilidade própria e a página em inglês também não tem, um hreflang correto não muda nada.

Segundo, ele opera sobre clusters de URLs, não sobre sites. Cada página tem o seu próprio cluster. /services/technical-seo/ e /ja/services/technical-seo/ formam um cluster; as duas home pages formam outro. Um único bloco de anotações para o site inteiro, apontando para as home pages de cada idioma e repetido em todas as páginas, é uma das formas mais comuns de ter hreflang e não obter nenhum benefício dele.

ja ou ja-JP?

A subtag de idioma é ja. Não jp. jp é um código de país — é o que aparece em .co.jp e em ja-JP — e não é um valor de idioma válido por si só. hreflang="jp" é inválido e simplesmente ignorado. Esse é o erro de hreflang mais frequente que vemos em seções japonesas e, como anotações inválidas falham em silêncio, ele pode ficar lá por anos.

Entre ja e ja-JP, a resposta honesta é que ja é o correto para a maioria dos sites.

  • ja significa “esta página é para falantes de japonês”, em qualquer lugar do mundo.
  • ja-JP significa “esta página é para falantes de japonês no Japão”, e exclui falantes de japonês que navegam de outros lugares.

Use a subtag de região apenas quando você realmente tiver mais de uma versão em japonês diferenciada por país — por exemplo, uma página ja-JP com preços japoneses e uma página ja-SG para a entidade de Singapura. Se você tem exatamente uma página em japonês, ja cobre todos que deveriam vê-la, incluindo falantes de japonês em viagem ou morando no exterior. Restringir para ja-JP sem motivo simplesmente elimina uma parte do público.

Se você usar uma subtag de região, ela precisa ser um código de país ISO 3166-1 alpha-2, e a grafia convencional é ja-JP (o valor não diferencia maiúsculas de minúsculas, mas a consistência facilita a auditoria).

Reciprocidade: a regra em que tudo tropeça

Cada URL de um cluster precisa listar todas as URLs desse cluster, incluindo ela mesma. Se a página A declara a página B como sua alternativa em japonês, mas a página B não declara a página A de volta, o Google pode desconsiderar a anotação por completo.

A autorreferência é de fato obrigatória e de fato costuma estar ausente. A página em japonês precisa incluir uma linha hreflang="ja" apontando para si mesma, e não apenas a linha que aponta para o inglês.

Para um site com um original em inglês e uma versão em japonês, o bloco idêntico aparece nas duas páginas:

<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />

A forma mais confiável de acertar a reciprocidade é parar de mantê-la manualmente. Gere o cluster a partir de uma única fonte de verdade — um registro de páginas que saiba em quais idiomas cada página existe —, de modo que todas as páginas do cluster emitam a mesma lista por construção. Hreflang mantido à mão se degrada na primeira vez que alguém adiciona uma página.

x-default

x-default marca a página a ser exibida quando nenhuma outra versão corresponde ao usuário. Ele é opcional e frequentemente mal compreendido.

Aponte-o para a página que for a alternativa padrão mais sensata para “alguém para quem não temos correspondência melhor”. Normalmente, é a versão global em inglês, ou uma página real de seleção de idioma, se você tiver uma. Não aponte o x-default para a página em japonês — ela será exibida para usuários aos quais não se destinava.

O x-default também participa da reciprocidade: a mesma anotação deve estar em todas as páginas do cluster, incluindo a página para a qual ele aponta.

Uma nuance que vale conhecer: o x-default só se justifica quando há mais de uma versão para escolher. Numa página que existe em um único idioma, todo o bloco de anotações é ruído.

Onde colocar

Três métodos de entrega, todos igualmente válidos para o Google:

  • Elementos <link> no <head> — o mais simples e o padrão certo para a maioria dos sites. Eles precisam estar no <head> do HTML bruto, e não injetados por JavaScript no <body>.
  • Cabeçalhos HTTP Link — a única opção para arquivos não HTML, como PDFs.
  • Anotações no sitemap XML — muitas vezes a escolha mais fácil de manter em um site grande, porque todo o mapa de clusters fica em um único arquivo gerado, em vez de distribuído por milhares de templates.

Escolha um só. Dois métodos que divergem são piores do que qualquer um deles isoladamente, e esse é um resultado surpreendentemente comum quando um plugin e um template escrito à mão estão ativos ao mesmo tempo.

Canonical e hreflang precisam concordar

É aqui que muitas configurações, de resto corretas, quebram.

Cada versão de idioma precisa ter canonical autorreferente. A página em japonês aponta o canonical para si mesma. Se a página em japonês tiver um <link rel="canonical"> apontando para a URL em inglês — o que acontece com mais frequência do que se imagina, geralmente como resquício de uma preocupação com conteúdo duplicado —, você disse ao Google que a página em japonês não deve ser indexada, e a anotação hreflang que aponta para ela perde o sentido.

Regras relacionadas que decorrem do mesmo princípio:

  • O hreflang precisa apontar para a URL canônica e indexável — não para um redirecionamento, não para uma variante com parâmetros, não para uma página com noindex.
  • Use URLs absolutas, com o protocolo. URLs relativas não são suportadas no hreflang.
  • Siga exatamente as suas convenções de barra final, www e https. https://example.com/ja/pricing e https://example.com/ja/pricing/ são URLs diferentes, e uma divergência quebra a reciprocidade mesmo que o navegador chegue ao mesmo lugar.

Subdiretório, subdomínio ou .co.jp

O hreflang funciona de forma idêntica nas três opções. example.com/ja/, ja.example.com e example.co.jp podem ser anotados como alternativas entre si, e o Google lida bem com clusters de hreflang entre domínios.

Portanto, a decisão sobre a estrutura de URLs não é uma decisão de hreflang — é uma decisão de autoridade, operação e credibilidade, que analisamos separadamente em Você precisa de um domínio .co.jp para ranquear no Japão?. O único ponto relevante para o hreflang: um cluster entre domínios é mais difícil de manter recíproco, porque os dois lados costumam ser mantidos por equipes diferentes, com ciclos de release diferentes. É um risco operacional, não de ranqueamento, mas é real.

Os erros que vale verificar primeiro

Aproximadamente na ordem em que os encontramos:

  1. hreflang="jp" em vez de hreflang="ja".
  2. Ausência de anotação autorreferente em um ou nos dois lados.
  3. Clusters não recíprocos — geralmente porque a seção japonesa foi construída depois, por outra equipe, a partir de outro template.
  4. Anotação aplicada ao site inteiro, apontando todas as páginas para as duas home pages.
  5. Destinos de hreflang que redirecionam, retornam 404 ou têm noindex.
  6. A página em japonês com canonical apontando para a página em inglês.
  7. Divergências de protocolo, www ou barra final entre a anotação e a URL real.
  8. Anotações injetadas por JavaScript no lado do cliente.
  9. Redirecionamentos automáticos baseados em IP que mandam o Googlebot — que rastreia majoritariamente a partir de IPs dos EUA — para longe das páginas em japonês por completo.

Este último merece destaque porque anula todo o resto. Se os visitantes com IPs japoneses são redirecionados à força para /ja/ e todos os demais são redirecionados à força para fora dela, as suas anotações descrevem um site que o Google não consegue rastrear. Sugira a troca de idioma com um banner que possa ser fechado; não a imponha.

Como validar

O Google aposentou o relatório dedicado de Segmentação internacional no Search Console, então não existe mais um validador de hreflang oficial em que se apoiar. A validação agora é tarefa sua, e não é difícil:

  • Rastreie as duas seções de idioma com um crawler que extraia o hreflang e verifique a reciprocidade em todo o conjunto, em vez de conferir uma única página por amostragem. Erros de reciprocidade são sistemáticos; se uma página tem um, provavelmente centenas têm.
  • Verifique se cada URL de destino retorna 200, tem canonical autorreferente e é indexável.
  • Confira o HTML bruto, e não o DOM renderizado no inspetor do navegador — eles podem ser diferentes.
  • Use a ferramenta Inspeção de URL numa página representativa em japonês para confirmar que o Google enxerga o canonical que você pretendia.
  • Acompanhe o relatório de Desempenho do Search Console filtrado pelo Japão e observe qual URL recebe as impressões nas consultas em japonês. Se ainda for a URL em inglês semanas depois da correção, ou a anotação não está sendo respeitada, ou a página em japonês não é um resultado crível para aquela consulta.

É essa última distinção que vale guardar. O hreflang decide qual das suas páginas é exibida. Ele não decide se alguma delas merece ser. Se a página em japonês é uma tradução direta de uma página em inglês, construída em torno da demanda de busca em inglês, anotações corretas vão exibir uma página que ninguém estava procurando — que é o argumento desenvolvido em detalhe em Por que traduzir o seu site não é fazer SEO japonês.

Corrija primeiro a camada técnica, porque ela tem respostas objetivas e, uma vez corrigida, continua corrigida. Depois, encare a metade mais difícil.

Se você quer que a configuração seja verificada adequadamente, isso faz parte do nosso trabalho de SEO internacional para o Japão e de SEO técnico — envie-nos as URLs e contaremos o que encontrarmos.