Idiomas

Tag canonical para SEO

Como implementar rel=canonical corretamente — o elemento de link HTML, o cabeçalho HTTP Link para PDFs, URLs absolutas, um por página — e onde as pessoas erram.

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

Uma tag canonical (rel=canonical) informa aos mecanismos de busca qual URL é a versão preferida de um conteúdo duplicado. É uma sinalização, não uma diretiva — um sinal forte que o Google pode ignorar. Métodos válidos: o elemento HTML <link rel="canonical"> no <head> (nunca no <body>), o cabeçalho HTTP Link (a forma de canonicalizar PDFs e outros recursos que não são HTML) e a inclusão no sitemap como sinal mais fraco. Declare uma relação canonical inequívoca por página; declarações múltiplas ou conflitantes podem produzir resultados inesperados, portanto não afirme que um mecanismo escolhe deterministicamente a primeira ou a última. Use URLs absolutas e faça autorreferência nas páginas preferidas. Não canonicalize páginas paginadas para a página 1 e não combine canonical com noindex ou um bloqueio em robots.txt — esses sinais entram em conflito. Teste a resposta bruta, o DOM renderizado, os cabeçalhos da resposta e a canonical declarada pelo usuário versus a selecionada pelo Google no Search Console.

TL;DR — rel=canonical é uma sugestão, não uma regra — um sinal forte que o Google pode substituir, e de fato substitui. Métodos válidos de declaração: o HTML <link rel="canonical"> no <head> (no <body>, ele é desconsiderado), o cabeçalho HTTP Link: rel="canonical" (a única forma de canonicalizar PDFs e outros arquivos que não são HTML) e a inclusão no sitemap como sinal mais fraco. Use exatamente uma canonical inequívoca por página — declarações múltiplas ou conflitantes podem produzir resultados inesperados. Use URLs absolutas, faça autorreferência nas páginas preferidas e não canonicalize uma série paginada para a página 1. Não combine canonical com noindex, bloqueio em robots.txt ou 4XX — cada um pode impedir o Google de ler ou respeitar a tag. Teste comparando o código-fonte com o DOM renderizado, use curl -I para o cabeçalho e confira a inspeção de URL do GSC (canonical declarada pelo usuário versus escolhida pelo Google).

Uma canonical é uma declaração, não uma decisão

Mantenha duas ideias separadas. Canonicalização é o processo pelo qual o Google escolhe uma URL representativa dentro de um conjunto de duplicatas — ele pesa muitos sinais para isso. A tag canonical é apenas um desses sinais: sua preferência declarada. Esta página trata de como declará-la corretamente; o processo de seleção em si está no hub de canonicalização.

Essa distinção é a espinha dorsal da precisão deste texto, porque o Google é explícito: “indicating a canonical preference is a hint, not a rule.” É uma sugestão forte — como explico no meu guia aprofundado de canonicalização, a canonical é “considered a strong signal,” e “Google ignores it if other signals are stronger.” Mas ela nunca é uma diretiva. Se você declara a URL A como canonical enquanto seus links internos, sitemap e redirecionamentos apontam para a URL B, o Google pode escolher B. (Esse é o estado “Duplicate, Google chose a different canonical than user” que você verá no Search Console.) Evidence for this claim Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Scope: Google Search canonical selection; applies to duplicate or very similar pages. Confidence: high · Verified: Google: URL canonicalization

Três maneiras sem redirecionamento de declarar uma canonical

Além dos redirecionamentos, o Google documenta três maneiras sem redirecionamento de indicar uma canonical, e elas têm forças diferentes: Evidence for this claim Alongside redirects, Google documents three non-redirect ways to indicate a canonical: an HTML link element, an HTTP Link header, and sitemap inclusion. Scope: The three non-redirect canonical declaration approaches covered in this article; Google also documents redirects as a canonicalization method. Confidence: high · Verified: Google: Specify a canonical URL

  • HTML <link rel="canonical"> no <head> — “A strong signal that the specified URL should become canonical.” Este é o método cotidiano para páginas HTML.
  • Cabeçalho de resposta HTTP Link: rel="canonical" — para documentos nos quais não é possível inserir um elemento <link>. O Google diz que você pode “use a link HTTP response header with a rel=“canonical” target attribute as defined by RFC5988 rather than an HTML element to indicate the canonical URL for a document supported by Search, including non-HTML documents such as PDF files.” O método HTML “Only works for HTML pages, not for files such as PDF. In such cases, you can use the rel=“canonical” HTTP header.” Essa é a resposta para “como canonicalizo um PDF?”
  • Inclusão no sitemap — “A weak signal that helps the URLs that are included in a sitemap become canonical.” É um sinal real, mas o mais fraco dos três.

Duas coisas merecem atenção sobre a interação entre eles:

  • Eles se somam. O Google diz: “these methods can stack and thus become more effective when combined.” Uma <link> auto-referente, um sitemap limpo e links internos consistentes apontando para o mesmo caminho são muito mais fortes juntos do que qualquer um isoladamente.
  • Nenhum é obrigatório. “While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference.” Declarar uma canonical remove ambiguidades; não declarar uma não é um erro.

Separadamente, um redirecionamento 301 é um sinal de consolidação ainda mais forte que rel=canonical — mas é uma ferramenta diferente (veja abaixo a comparação entre canonical, 301 e noindex).

Um PDF não tem <head>, portanto não há onde inserir um elemento <link>. A correção é enviar a canonical no cabeçalho de resposta HTTP, no nível do servidor. O formato é:

Link: <https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"

Você configura isso no servidor (Apache .htaccess, Nginx) ou na CDN/edge — consulte a aba Scripts para snippets funcionais de Apache e Nginx e o comando curl -I para confirmar que o cabeçalho está sendo realmente enviado. O método do cabeçalho também funciona para HTML, mas, nesse caso, o elemento <link> é mais simples; use o cabeçalho quando não houver marcação para editar (PDFs, imagens e outros arquivos que não são HTML).

Ela precisa estar no <head> — a armadilha da posição no body

Este é o modo de falha que mais prejudica as pessoas e quase sempre acontece por acidente. O Google diz: “The rel=“canonical” link element is only accepted if it appears in the <head> section of the HTML, so make sure at least the <head> section is valid HTML.” E a publicação de 2013 sobre “5 common mistakes” continua sendo a formulação mais clara: “When we encounter a rel=canonical designation in the <body>, it’s disregarded.” A frase final resume a regra: “rel=canonical designations in the <head> are processed, not the <body>.” Evidence for this claim Google accepts an HTML rel=canonical link element only in a valid head section and disregards a canonical placed in the body. Scope: HTML link-element canonicals in Google Search; HTTP-header canonicals are a separate method. Confidence: high · Verified: Google: Common rel=canonical mistakes

A armadilha é esta: você escreveu a canonical no <head> do código-fonte. Mas, quando a página é construída no navegador ou renderizada pelo mecanismo de busca, o <head> pode terminar cedo — tags não fechadas, JavaScript injetado no head ou um <iframe> dentro dele podem fechá-lo prematuramente. A canonical então cai no <body> renderizado, onde é ignorada. Descrevi exatamente isso no meu guia de SEO para JavaScript: situações como “unclosed tags, JavaScript injected” podem fazer o <head> terminar antes da hora e jogar a canonical no <body> de uma página renderizada “where it will not be respected.”

O problema é invisível no view-source — o HTML bruto parece correto. Você precisa comparar o HTML bruto com o DOM renderizado (painel Elements do DevTools ou o HTML renderizado da inspeção de URL do GSC) para descobrir onde a canonical foi parar.

Sobre JavaScript: a orientação do Google é escolher um método e não criar conflito. “If you can’t set the canonical URL in the HTML source code, leave it out and only set it with JavaScript.” Se o JS injeta a canonical, confirme que a insere corretamente no <head> — não faça também o servidor renderizar uma segunda canonical diferente.

Declare uma relação canonical por página

Deve haver uma relação canonical inequívoca por página. A orientação atual do Google sobre métodos de canonical alerta que combinar métodos pode produzir erros e resultados inesperados; ela não define um vencedor determinístico pela primeira ou pela última tag. Uma publicação do Google Search Central de 2013 disse que declarações múltiplas provavelmente seriam ignoradas. Trate isso como contexto histórico de troubleshooting, não como um contrato eterno de parser determinístico: a conclusão segura hoje é sinalizar o conflito, expor cada declaração HTML e HTTP e corrigir o template.

A causa usual não é um erro de digitação; é o empilhamento de sistemas. O CMS injeta uma, o tema injeta outra e um plugin de SEO injeta uma terceira — três declarações conflitantes. Sinalizei esse padrão diretamente no meu guia aprofundado de canonicalização: várias tags rel=canonical provavelmente serão ignoradas, e “in many cases this happens because tags are inserted into a system at different points such as by the CMS, the theme, and plugin(s).” Se você está depurando uma canonical que “isn’t working”, conte as tags no DOM renderizado primeiro.

Use URLs absolutas, não relativas

O Google diz: “Use absolute paths rather than relative paths with the rel=“canonical” link element. Even though relative paths are supported by Google, they can cause problems in the long run.” A razão é mecânica — um <link> aceita URLs relativas e absolutas, e um href relativo como /page/ é resolvido contra a URL atual. Com uma base malformada ou um caminho inesperado, ele pode resolver para um lugar que você não pretendia. Escreva sempre a URL totalmente qualificada:

<!-- Good -->
<link rel="canonical" href="https://www.example.com/dresses/green/green-dress.html">

<!-- Bad: relative path -->
<link rel="canonical" href="/dresses/green/green-dress.html">

A mesma lógica vale para host e protocolo: aponte para a versão real e final (https:// em vez de http://, no host canonical). E não use um fragmento de URL como canonical — “Google generally doesn’t support URL fragments.”

Canonicals auto-referentes e paginação

Uma página nomear a si mesma como canonical é aceitável e recomendado para a versão preferida — isso torna sua intenção inequívoca quando os outros sinais não estão todos alinhados. Quando uma verificação diz que a página tem “no different canonical”, uma canonical auto-referente satisfaz essa condição: é uma declaração permitida para a mesma URL, não um destino concorrente.

A paginação é onde a autorreferência mais importa e onde as pessoas mais erram. Não canonicalize as páginas 2, 3, 4… de uma série de volta para a página 1. “Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical.” A página 2 não é uma duplicata da página 1 — tem conteúdo diferente. Em vez disso, “self-referencing canonicals should be used on all paginated pages”: cada página é sua própria canonical.

Outro erro de canonicalização excessiva: uma página de categoria ou landing page que aponta sua canonical para um único artigo em destaque. A categoria e o artigo não têm o mesmo conteúdo, portanto isso também é uso indevido.

Não quebre a visibilidade da canonical — e não a aponte para um destino quebrado

Uma canonical só funciona se o Google puder rastrear a página, ler a tag e não encontrar uma instrução contraditória. Esse é um problema de saúde do lado da origem — trata-se de saber se o Google consegue sequer ver a tag na URL duplicada. Há três maneiras de as pessoas derrotarem a própria canonical assim:

  • Bloquear a URL canonicalizada no robots.txt. Se você usar Disallow na duplicata, o Google não poderá rastreá-la, nunca verá a canonical nela e não poderá transmitir a consolidação. (O Google acrescenta que uma URL bloqueada por robots.txt “may still index URLs that are disallowed in robots.txt without their content.” Não use robots.txt para canonicalização.)
  • Definir noindex na URL canonicalizada. São instruções contraditórias: noindex diz “remova esta página” e canonical diz “consolide esta página”. Não misture as duas — escolha com base na intenção.
  • Retornar 4XX na URL canonicalizada. O efeito é o mesmo de noindex: o Google não consegue ler a tag e não consegue transferir a consolidação.

E não declare canonicals conflitantes entre métodos: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques” — por exemplo, uma URL no sitemap e outra em rel=canonical.

Há um problema separado de saúde do lado do destino que as pessoas deixam passar porque aponta na direção oposta: a URL para a qual você aponta precisa ser um destino limpo. A RFC 6596 recomenda evitar um destino que seja ele próprio a origem de um redirecionamento, que leve por uma cadeia a outra canonical ou que retorne um código de erro — e a checklist de verificação do próprio Google acrescenta que o destino não deve carregar uma tag noindex. Uma canonical apontada para um destino que redireciona, encadeia, é noindex ou retorna erro pede que o Google consolide em uma URL que não consegue servir como página representativa — trate “does the target return a clean 200 with no redirect, no noindex, and no different canonical target of its own” como uma verificação própria, separada de saber se a página de origem pode ser rastreada.

Se você usa hreflang, a canonical precisa apontar para uma página no mesmo idioma: “specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn’t exist for the same language.”

Canonical versus redirecionamento 301 versus noindex

Eles costumam ser tratados como intercambiáveis. Não são — veja a tabela de decisão na aba Folhas de consulta. A versão curta é:

  • rel=canonical — as duas URLs continuam ativas e rastreáveis; você expressa uma preferência e o Google consolida os sinais na escolhida. É uma sugestão. Use quando as duas URLs precisam continuar acessíveis e são duplicatas reais ou quase duplicatas (parâmetros, versões para impressão) — não como correção geral para conteúdo distribuído; veja abaixo.
  • Redirecionamento 301 — usuários e bots são movidos para o destino; é o sinal de consolidação mais forte. Use quando a duplicata não deve ser acessível de forma alguma.
  • noindex — uma diretiva que remove uma página da busca (ela precisa continuar rastreável para que o Google veja a diretiva). Use para remover, não para consolidar.

A preferência do próprio Google para duplicatas dentro do site é a canonical: “We don’t recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search. rel=“canonical” link annotations are the preferred solution.” Evidence for this claim Google recommends rel=canonical rather than noindex when the goal is selecting a canonical within one site, because noindex removes the page from Search. Scope: Google Search guidance for duplicate pages within a single site. Confidence: high · Verified: Google: Specify a canonical URL

Por que uma canonical é ignorada

Quando o Google escolhe uma canonical diferente da que você declarou, quase sempre é por um destes motivos: as duas URLs não têm realmente o mesmo conteúdo; você tem canonicals múltiplas ou conflitantes; a tag está no body; a URL é relativa ou quebrada; a URL está bloqueada por robots ou retorna 4XX; ou sinais mais fortes (links internos, sitemap e redirecionamentos) apontam para outro lugar.

O caso de conteúdo que “não é realmente o mesmo” atinge com mais força sites renderizados por JS. John Mueller diz: “With JavaScript based sites, the content side is a common reason for this: for example, if you’re using a SPA-type setup where the static HTML is mostly the same, and JavaScript has to be run in order to see any of the unique content, then if that JS can’t be executed properly, then the content ends up looking the same.” Se o Google não consegue ver o conteúdo exclusivo, não consegue distinguir suas duplicatas — e pode consolidá-las ou separá-las de um modo que você não pretendia.

O Bing trata rel=canonical da mesma forma — um sinal de clareza, não uma solução universal — e recomenda explicitamente seu uso para conteúdo distribuído (peça ao parceiro que aponte a canonical para o original). Essa é uma divergência real em relação ao Google: a orientação atual de troubleshooting do Google diz que “the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different.” Evidence for this claim Google's current troubleshooting guidance does not recommend rel=canonical as the general fix for duplication by syndication partners, because syndicated pages are often materially different from the original. Scope: Google Search guidance for syndicated-content duplication; canonical remains valid where the syndicated copy is a genuine duplicate or superset of the original. Confidence: high · Verified: Google: Fix canonicalization issues Para esse problema específico, a correção do Google é pedir ao parceiro de distribuição que bloqueie a cópia dele de ser indexada — não usar uma canonical — porque ela só funciona quando o destino tem de fato o mesmo conteúdo, e cópias distribuídas muitas vezes não são próximas o bastante. Na caixa de ferramentas, o enquadramento do Bing é que “Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” Uma divergência importante: para duplicatas por parâmetro, o Bing também oferece URL Normalization no Bing Webmaster Tools como correção preferida.

Como testar

O fluxo numerado está na aba Checklists; os comandos estão em Scripts. O essencial é:

  1. View-source da página — existe exatamente um <link rel="canonical">, no <head>, com uma URL absoluta?
  2. Compare com o DOM renderizado (DevTools / HTML renderizado do GSC) — ele permaneceu no <head> e continua sendo o único depois da renderização?
  3. curl -I na URL para o cabeçalho HTTP Link: rel="canonical" (é assim que você verifica PDFs e recursos que não são HTML).
  4. Inspeção de URL do GSC — compare a canonical declarada pelo usuário com a canonical escolhida pelo Google. Uma divergência é o sinal para investigar o motivo. Duas ressalvas: o resultado indexado pode atrasar o que está acontecendo por horas, e o teste ao vivo só confirma que a URL pode ser buscada agora — não prevê qual URL o Google escolherá como canonical.
  5. Rastreie o site (Ahrefs Site Audit, gratuito pelo Ahrefs Webmaster Tools para sites verificados, ou Screaming Frog) para encontrar problemas de canonical em escala.

Para o tema mais amplo — como o Google realmente escolhe uma canonical entre cerca de 40 sinais — veja o hub de canonicalização. Questões irmãs, como conteúdo duplicado e parâmetros de URL, são os motivos habituais para você recorrer a uma canonical.

Add an expert note

Pin an expert quote

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