Resumo

  • Em fevereiro de 2009, o Google deu aos sites a opção de indicar com rel="canonical" qual URL deveria representar páginas duplicadas. O anúncio chamou a indicação de sinal forte, sujeito a outros sinais. O editor escolhia sua preferência; o mecanismo de busca mantinha a decisão.
  • O RFC 6596, de 2012, mostrou o risco de apontar errado: se a segunda página de uma reportagem disser que a primeira é sua versão canônica, seu texto exclusivo pode ser descartado no índice como repetição.

A mesma vitrine em endereços demais

Uma loja publica um produto em sua URL principal. Depois surgem versões com parâmetro de categoria, rastreamento de campanha ou identificação de sessão. O produto não mudou; o inventário de endereços cresceu. Em seu anúncio de 12 de fevereiro de 2009, o Google propôs uma linha no <head> das páginas duplicadas: <link rel="canonical" href="...">. A página informava qual endereço o site preferia ver nos resultados.

Não era um redirecionamento do visitante. A instrução chegava ao índice, que podia reunir sinais de links em uma URL e exibi-la como representante. Ao responder se o elemento era ordem ou sugestão, o Google disse que era uma sugestão forte, avaliada com outros sinais. O site sabia quais variantes havia criado. O buscador comparava rastreamentos, links e agrupamentos de conteúdo. A etiqueta abria um canal para o primeiro, sem transferir o comando do segundo.

O próprio texto de 2009 registra uma expansão posterior. A resposta inicial aceitava sugestões entre subdomínios, mas não entre domínios inteiramente diferentes; para uma mudança de domínio, recomendava redirecionamento permanente. Uma atualização de 17 de dezembro de 2009 anunciou suporte entre domínios. É um detalhe de data com consequência: o alcance de dezembro não fazia parte da promessa de fevereiro.

Quando o endereço preferido engole um capítulo

Em abril de 2012, o RFC 6596 definiu a relação canonical como indicação de uma IRI preferida para conteúdo duplicado ou contido integralmente no destino. Ela podia aparecer no HTML ou em um cabeçalho HTTP Link. Um aplicativo podia processar apenas o destino, transferir propriedades como popularidade de links e mostrar sua URL. O documento descrevia o que o relacionamento autorizava interpretar; cada sistema continuava a decidir como aplicá-lo.

Pense em uma reportagem dividida em duas páginas e oferecida também em versão integral. A primeira página não contém os parágrafos exclusivos da segunda; a versão integral contém ambos. Cada parte pode apontar para a versão completa sem perder sua contribuição. Se a segunda aponta para a primeira, a afirmação de equivalência é falsa. O RFC alerta que a segunda página pode ser marcada como duplicata e ter seu texto desconsiderado. O leitor ainda abre a página, mas a busca pode perder parte da reportagem.

O RFC recomenda uma relação canônica por recurso e desaconselha destinos com erro, redirecionamento permanente ou outra indicação canônica em cadeia. Diante de uma indicação incorreta, o aplicativo pode ignorá-la e recorrer a critérios próprios. A documentação atual do Google ainda descreve a escolha de uma representante com base em vários sinais, inclusive a possibilidade de divergir da preferência do editor. O documento atual mostra a prática atual; o limite de autoridade já aparecia na resposta de 2009.