Idiomas

Canonicalização

Como os mecanismos de busca escolhem uma URL canônica entre duplicatas e consolidam nela os sinais de ranqueamento — por que rel=canonical é uma sugestão, não uma regra, e como alinhar todos os sinais.

Publicado pela primeira vez: 23 de jun. de 2026 · Última atualização: 8 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
1 sinal de evidência nesta página

Canonicalização é como um mecanismo de busca escolhe uma URL representativa quando várias entregam o mesmo conteúdo ou quase o mesmo, e depois consolida nela sinais como links, PageRank e texto âncora. O ponto mais importante: rel=canonical é uma sugestão, não uma regra — o Google agrupa duplicatas e escolhe uma canonical usando sinais como a anotação rel=canonical, redirecionamentos, sitemap, links internos, HTTPS e formato da URL. Ele pode substituir sua declaração, como no status "Duplicate, Google chose different canonical than user". Canonical não é 301 nem diretiva de indexação como noindex. Faça todos os sinais apontarem para a mesma URL e verifique a escolha na inspeção de URL do Search Console.

TL;DR — Canonicalização é agrupamento + seleção + consolidação: o Google detecta duplicatas (checksums/fingerprints de conteúdo), agrupa-as, escolhe uma canônica e consolida nela os sinais de ranqueamento (links, PageRank e texto âncora). rel="canonical" é uma sugestão forte, não uma diretiva — o Google pode e realmente a substitui, como aparece no GSC: “Duplicate, Google chose different canonical than user”. Ele pesa um conjunto crescente de sinais (~20 segundo Illyes em 2020, ~40 segundo Allan Scott do Google em 2025): anotação rel=canonical, redirecionamentos, presença no sitemap, links internos, HTTPS em vez de HTTP e URLs mais curtas em vez de mais longas — alguns têm mais peso que outros (um redirecionamento supera o sinal de HTTPS). Canonical não é 301 nem diretiva de indexação como noindex. Faça todos os sinais apontarem para uma URL, use canonicals auto-referentes e verifique a canônica escolhida na inspeção de URL do Search Console.

O que canonicalização realmente é

Canonicalization sits between duplicate URLs and the index — deciding which one URL represents the group. Fonte: /technical-seo/how-search-works/indexing/canonicalization/

Three reachable duplicate URL variants feed a canonicalization decision. A separate bundle of signals also feeds the decision: rel=canonical, redirects, sitemap inclusion, internal links, and HTTPS. The decision selects one representative canonical URL, which may be indexed and shown in search while cluster signals consolidate onto it. The other duplicate URLs remain reachable rather than being deleted.

© Patrick Stox LLC · CC BY 4.0 ·

A definição do Google é precisa: “Canonicalization is the process of selecting the representative –canonical– URL of a piece of content,” (canonicalização é o processo de selecionar a URL representativa — canônica — de um conteúdo) e “a canonical URL is the URL of a page that Google chose as the most representative from a set of duplicate pages.” (uma URL canônica é a URL de uma página que o Google escolheu como a mais representativa de um conjunto de páginas duplicadas.) Evidence for this claim Google groups similar pages and selects a representative canonical URL for the cluster. Scope: Google Search canonical selection for duplicate or very similar content. Confidence: high · Verified: Google Search Central: In-depth guide to how Google Search works Escrevi o guia de canonicalização da Ahrefs, e o enquadramento que uso é que há realmente dois trabalhos: “Clustering creates a cluster of duplicate pages, and canonicalization chooses which version signals consolidate to and what page will be shown in search results.” (o agrupamento cria um grupo de páginas duplicadas, e a canonicalização escolhe para qual versão os sinais se consolidam e qual página será mostrada nos resultados.)

Portanto, três coisas acontecem, nesta ordem:

  1. Detectar e agrupar as URLs duplicadas (ou quase duplicadas).
  2. Selecionar uma delas como canônica.
  3. Consolidar os sinais de ranqueamento na URL escolhida.

Entenda esses três passos e a maior parte da confusão sobre canonicalização desaparece.

Por que isso importa

O Google admite que duplicatas são principalmente um problema de usabilidade e relatórios, não uma falha moral: “having the same content accessible through many different URLs can be a bad user experience… and it may make it harder for you to track how your content performs in search results.” (ter o mesmo conteúdo acessível por muitas URLs diferentes pode ser uma experiência ruim e pode dificultar acompanhar o desempenho do conteúdo nos resultados.) A maioria das duplicatas não é maliciosa — são acidentes técnicos comuns: parâmetros, navegação facetada, variantes de protocolo/host e IDs de sessão.

O benefício real aparece em quatro superfícies; vale ser preciso em cada uma, em vez de tratar “canonicalização ajuda SEO” como um benefício vago:

  • Participação no grupo. URLs duplicadas são agrupadas; a canonical é a representante designada.
  • Frequência relativa de rastreamento. O Google diz que rastreia a página canônica com mais regularidade e duplicatas com menos frequência — um efeito relativo que reduz rastreamento redundante. Não é promessa de que canonicalizar uma página liberará instantaneamente orçamento em outro lugar ou acelerará páginas sem relação.
  • Avaliação de conteúdo e qualidade. Normalmente o Google usa a canonical como principal fonte para avaliar qualidade e relevância.
  • O que é servido. Os resultados geralmente apontam para a canonical — mas não sempre. O Google pode servir uma duplicata quando ela se ajusta melhor ao usuário, como uma versão específica para dispositivo.

A documentação do Google descreve o lado dos sinais claramente: declarar uma canonical “helps search engines to be able to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL.” (ajuda os mecanismos a consolidar os sinais das URLs individuais, como links para elas, em uma única URL preferida.) Isso depende de o destino realmente se tornar canônico — não garante que cada canonical declarada absorva automaticamente todo o PageRank, texto âncora ou valor de ranqueamento da duplicata. Se seus sinais divergirem e o Google escolher outra coisa, nada se consolida como você pretendia.

E alguma duplicação é normal — não é, por si só, uma violação de política de spam. Os motivos práticos para canonicalizar são clareza para o usuário, relatórios mais limpos, uma URL de busca consistente, consolidação de sinais e redução de rastreamento duplicado, não medo de penalidade. A duplicação sem controle ainda vale ser corrigida na origem — é mais uma questão de orçamento de rastreamento e navegação facetada do que de canonicalização, embora os temas estejam ligados.

Como o Google escolhe uma canonical

Canonicalization is three jobs, not one: cluster, select, consolidate. Fonte: /technical-seo/how-search-works/indexing/canonicalization/

Step one fingerprints duplicate URLs and groups them into a cluster. Step two selects one URL as canonical while the others remain reachable alternates. Step three consolidates links, PageRank, and anchor text from the cluster onto the selected canonical.

© Patrick Stox LLC · CC BY 4.0 ·

Esta é a parte que muitos guias tratam superficialmente, então vale fazer direito.

Etapa 1 — detecção de duplicatas

O Google cria fingerprints do conteúdo para encontrar duplicatas. Gary Illyes descreveu o mecanismo no Search Off the Record: “A checksum is basically a hash of the content. Basically a fingerprint.” (um checksum é basicamente um hash do conteúdo. Basicamente, um fingerprint.) Páginas com fingerprints iguais ou muito parecidos (elementos repetidos, como navegação e rodapés, têm grande parte do peso descontado) podem ser tratadas como duplicatas.

A documentação atual do Google apresenta a mesma ideia em termos mais simples, sem a mecânica do checksum: durante a indexação, ele compara o conteúdo principal de cada página e agrupa páginas iguais ou muito semelhantes. O Google não publica exatamente como funciona o fingerprinting nem quanto do conteúdo repetido é descontado; trate a explicação de Illyes como uma descrição direcional de uma conversa de 2020, não como um algoritmo documentado.

Etapa 2 — agrupamento

As URLs duplicadas são reunidas em um grupo. Tudo no grupo é candidato a canonical; exatamente uma vencerá.

Etapa 3 — seleção no grupo

Agora o Google escolhe. Ele usa um conjunto de sinais — e a contagem publicada cresceu com o tempo. Em 2020, Illyes disse “we employ, I think, over twenty signals, we use over twenty signals, to decide which page to pick as canonical.” (usamos, acredito, mais de vinte sinais para decidir qual página escolher como canônica.) Em 2025, a contagem mencionada pelo Google é maior: como observei no guia de canonicalização da Ahrefs, “According to Google’s Allan Scott, there are ~40 different canonical selection signals.” (segundo Allan Scott, do Google, há cerca de 40 sinais diferentes de seleção de canonical.) Trate isso como o Google tendo divulgado mais ao longo do tempo — 20+ em 2020 e ~40 em 2025 — não como contradição.

A documentação do Google lista explicitamente alguns: “There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations.” (há alguns fatores que participam da canonicalização: se a página é servida por HTTP ou HTTPS, redirecionamentos, presença da URL em um sitemap e anotações de links rel="canonical".) Minha lista mais completa inclui o restante do que é citado com frequência: duplicatas, elementos de link canonical, URLs de sitemap, links internos e externos, redirecionamentos, hreflang, hreflang x-default, PageRank, páginas HTTPS em vez de HTTP e URLs mais curtas em vez de longas.

Quais sinais têm mais peso

Eles não são iguais. Illyes foi explícito: “301 redirect, or any sort of redirect actually, should be much higher weight… than whether the page is on an http URL or https.” (um redirecionamento 301, ou qualquer redirecionamento, deve ter um peso muito maior do que a página estar em uma URL HTTP ou HTTPS.) E chamou a própria tag canonical de “quite a strong signal” (um sinal bastante forte) — forte, mas pode perder. Como escrevi no meu guia de canonicalização, a tag canonical “is sometimes referred to as a hint because it’s just one canonicalization signal, but it is considered a strong signal. Google ignores it if other signals are stronger.” (às vezes é chamada de sugestão porque é apenas um sinal de canonicalização, mas é considerada forte; o Google a ignora se outros sinais forem mais fortes.)

Por que é uma sugestão, não uma diretiva

Este é o eixo de precisão de todo o tema. Google: “You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.” (você pode indicar sua preferência ao Google usando estas técnicas, mas o Google pode escolher outra página como canonical por vários motivos. Ou seja, indicar uma preferência de canonical é uma sugestão, não uma regra.) Evidence for this claim Canonical declarations express a preference; Google can select a different canonical based on its signals. Scope: Google Search canonicalization; redirects and rel=canonical are strong signals while sitemap inclusion is weaker. Confidence: high · Verified: Google Search Central: How to specify a canonical URL Quando sua canonical declarada perde, você vê no Search Console “Duplicate, Google chose different canonical than user” — o que, como descrevo, “means that Google chose a different URL to index than the one the user selected.” (significa que o Google escolheu uma URL diferente para indexar da selecionada pelo usuário.) A correção quase nunca é “add a stronger tag” (adicionar uma tag mais forte) — é alinhar os sinais conflitantes.

Formas de especificar uma canonical

O Google afirma de início que “none of them are required; your site will likely do just fine without specifying a canonical preference,” (nenhuma é obrigatória; seu site provavelmente funcionará bem sem especificar uma preferência de canonical), mas na prática você deve ser deliberado. A documentação atual também observa que esses métodos podem se somar — usar vários sinais fortes e alinhados aumenta a chance de o Google escolher a URL desejada, embora nenhum isoladamente a garanta. Os principais métodos são:

  • Elemento de link rel="canonical" — a linha no <head>. É o método mais comum; o Google o chama de “a strong signal that the specified URL should become canonical.” (um sinal forte de que a URL especificada deve se tornar canônica.) Ele precisa estar no <head> — uma tag não fechada ou JavaScript que a empurre para o <body> faz o Google ignorá-la. Declare apenas uma por página; declare mais de uma e o Google ignora todas.
  • Cabeçalho HTTP rel="canonical" — para arquivos não HTML (como PDFs), que não têm <head> onde inserir a tag, defina a canonical no cabeçalho da resposta HTTP.
  • Redirecionamentos — “a strong signal that the target of the redirect should become canonical.” (um sinal forte de que o destino do redirecionamento deve se tornar canonical.) Use 301 quando estiver realmente movendo conteúdo.
  • Inclusão no sitemap — “a weak signal that helps the URLs that are included in a sitemap become canonical.” (um sinal fraco que ajuda as URLs incluídas em um sitemap a se tornarem canônicas.) Liste apenas URLs canônicas no sitemap.
  • Links internos — crie links consistentemente para a versão desejada. Links internos inconsistentes são uma das causas mais comuns de conflito entre sinais.

Canonicals auto-referentes e entre domínios

Uma canonical auto-referente — página indexável cuja canonical aponta para ela mesma — é uma boa prática em toda página que você quer indexar. Ela explicita sua preferência mesmo quando outros sinais são ambíguos e neutraliza cópias com parâmetros que, de outra forma, pareceriam duplicatas.

Canonicals entre domínios são compatíveis: você pode apontar a canonical de uma página para uma URL em outro domínio que controla, para consolidar nela (comum em distribuição de conteúdo). O modo de falha a respeitar é o hijacking — como alerto no guia de canonicalização, “In some really bad scenarios, a page on the wrong domain may be shown. This is referred to as hijacking.” (em alguns cenários muito ruins, uma página no domínio errado pode ser exibida. Isso é chamado de hijacking.) É raro, mas por isso canonicals entre domínios exigem cuidado.

Casos-limite: o que realmente conta como duplicata

Cinco situações recebem o rótulo “duplicata” de forma errada mais do que qualquer outra. O padrão é não decidir por uma característica da URL (um ?, número de página, pasta de idioma ou tag de script), mas pelo conteúdo principal efetivamente renderizado.

SituaçãoTratar como duplicata?Por quê
Parâmetros de rastreamento ou sessão (?utm_source=, ?sessionid=)Geralmente simMesmo conteúdo principal — é seguro canonicalizar para a URL limpa.
Parâmetros de filtro, ordenação ou faceta (?color=red, ?sort=price)Não automaticamentePodem produzir conteúdo ou intenção materialmente diferentes da página base — verifique o conteúdo renderizado antes de eliminá-los com canonical.
Páginas paginadas (/page/2/)NãoO Google trata cada página da série como conteúdo principal separado — dê a cada uma delas uma URL única e uma canonical auto-referente; nunca aponte para a página 1.
Páginas totalmente traduzidasNãoConteúdo em outro idioma não é duplicata do original, mesmo quando o template coincide — relacione com hreflang, não canonical.
Variantes regionais no mesmo idioma (por exemplo, páginas quase idênticas en-US e en-GB)Às vezesPodem ser agrupadas como duplicatas comuns. Mantenha a preferência de canonical no mesmo idioma e use hreflang recíproco para que a URL regional correta ainda possa aparecer.

Dois detalhes de implementação causam falhas silenciosas com frequência suficiente para merecer destaque próprio:

  • Canonicals renderizadas por JavaScript. A orientação do Google é escolher uma única fonte clara para o valor: coloque-o no HTML inicial e não o substitua com JavaScript ou — se isso não for possível — deixe-o fora do HTML e defina-o somente por JavaScript. Declarar canonical na origem e alterá-la com script é a falha real: o Google termina com dois sinais conflitantes na mesma página.
  • Arquivos não HTML. O cabeçalho HTTP rel="canonical" (para PDFs, documentos do Word e semelhantes) é aceito especificamente nos resultados da Busca na Web do Google — não é um sinal universal em todas as superfícies do Google. Use uma URL absoluta e não permita que os metadados do arquivo declarem uma canonical conflitante.

Como verificar a canonical escolhida pelo Google

Não presuma que seu HTML é a fonte da verdade — a escolha do Google é. Como digo às pessoas: “Your main source of truth for what Google chose as the canonical will be the URL Inspection tool in Google Search Console. Enter the URL, and it will show what the declared canonical is and what Google chose as the canonical.” (sua principal fonte da verdade sobre a canonical escolhida pelo Google será a ferramenta de inspeção de URL no Google Search Console. Informe a URL e ela mostrará a canonical declarada e a que o Google escolheu.) Se as duas divergirem, esse é o sinal para alinhar tudo.

Alguns limites que vale conhecer antes de tratar esse campo como verdade absoluta:

  • Ele reflete o estado indexado, não uma verificação ao vivo. A canonical escolhida pelo Google na inspeção de URL vem do que o Google já indexou. O Teste ao vivo na mesma ferramenta pode mostrar sinais atuais, mas não prevê a escolha; trate o campo indexado como histórico, não em tempo real.
  • A visibilidade é limitada às propriedades que você possui. Você só vê informações de canonical para URLs dentro de propriedades do Search Console às quais tem acesso, não para páginas arbitrárias de terceiros.
  • Uma ferramenta de auditoria observa entradas, não a decisão do Google. Uma ferramenta como o Canonicalization Checker mostra os sinais enviados — HTML, cabeçalhos e redirecionamentos. Ela não diz qual canonical o Google escolheu; somente a inspeção de URL faz isso.
  • Não há garantia de inclusão, prazo ou ranqueamento. Ter a URL pretendida escolhida como canonical não garante que ela será indexada, que isso ocorrerá em um prazo fixo ou que haverá tráfego ou posições — canonicalização decide a representação, não esses resultados.

Erros comuns de canonicalização

Os recorrentes que vejo (vários da minha própria lista de erros comuns):

  • Usar uma canonical de produção para proteger um site de staging. Uma página de staging em https://staging.example.com/pricing/ pode apontar a canonical para https://example.com/pricing/ e ainda ser rastreada, agrupada ou até exibida enquanto o Google reconcilia os sinais. A canonical diz qual duplicata você prefere; não torna a URL de staging privada nem orienta o Google a removê-la. Se o host de staging escapar para a busca, mantenha-o rastreável com noindex até o Google processar a diretiva, ou redirecione-o se houver uma substituição permanente em produção. Para um ambiente que nunca deve ser público, exija autenticação.
  • Canonicalizar para uma não duplicata. Apontar a canonical de uma página para uma página sem relação informa ao Google que são o mesmo conteúdo; ele pode remover a “duplicata” dos resultados. Canonicals são para duplicatas reais.
  • Canonical + noindex na mesma URL. Instruções contraditórias. A orientação de John Mueller sobre combinar sinais conflitantes é: “I’d just pick one (noindex or followed links). Links on a noindexed page can be picked up, but it’s not guaranteed.” (eu escolheria apenas um — noindex ou links seguidos. Links em uma página noindex podem ser capturados, mas isso não é garantido.) Escolha um.
  • Bloquear a URL canonicalizada em robots.txt. Google: “Don’t use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content.” (não use robots.txt para canonicalização. O Google ainda pode indexar URLs proibidas no robots.txt sem seu conteúdo.) Uma página bloqueada nem pode ser lida para verificar sua tag canonical.
  • Retornar 4XX para a URL canonicalizada — se a duplicata der erro, não resta nada para consolidar os sinais.
  • Canonicalizar todas as páginas paginadas para a página 1. Cada página da série tem conteúdo distinto; não as colapse na raiz.
  • Cadeias de canonicals / redirecionamentos conflitantes — uma canonical apontando para uma URL que depois redireciona força o Google a desfazer uma contradição. Aponte diretamente para o destino final.
  • Várias canonicals ou uma canonical no <body> — a posição no body não é aceita; várias declarações entram em conflito sem um resultado confiável de primeira/última.

Mitos desmentidos

  • “Uma tag canonical garante qual URL ranqueia/indexa.” Não — é uma sugestão; o Google pode escolher outra (é exatamente o que informa o status do GSC “Duplicate, Google chose different canonical than user”).
  • “rel=canonical is the same as a 301 redirect.” (rel=canonical é a mesma coisa que um redirecionamento 301.) Não. 301 é a diretiva para mover uma página; canonical é uma sugestão de consolidação e ambas as URLs continuam acessíveis. A posição de longa data do Bing é que, ao mover conteúdo, você deve usar 301, não canonical, porque o redirecionamento é a instrução inequívoca. Se está aposentando uma URL, redirecione-a.
  • “Uma canonical bloqueia ou permite indexação como noindex.” Não — canonical não é uma diretiva de indexação. Combiná-la com noindex envia sinais conflitantes; use um ou outro.
  • “Mais tags canonical = sinal mais forte.” O contrário: declare mais de uma e o Google ignora todas.

Bing e outros mecanismos

O Bing usa os mesmos elementos básicos. No enquadramento do Bing em dezembro de 2025, “Duplicate content doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems,” (conteúdo duplicado não provoca penalidades de busca por si só, mas reduz a visibilidade ao diluir autoridade, confundir intenção e atrasar a chegada de atualizações aos mecanismos de busca e sistemas de descoberta com IA) e “Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” (tags canonical, redirecionamentos, hreflang, noindex e IndexNow apoiam essa clareza, mas a base é um site simplificado que evita duplicação desnecessária.) O Bing também oferece o recurso URL Normalization no Bing Webmaster Tools para consolidar variantes de parâmetros sem alteração de código — útil quando as duplicatas vêm de parâmetros de URL.

Para onde ir agora

Esta página é o hub conceitual da canonicalização, o tópico pai. Ela fica dentro da etapa mais ampla de indexação de como a busca funciona (canonicalização decide qual URL de um grupo duplicado é efetivamente indexada). Os três aprofundamentos abaixo levam cada parte um passo adiante:

  • Tags canonical (rel=canonical) — a própria tag: sintaxe exata, implementação no <head> versus cabeçalho HTTP, padrões auto-referentes e todas as formas de ser ignorada.
  • Conteúdo duplicado — o que realmente conta como duplicata, por que não é penalidade e como evitá-la na origem em vez de corrigi-la com tags.
  • Parâmetros de URL — o maior gerador de duplicatas: parâmetros de rastreamento, ordenação, filtro e sessão, e como impedir que fragmentem uma página em variantes sem fim.

A canonicalização também toca seus temas irmãos neste grupo: duplicatas e excesso de parâmetros desperdiçam exatamente o orçamento de rastreamento, a navegação facetada é uma grande fonte de URLs quase duplicadas e armadilhas de spider podem gerar os espaços infinitos de URLs que fazem a duplicação explodir. Para o pipeline completo — descoberta, rastreamento, renderização, indexação e entrega — veja o grupo Como a Busca Funciona.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.