Atena
Analytikos
Canonical entre domínios: tela com mensagens de erro de servidor em vermelho

Canonical entre domínios: os 3 desfechos que somem da busca

NAVEGAÇÃO RÁPIDA

Mais lidas

Carregando posts...

Um site some da busca. O dono abre o Search Console, investiga e encontra algo absurdo: o Google elegeu como canônica das páginas dele uma página de cassino, em outro domínio, sem nenhuma relação de conteúdo. A primeira reação é culpar o canonical entre domínios. Quase sempre o culpado é bem mais banal.

O caso foi levado ao fórum r/bigseo do Reddit, no tópico “Pages get deindexed by strange canonical content”, e respondido ali por John Mueller, do Google, em uma troca que a Search Engine Journal detalhou na sexta-feira. A explicação que apareceu no fio é a parte mais útil da história, e ela tem pouco a ver com canonical entre domínios.

Vale destrinchar o caso, porque o mecanismo por trás dele nada tem de exótico e atinge qualquer site que renderiza conteúdo no cliente e já teve uma janela de instabilidade.

O que foi relatado

O relato original no r/bigseo descreve uma desindexação lenta e crescente. As páginas tratavam de empresas e fornecedores, e o Google passou a apontar como canônica uma página de apostas sem similaridade alguma de conteúdo. O autor do relato não explicou como essa marcação teria surgido, e esse é justamente o buraco da hipótese.

Para um canonical entre domínios de verdade transferir sinais, a tag precisa estar no site de origem apontando para o destino. Se ninguém colocou essa tag, não é um caso de canonical entre domínios. Se colocou sem saber, a conversa muda de assunto e passa a ser sobre invasão.

A explicação que fecha a conta, e não envolve canonical entre domínios

Outro participante do fio relatou um episódio quase idêntico e trouxe o detalhe decisivo. Ao pesquisar a URL de terceiro no Google, ela aparecia indexada com o título de uma mensagem genérica de erro de aplicação JavaScript, a mesma que o site dele exibia durante quedas temporárias.

Isso nos faz suspeitar que, em algum momento, o Googlebot pode ter rastreado uma resposta de erro ou de fallback em vez do conteúdo real da página, e então tratado várias URLs que mostravam a mesma casca de erro como duplicatas.

Usuário No_Wrap_9584, no tópico do r/bigseo, em trecho citado pela Search Engine Journal

Esse é o ponto. Se dezenas de sites diferentes devolvem exatamente o mesmo texto de erro, o Google vê dezenas de páginas idênticas e faz o que a documentação oficial sobre canonicalização descreve: agrupa o conjunto e elege uma representante. A eleita pode ser qualquer uma delas, inclusive a do cassino.

Canonical entre domínios: diagrama do erro de renderização até a perda de indexação
Imagem: Analytikos. O caminho entre um deploy com falha e a perda de indexação.

A resposta de Mueller: o diagnóstico importa menos do que parece

Mueller concordou que a hipótese fazia sentido e recomendou o teste ao vivo de URL no Search Console para ver como o Google renderiza a página. Em seguida, publicou uma segunda resposta que reorganiza o problema de um jeito útil.

CenárioO que aconteceResultado na busca
Sua página é canônicaFica indexada com a mensagem de erroNão aparece para o conteúdo real
Sua página vira soft 404O Google trata como página inexistenteNão aparece para o conteúdo real
A outra página é canônicaA sua é agrupada com a de terceiroNão aparece para o conteúdo real
Imagem: Analytikos. Os três desfechos que Mueller descreveu, com o mesmo efeito prático.

Os três caminhos levam ao mesmo lugar. Gastar energia decidindo qual deles aconteceu é menos produtivo do que impedir que a página suba quebrada. Na leitura do próprio Mueller, o soft 404 seria inclusive o comportamento mais correto do buscador diante de uma casca de erro, e o documento oficial sobre códigos de status e erros de rede explica por que uma resposta 200 com conteúdo de erro é pior do que um 404 honesto.

A solução ideal é encontrar formas de reconhecer esse tipo de erro do seu lado, antes de colocar o site no ar com o erro.

John Mueller, Google

Por que o canonical entre domínios quase nunca é a resposta hoje

O recurso de canonical entre domínios nasceu para sinalizar migração quando o redirecionamento 301 era impossível, cenário hoje raríssimo. Depois virou muleta para conteúdo sindicalizado, até o Google mudar a orientação e passar a recomendar a meta tag noindex nas cópias.

Como o canonical é apenas uma dica forte e não uma ordem, existem caminhos melhores e mais determinísticos para o mesmo objetivo. O guia oficial de como especificar a URL canônica deixa claro que redirecionamento é sinal forte, e o material de solução de problemas de canonicalização cobre os casos em que a escolha do Google diverge da sua.

Se você já acompanhou aqui por que o canonical autorreferencial voltou à recomendação oficial e quanto tempo o Google leva para reavaliar uma escolha de canônica, a conclusão é a mesma: canonical resolve duplicidade interna, não conserta infraestrutura.

Como detectar antes que o Google detecte

A parte mais aproveitável da resposta de Mueller é operacional. Ele contou que roda uma bateria de testes automatizados antes de publicar os próprios sites, e adiciona um teste novo sempre que algo dá errado. Vale traduzir isso para uma rotina de e-commerce ou portal:

  • Testes automatizados no pipeline, bloqueando o deploy quando uma página crítica não renderiza conteúdo.
  • Monitoramento externo das URLs mais importantes, com verificação de conteúdo e não apenas de status HTTP.
  • Alerta quando o HTML retornado encolhe além de um limite, sinal clássico de casca de erro.
  • Resposta 5xx de verdade quando a aplicação falha, nunca um 200 com mensagem de erro no corpo.
  • Teste ao vivo de URL no Search Console após qualquer incidente, para ver o que o Googlebot enxergou.
  • Revisão do canonical eleito nas páginas afetadas nas semanas seguintes ao incidente.

Sites que dependem de JavaScript para montar o conteúdo principal correm mais risco, porque a falha aparece como página válida com corpo vazio. Esse é o mesmo território de problemas que já discutimos ao falar de como a qualidade do site afeta páginas não indexadas e de orçamento de rastreamento.

Uma última ressalva sobre causa e efeito

O texto da Search Engine Journal faz uma observação que merece repetição. Quando uma queda acontece, a tendência é encontrar qualquer anomalia visível e promovê-la a causa. Links ruins, canibalização, canonical estranho: tudo vira explicação se você olhar com vontade suficiente.

Coincidência não é causalidade. Antes de reescrever a arquitetura de canônicas do site, ou de banir o canonical entre domínios por causa de um caso relatado na internet, confirme no seu próprio Search Console o que o Google rastreou, quando rastreou e o que recebeu de volta.

Perguntas frequentes

O que é um canonical entre domínios?

O canonical entre domínios é a tag canônica apontando para uma URL em outro domínio, indicando que o conteúdo original está lá. O Google trata como dica forte, não como ordem, e hoje recomenda redirecionamento ou noindex na maioria dos casos que antes usavam esse recurso.

Um site de terceiro pode canonicalizar as minhas páginas sem minha permissão?

Não pelo caminho normal. Para existir um canonical entre domínios, a tag precisa estar no seu site apontando para o outro domínio. Se ela apareceu sem que ninguém da equipe a tenha colocado, o cenário a investigar é invasão, não SEO.

Por que uma página de erro faz o Google agrupar sites diferentes?

Porque mensagens genéricas de erro de aplicação são idênticas em milhares de sites. Se o Googlebot rastreia essa casca no lugar do conteúdo, ele vê páginas duplicadas e escolhe uma representante para o grupo.

Como saber o que o Googlebot realmente viu na minha página?

Use o teste ao vivo de URL no Search Console e compare o HTML renderizado com o conteúdo esperado. É o caminho recomendado pelo próprio Google e o mais rápido para confirmar se a falha estava na renderização.

Quanto tempo leva para o Google reverter uma escolha errada de canônica?

Depende da frequência de rastreamento da página. Em relatos recentes o intervalo típico ficou em torno de duas semanas após a correção, e páginas menos rastreadas podem demorar mais.

Conteúdos Relacionados

Compartilhar esse post
Facebook
WhatsApp
LinkedIn
Leia também:

Mais lidas

Carregando posts...

Conteúdos Relacionados:

Receba conteúdos exclusivos e novidades

Estratégia e resultados baseados em dados.

Rolar para cima