Um site criado por IA pode entregar a mesma página em mais de um endereço: com e sem barra final, em um domínio temporário e no domínio oficial, com parâmetros de campanha ou por rotas que apontam para o mesmo arquivo. Se o template também herdou uma tag canonical de outro projeto, a página publicada pode declarar como preferida uma URL que nem pertence ao site.

Revisar canonical não é apenas procurar uma linha no <head>. É decidir qual URL representa cada conteúdo, alinhar os sinais técnicos e confirmar o HTML servido na versão que está no ar.

Este guia organiza essa revisão da fonte à URL publicada, sem tratar canonical como redirecionamento nem prometer que uma tag isolada controla a indexação.

O que uma URL canônica resolve

Quando várias URLs têm conteúdo igual ou muito parecido, mecanismos de busca tentam escolher uma versão representativa. A documentação do Google sobre URLs canônicas explica que rel="canonical", redirecionamentos e inclusão em sitemap são sinais para consolidar URLs duplicadas.

No HTML, a indicação costuma aparecer assim:

<link rel="canonical" href="https://www.exemplo.com/servicos/" />

Ela informa a URL preferida para aquela página. Não transporta o visitante, não protege conteúdo e não garante que o mecanismo de busca aceitará a escolha. Se a página canônica contradiz outros sinais ou não está acessível, outro endereço pode ser selecionado.

Separe os mecanismos:

Recurso Função principal
canonical indicar a versão preferida entre URLs semelhantes
redirecionamento levar navegador e crawler de uma URL para outra
noindex pedir que uma página não apareça no índice
robots.txt controlar rastreamento de caminhos por crawlers
sitemap apresentar URLs que o site quer ajudar a descobrir

Misturar essas funções cria configurações difíceis de diagnosticar.

Comece por um inventário de URLs

Antes de editar tags, registre as rotas que podem entregar cada conteúdo:

conteúdo: página de serviços
URL oficial: https://www.exemplo.com/servicos/
outras URLs encontradas:
- https://exemplo.com/servicos/
- https://www.exemplo.com/servicos
- https://www.exemplo.com/servicos/?utm_source=campanha
- https://projeto.sitenoar.dev/servicos/
destino desejado para pessoas:
URL canônica declarada hoje:

Nem toda variação precisa de uma tag diferente. Parâmetros de Analytics podem continuar chegando à mesma página enquanto o canonical aponta para a versão limpa. Já uma versão temporária e um domínio próprio exigem uma decisão explícita sobre qual endereço é oficial.

Inclua no inventário:

  • protocolo e hostname;
  • presença de www, quando aplicável;
  • barra final;
  • letras maiúsculas e minúsculas;
  • parâmetros;
  • versões de homologação ou demonstração;
  • páginas parecidas que deveriam continuar independentes.

Não consolide duas páginas só porque o layout é semelhante. Se elas atendem intenções, regiões ou ofertas diferentes, a decisão editorial vem antes do código.

Defina a URL preferida antes de gerar a tag

Uma canonical útil deve apontar para uma URL:

  • absoluta, incluindo https:// e hostname;
  • acessível e estável;
  • coerente com o domínio que a equipe divulga;
  • correspondente ao conteúdo daquela página;
  • sem parâmetros descartáveis;
  • incluída nos links internos e no sitemap, quando existe.

Evite gerar o hostname a partir de uma variável ausente e cair silenciosamente em localhost, domínio de preview ou endereço de outro cliente. Em sites gerados por IA, revise também constantes copiadas de templates, layouts compartilhados e fallbacks do framework.

Se o domínio oficial ainda não foi decidido, não invente um valor apenas para eliminar um alerta. Registre a pendência e confirme o destino com quem controla a publicação.

Procure a fonte real do canonical

A tag pode ser definida diretamente no HTML ou produzida por layout, componente de SEO, gerador estático, CMS ou configuração global. Localize a origem antes de alterar a saída compilada.

Uma busca inicial pode usar:

Terminal window
rg -n 'rel=.canonical|canonicalURL|siteUrl|baseUrl' src public .

Depois, compare três camadas:

  1. valor configurado na fonte;
  2. valor presente no HTML da build;
  3. valor entregue pela URL publicada.

Corrigir apenas a pasta de saída perde a mudança na próxima build. Corrigir apenas a fonte sem regenerar e republicar deixa a URL antiga no ar.

Use canonical autorreferente com consistência

Em geral, cada página indexável pode declarar a própria URL preferida, inclusive quando não há uma duplicata óbvia. Isso torna a intenção explícita e reduz variações acidentais entre templates.

Para uma estrutura multipágina:

/servicos/
<!-- / -->
<link rel="canonical" href="https://www.exemplo.com/" />


<link rel="canonical" href="https://www.exemplo.com/servicos/" />

Não faça todas as páginas apontarem para a home. Esse atalho afirma que conteúdos diferentes seriam duplicados e remove a identidade das rotas internas.

Também evite canonical encadeado: página A aponta para B e B aponta para C. Faça as versões alternativas apontarem diretamente para a URL final escolhida.

Alinhe os outros sinais

Canonical funciona melhor quando a arquitetura conta a mesma história.

Menus, breadcrumbs, CTAs e links de conteúdo devem preferir a URL canônica. Se metade do site usa uma versão com barra e a outra metade usa outra forma, o próprio site produz sinais divergentes.

Sitemap

Liste URLs canônicas, não todas as variações encontradas. O guia de sitemap e robots.txt para sites criados por IA mostra como revisar esse arquivo junto com as regras de rastreamento.

Redirecionamentos

Quando uma URL antiga não deve mais ser usada por visitantes, um redirecionamento permanente pode ser mais adequado que apenas uma canonical. Preserve a equivalência: não envie dezenas de páginas removidas para uma home sem relação.

Domínio próprio

Depois que um Custom Domain se torna o endereço oficial, revise canonical, links absolutos, Open Graph e sitemap. A documentação de Domínios próprios cobre configuração, verificação e SSL; ela não reescreve automaticamente valores fixos dentro dos arquivos do seu site.

Teste a build, não apenas o componente

Gere a saída publicável e inspecione todas as páginas HTML. Uma verificação simples pode listar os valores finais:

Terminal window
rg -n '<link[^>]+rel="canonical"' dist -g '*.html'

Para cada rota, confirme:

  • existe no máximo uma tag canonical válida;
  • o href é absoluto;
  • o hostname é o aprovado;
  • o caminho corresponde à página;
  • não há valor de preview, localhost ou placeholder;
  • a URL de destino faz parte do pacote ou do domínio esperado.

Se a aplicação injeta metadados no cliente, lembre que o HTML inicial pode não conter a indicação. Prefira gerar o canonical no documento entregue, de acordo com a arquitetura do projeto.

Publique e confira o HTML servido

O contrato de Publicação transforma a saída estática em Pages e assets. Antes do deploy, confirme index.html na raiz do pacote e as demais rotas no caminho esperado.

Depois do deploy:

  1. abra a URL canônica e pelo menos uma rota interna;
  2. inspecione o HTML retornado, não apenas o DOM depois do JavaScript;
  3. confira status, hostname, caminho e canonical;
  4. teste variações que deveriam redirecionar;
  5. verifique se links internos usam o endereço preferido;
  6. registre o Site ID, versão e URLs testadas.

Se encontrar um valor errado, corrija a fonte e republique o mesmo Site. Criar outro Site para corrigir metadata introduz mais uma URL no problema.

Peça uma revisão segura ao agente

Um pedido fechado evita que o agente escolha domínios ou consolide páginas por conta própria:

Revise as URLs canônicas deste site sem publicar alterações ainda.


Domínio oficial: [domínio aprovado]
Rotas que devem ser indexáveis: [lista]
Rotas de preview ou alternativas: [lista]


Retorne por página:
- URL esperada;
- canonical encontrado na fonte e na build;
- divergências com links internos, redirects e sitemap;
- arquivo que controla o valor;
- correção proposta.


Não invente domínio, não una conteúdos diferentes e não altere copy.
Depois da aprovação, corrija a fonte, gere a build e mostre o diff.

Após publicar, complete com a auditoria SEO do Site no Ar. A auditoria encontra canonical incorreto na versão ativa, mas a decisão sobre qual URL é oficial continua pertencendo ao projeto.

Checklist final de canonical

Antes de divulgar a URL:

  • domínio oficial confirmado;
  • uma URL preferida definida por conteúdo;
  • canonical absoluto e correspondente à rota;
  • nenhuma referência a preview, template ou localhost;
  • links internos e sitemap usam as URLs preferidas;
  • redirecionamentos testados separadamente;
  • build inspecionada;
  • HTML publicado conferido;
  • correções republicadas no mesmo Site;
  • evidências registradas por URL e versão.

Uma canonical correta não nasce de uma tag copiada. Ela fecha um acordo entre conteúdo, domínio, rotas, build e publicação. Quando esses sinais convergem, o site deixa claro qual endereço deve representar cada página — para crawlers, para a equipe e para a próxima atualização feita pelo agente.