"Duplicada, o Google escolheu uma canônica diferente" e os outros status de canonical do Search Console

Por que o Google agrupa páginas e escolhe uma

Quando o mesmo conteúdo responde em mais de um endereço, o Google junta essas URLs num grupo e escolhe uma como representante, a canônica. Só ela aparece normalmente nos resultados. As outras ficam de fora do índice, e o Search Console conta cada uma delas como "não indexada" com um motivo.

Isso acontece em todo site, e o Google diz com todas as letras que ter um pouco de conteúdo duplicado é normal e não é violação das políticas de spam. As origens mais comuns que a documentação cita:

• Região: páginas pra países diferentes com praticamente o mesmo conteúdo no mesmo idioma.
• Dispositivo: versão pra celular em outro endereço, como m.seusite.com.br.
• Protocolo: o site respondendo em http:// e em https://.
• Funções do site: ordenação e filtros de uma categoria, parâmetros de rastreamento como ?gclid=.
• Variantes acidentais: um ambiente de demonstração aberto pros robôs, a home respondendo em / e em /home.

Você pode sugerir qual URL prefere. O Google leva em conta, mas trata como sugestão: a escolha final é dele. Os três status abaixo contam como essa escolha terminou.

Os três status, um por um

Eles aparecem no relatório de indexação de páginas do Search Console (menu Indexação › Páginas), na lista de motivos das páginas não indexadas. Um aviso sobre os nomes: a central de ajuda em português chama o terceiro de "Cópia, o Google e o usuário não escolheram a mesma página canônica". Em inglês ele é "Duplicate, Google chose different canonical than user", e muita gente procura pela tradução "Duplicada, o Google escolheu uma canônica diferente da do usuário". É o mesmo status.

Página alternativa com tag canônica adequada

A central de ajuda resume assim: a página direciona corretamente pra página canônica, que está indexada. Os exemplos da ajuda são uma página AMP com canônica de desktop, a versão pra celular de uma canônica de desktop ou o contrário. O Google entendeu o seu canonical, concordou com ele e indexou a página certa. A própria ajuda diz que nenhuma ação é necessária.

Então "página alternativa com tag canônica adequada" é erro? Na maioria dos casos, não. Só vale olhar com atenção quando aparecem ali páginas que deveriam estar no Google por conta própria: posts, produtos, categorias. Isso indica que elas estão apontando pra outra URL sem querer, como uma página 2 de categoria apontando pra página 1 ou um template que grava o canonical da home em todo o site. Aí o problema é o canonical errado, assunto do artigo sobre canonical apontando pro lugar errado.

Um detalhe: o Search Console não detecta páginas em outro idioma como alternativas. Versões traduzidas não entram nesse status.

Cópia sem página canônica selecionada pelo usuário

A página é cópia de outra, mas não indica qual é a preferida. O Google escolheu uma por conta própria e esta ficou fora da busca. A ajuda chama isso de comportamento padrão, não de erro.

Você tem três caminhos:

• O Google escolheu bem: não precisa fazer nada. Declarar o canonical mesmo assim deixa a escolha explícita e evita surpresa no futuro.
• O Google escolheu a URL errada: declare a canônica que você quer, com rel="canonical", e alinhe os outros sinais (seção abaixo).
• A página não é cópia: deixe a diferença clara no conteúdo. Se duas páginas de produto só mudam a cor no título, o Google tende a juntar as duas.

Duplicada, o Google escolheu uma canônica diferente da do usuário

A página está marcada como a canônica do grupo, mas o Google acha que outra URL é mais adequada e indexou essa outra. Aqui o Google discordou de você, e é o status que mais merece investigação.

A ajuda dá a pista principal: uma cópia precisa ser parecida com a canônica. Se a URL que você declarou como canônica não é semelhante à página, o Google não aceita. E, mesmo quando o conteúdo bate, outros sinais podem pesar mais que a tag. Só depois de comparar as duas URLs dá pra saber qual é o seu caso.

Os três lado a lado

Por que o Google ignora o seu canonical

O Google usa vários sinais pra escolher a canônica, e a documentação diz quanto cada um pesa: redirecionamento é um sinal forte, rel="canonical" é forte e o sitemap é fraco. Eles se somam. Quando apontam todos pra mesma URL, a chance de ela ser a escolhida aumenta. Quando apontam pra lugares diferentes, o Google escolhe entre eles. As contradições mais comuns:

• Redirect pro outro lado. O canonical da página A aponta pra B, mas B redireciona pra A (ou pra C). O redirect é sinal forte e costuma ganhar.
• Sitemap com outra URL. O canonical diz /produto e o sitemap lista /produto?cor=azul. O Google pede pra não indicar URLs diferentes como canônicas da mesma página por métodos diferentes.
• Links internos apontando pra versão duplicada. Menu, breadcrumb e listagens linkando pra /produto/ enquanto o canonical diz /produto. A documentação recomenda linkar sempre a URL canônica.
• Conteúdo diferente. O canonical aponta pra uma página que não é parecida: a home, a página 1 de uma lista, um produto de outra cor com outro texto. Como a cópia precisa ser semelhante à canônica, o Google ignora.
• http e https. O Google prefere HTTPS como canônica, salvo se ela tiver problema: certificado inválido, recursos inseguros ou redirect de HTTPS pra HTTP. Canonical apontando pra http:// briga com essa preferência.
• www e sem www, barra no fim. Se o canonical diz https://www.seusite.com.br/sobre/ e o servidor redireciona pra https://seusite.com.br/sobre, a canônica declarada é uma URL que redireciona. Escolha um padrão e use em todo lugar.
• Parâmetros. Filtros, ordenação e rastreamento de campanha criam URLs novas com o mesmo conteúdo. Cada uma deve apontar pra versão limpa, e os links internos não devem carregar o parâmetro.
• Canonical fora do <head>, duplicado ou trocado por JavaScript. A tag fora do <head> é ignorada. O Google também pede pra não trocar o canonical do HTML via JavaScript: ou ele vem certo no HTML, ou só no JavaScript.
• Idiomas sem hreflang. Sites regionais com o mesmo conteúdo localizado, sem anotação hreflang, são agrupados. URLs que se apontam com hreflang ganham preferência como canônicas sobre URLs fora do grupo.

Existem também causas fora do seu código. A página de solução de problemas do Google cita servidor mal configurado (que entrega o conteúdo de um domínio quando se pede outro), site invadido com canonical ou redirect pra outro domínio, conteúdo republicado por parceiros e, mais raramente, um site que copiou o seu sem permissão.

Passo a passo na Inspeção de URL

1. Abra o motivo no relatório. No Search Console, vá em Indexação › Páginas, desça até a lista de motivos das páginas não indexadas e clique no status. A lista mostra as URLs afetadas.
2. Inspecione uma URL. Copie um dos endereços da lista e cole na barra de inspeção, no topo do Search Console.
3. Abra a seção Indexação da página. Ela traz os dois campos que importam: URL canônico declarado pelo usuário (o que a sua página diz, por tag, cabeçalho HTTP ou sitemap) e URL canônico selecionado pelo Google (o que ele escolheu).
4. Compare as duas. Abra as duas URLs lado a lado no navegador. A pergunta da própria documentação é: a página que o Google escolheu faz mais sentido pra quem chega pela busca? Às vezes faz, e a correção é aceitar.
5. Veja o que o Google recebeu. Clique em Ver a página rastreada pra ver o HTML e os cabeçalhos HTTP que o Googlebot buscou. Procure ali o rel="canonical" e um cabeçalho Link.
6. Rode o teste em tempo real depois de corrigir (botão Testar o URL publicado). Ele mostra o canonical declarado na versão atual, mas não mostra qual o Google vai escolher. A ajuda é clara: o teste em tempo real não consegue prever se a versão testada vai ser considerada canônica. Essa decisão só sai na indexação.

Uma observação: se a URL escolhida pelo Google estiver numa propriedade do Search Console que não é sua (outro domínio, por exemplo), você não vai ver o tráfego dessa cópia no seu relatório.

Como corrigir em cada caso

Três coisas que a documentação pede pra não fazer: usar o robots.txt pra canonicalizar (bloquear a URL não impede que ela seja indexada sem conteúdo), usar a ferramenta de remoção (ela esconde todas as versões da URL) e usar noindex pra escolher a canônica (ele tira a página da busca). Se a duplicata não precisa mais existir, o redirect permanente é o sinal mais forte.

Com idiomas, a regra é apontar o canonical pra uma página no mesmo idioma, ou pro melhor substituto quando a tradução não existe. Páginas com o conteúdo principal em idiomas diferentes não são cópias; mas, se só o menu e o rodapé foram traduzidos e o corpo é igual, elas são tratadas como duplicadas.

Exemplos de código

A tag no HTML

Dentro do <head>, com URL absoluta. A página canônica também aponta pra si mesma:

<head>
  <title>Tênis azul</title>
  <link rel="canonical" href="https://seusite.com.br/produtos/tenis-azul" />
</head>

Não use rel="canonical" com hreflang, lang, media ou type. Versões alternativas usam rel="alternate", como a versão pra celular em outro endereço:

<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.seusite.com.br/produtos/tenis-azul" />

O cabeçalho Link pra PDF e outros arquivos

PDF, Word e outros arquivos não têm <head>. Pra eles, o canonical vai no cabeçalho HTTP da resposta, também com URL absoluta. Se o mesmo material existe em .docx e em PDF, a versão .docx pode apontar pro PDF:

HTTP/1.1 200 OK
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Link: <https://seusite.com.br/downloads/guia.pdf>; rel="canonical"

No nginx, a diretiva add_header resolve:

# nginx
location = /downloads/guia.docx {
    add_header Link '<https://seusite.com.br/downloads/guia.pdf>; rel="canonical"';
}

Escolha um lugar pra cada URL: tag no HTML ou cabeçalho, não os dois com valores diferentes.

Next.js (App Router)

Defina o domínio de produção no metadataBase do layout raiz e o canonical em cada página com alternates.canonical. O Next junta os dois numa URL absoluta:

import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://seusite.com.br"),
};

import type { Metadata } from "next";

export async function generateMetadata({ params }: { params: Promise<{ slug: string }> }): Promise<Metadata> {
  const { slug } = await params;
  return {
    alternates: {
      canonical: `/produtos/${slug}`,
      languages: { "en-US": `/en/products/${slug}` },
    },
  };
}

A saída é <link rel="canonical" href="https://seusite.com.br/produtos/tenis-azul" /> mais um <link rel="alternate" hreflang="en-US">. Duas pegadinhas. A primeira: os metadados de segmentos diferentes são mesclados de forma rasa, então um alternates definido na página substitui o do layout inteiro. A segunda: desde a versão 15.2, quando o generateMetadata demora, o Next pode transmitir os metadados depois e acrescentá-los ao <body> pra robôs que executam JavaScript. A documentação do Next diz ter verificado que o Googlebot interpreta isso corretamente; mesmo assim, confira com curl onde o canonical aparece. Se quiser os metadados sempre no <head>, a opção htmlLimitedBots: /.*/ no next.config desliga essa transmissão, ao custo de respostas mais lentas.

Como conferir com curl

Primeiro, o canonical que o HTML entrega, sem JavaScript:

curl -s https://seusite.com.br/produtos/tenis-azul | grep -io '<link[^>]*canonical[^>]*>'

Se aparecer mais de uma linha, há canonical duplicado (tema e plugin, por exemplo). Depois, o cabeçalho, que é onde fica o canonical de PDFs:

curl -sI https://seusite.com.br/downloads/guia.docx | grep -i '^link:'

Agora confira se a URL canônica responde 200, sem redirect. Se este comando mostrar um 301 ou 302, com o destino ao lado, o canonical aponta pra um endereço que redireciona:

curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://seusite.com.br/produtos/tenis-azul

Por fim, teste as variantes. Todas devem redirecionar pra mesma URL final ou apontar pra ela no canonical:

for u in http://seusite.com.br/produtos/tenis-azul \
         https://www.seusite.com.br/produtos/tenis-azul \
         https://seusite.com.br/produtos/tenis-azul/ \
         "https://seusite.com.br/produtos/tenis-azul?utm_source=teste"; do
  printf "%s\n  final: " "$u"
  curl -sL -o /dev/null -w "%{url_effective}\n" "$u"
  printf "  canonical: "
  curl -sL "$u" | grep -io '<link[^>]*canonical[^>]*>' | grep -o 'href="[^"]*"'
done

Pra não fazer isso página por página, a ferramenta verificar canonical lê o canonical de cada página da amostra e avisa quando ele falta ou aponta pra outra URL. Vale também passar o sitemap no validador de sitemap: ele deve listar só as URLs canônicas, nunca as variantes.

Quanto tempo leva pra atualizar

• Na Inspeção de URL, o "URL canônico selecionado pelo Google" só muda depois que o Google rastreia e indexa a página de novo. A própria ajuda avisa que esse valor pode estar algumas horas atrasado em relação ao índice.
• Pra reavaliar o agrupamento, a página de solução de problemas fala em até duas semanas, mesmo depois das correções. Páginas cuja diferença de conteúdo é clara costumam ser separadas mais rápido.
• Pra acelerar, use Solicitar indexação na Inspeção de URL. Existe um limite diário de pedidos, então guarde pras URLs mais importantes.
• No relatório, abra o motivo e clique em Validar a correção. A validação costuma levar até cerca de duas semanas, às vezes mais. Pra "Página alternativa com tag canônica adequada" e para cópias que estão certas, não há o que validar: elas continuam no relatório, e isso é o esperado.

Não espere o número chegar a zero. Todo site tem variantes com parâmetro, versões antigas e duplicatas legítimas, e elas vão continuar aparecendo como não indexadas. O que importa é que as páginas que você quer no Google estejam em "URL canônico selecionado pelo Google" apontando pra si mesmas. A varredura grátis da Varrida confere o canonical de cada página da amostra e avisa quando ele falta ou aponta pra outra URL.