Robots.txt, sitemap e canonical: o trio da indexação

Como o Google descobre e indexa páginas

Antes de uma página aparecer na busca, ela passa por três etapas bem distintas — e quase todo problema de "minha página não aparece no Google" mora na confusão entre elas:

1. Descoberta (crawling): o Googlebot encontra a URL, seja seguindo um link de outra página, seja lendo um sitemap.
2. Renderização: o robô baixa o HTML, executa o JavaScript e monta a página como um navegador faria.
3. Indexação: o conteúdo é analisado e, se passar nos critérios de qualidade, entra no índice — o banco de dados gigante de onde a busca puxa os resultados.

Cada etapa tem seu próprio controle. O robots.txt mexe na primeira (descoberta). A tag noindex mexe na terceira (indexação). O canonical diz qual versão de uma página, entre várias parecidas, deve representar todas. E o sitemap ajuda na descoberta, entregando a lista de URLs de bandeja. Os três que dão título a este guia — robots.txt, sitemap e canonical — são justamente as ferramentas que você controla diretamente em cada uma dessas frentes.

Vale guardar um conceito: crawl budget, o "orçamento de rastreamento". O Google não tem tempo infinito para visitar seu site. Em sites pequenos isso raramente importa, mas em portais com dezenas de milhares de URLs, deixar o robô perder tempo em páginas inúteis (filtros, ordenações, busca interna) significa menos visitas às páginas que importam. Os três arquivos abaixo são, no fundo, como você direciona essa atenção.

robots.txt: o que ele faz (e o que não faz)

O robots.txt é um arquivo de texto puro que vive na raiz do domínio — sempre em https://seusite.com/robots.txt, nunca em uma subpasta. Ele dá instruções de rastreamento aos robôs: "pode entrar aqui", "não entre ali". A sintaxe é enxuta:

Aqui está a parte que confunde quase todo mundo: robots.txt impede o rastreamento, não a indexação. São coisas diferentes. Se você bloqueia /promo com Disallow, mas outro site linka para essa URL, o Google ainda pode listá-la nos resultados — só que sem descrição, com aquele aviso "não há informações disponíveis para esta página". O robô obedeceu e não entrou, mas a URL existe e foi indexada mesmo assim.

Outros detalhes que pegam: o robots.txt é sensível a maiúsculas nos caminhos, aceita os curingas * (qualquer sequência) e $ (fim da URL), e é um arquivo público — qualquer um lê o seu. Nunca liste lá um caminho secreto achando que está escondendo algo; você está fazendo o contrário, apontando para ele. Para montar o arquivo sem errar a indentação ou esquecer a linha do sitemap, o Gerador de robots.txt monta a estrutura a partir das regras que você escolhe.

Sitemap XML: dando um mapa ao rastreador

Se o robots.txt diz "por onde não passar", o sitemap XML diz "olha tudo o que existe aqui". É uma lista, em XML, das URLs que você quer que sejam descobertas. Especialmente útil para páginas novas, profundas (a muitos cliques da home) ou pouco linkadas internamente. O formato é simples:

• <loc> — a URL completa e canônica da página (obrigatório).
• <lastmod> — data da última modificação, no formato ISO 8601 (2026-06-30). O Google usa este campo se ele for honesto e consistente.
• <changefreq> e <priority> — frequência e prioridade. O Google declarou que ignora os dois; pode preencher, mas não espere efeito.

Há limites técnicos: cada arquivo de sitemap comporta no máximo 50.000 URLs ou 50 MB (descompactado), o que vier primeiro. Site maior que isso? Você quebra em vários sitemaps e cria um sitemap index, um sitemap que aponta para os outros. Toda URL listada deve responder com status 200, ser a versão canônica e não estar bloqueada no robots.txt — sitemap e robots.txt se contradizendo é sinal misto que confunde o rastreador.

Para o Google encontrar o arquivo, há dois caminhos: declarar a linha Sitemap: no robots.txt e/ou enviá-lo pelo Google Search Console (o antigo "ping" por URL foi desativado em 2023). O Gerador de Sitemap XML monta o <urlset> já com o cabeçalho e os campos certos a partir da sua lista de URLs.

Canonical: resolvendo conteúdo duplicado

A mesma página costuma ser acessível por várias URLs sem você perceber. Veja como estas quatro podem servir o mesmo conteúdo:

• https://loja.com/tenis
• https://loja.com/tenis/ (com barra no fim)
• https://loja.com/tenis?cor=preto&utm_source=email
• http://www.loja.com/tenis (http e www)

Para o Google, são quatro URLs diferentes com conteúdo praticamente igual. Isso dilui sinais: os links e a autoridade que deveriam reforçar uma página se espalham entre as variações. A solução é a tag <link rel="canonical" href="..."> no <head>, apontando todas as variantes para a versão "oficial". É como dizer: "esta aqui é a original; consolide tudo nela".

Dois pontos importantes. Primeiro, toda página deveria ter um canonical auto-referente — apontando para si mesma na forma limpa — mesmo quando não há duplicação aparente; isso protege contra parâmetros de rastreamento e cópias. Segundo, o canonical é uma dica, não uma ordem: o Google pondera o sinal junto com outros (links internos, sitemap, redirecionamentos) e, se eles se contradisserem, pode escolher um canônico diferente do que você indicou. Mantenha todos os sinais coerentes. O Gerador de URL Canônica monta a tag já normalizada, sem os parâmetros que não deveriam entrar na versão oficial.

hreflang para sites em mais de um idioma

Se o seu site tem versões em português e inglês — como este aqui, com /ferramentas e /en/tools — o hreflang diz ao Google qual versão mostrar para cada público, evitando que a página em inglês apareça para quem busca em português (e vice-versa). A anotação fica no <head>:

• <link rel="alternate" hreflang="pt-BR" href="https://site.com/ferramentas/x">
• <link rel="alternate" hreflang="en" href="https://site.com/en/tools/x">
• <link rel="alternate" hreflang="x-default" href="https://site.com/ferramentas/x">

Três regras que, se quebradas, fazem o hreflang ser ignorado em silêncio: o código de idioma segue o ISO 639-1 (pt, en) e, opcionalmente, a região em ISO 3166-1 (pt-BR, en-US); as referências precisam ser recíprocas — se A aponta para B, B tem que apontar de volta para A, e cada página deve listar a si mesma; e o x-default marca a versão de fallback para idiomas não cobertos. Como o erro de reciprocidade é o mais comum, gerar as tags de um bloco só ajuda — o Gerador de hreflang produz o conjunto completo e simétrico para cada par de URLs.

Perguntas frequentes

Bloquear uma página no robots.txt a tira do Google?

Não de forma confiável. O robots.txt impede o rastreamento, mas uma URL bloqueada ainda pode ser indexada se houver links apontando para ela — aparecendo nos resultados sem título nem descrição. Para remover do índice, use a meta tag noindex e deixe a página rastreável, para que o Googlebot consiga ler a instrução.

Preciso de sitemap se meu site é pequeno?

Não é obrigatório. Sites pequenos e bem linkados internamente são descobertos sem dificuldade. Mas o sitemap não atrapalha e ajuda em três casos: páginas novas, páginas profundas e conteúdo pouco linkado. Como custa quase nada manter, vale ter.

O canonical garante que o Google vai escolher a URL que indiquei?

Não. O canonical é um sinal forte, mas é uma sugestão. O Google cruza esse sinal com links internos, redirecionamentos e o sitemap. Se tudo apontar na mesma direção, ele costuma respeitar; se houver contradição, pode eleger outra URL como canônica. Mantenha os sinais coerentes.

Posso usar o mesmo sitemap para listar as versões em vários idiomas?

Pode, e é uma alternativa válida ao hreflang no HTML: o sitemap aceita anotações xhtml:link que declaram as versões alternativas de cada URL. O importante é não misturar os dois métodos de forma inconsistente — escolha colocar o hreflang no <head> ou no sitemap, e mantenha a reciprocidade.

Com que frequência o Google relê esses arquivos?

Não há um número fixo. O robots.txt costuma ser buscado a cada 24 horas (ou menos, em sites muito ativos); sitemaps são reprocessados conforme o Google rastreia o site. Mudanças importantes — como liberar um diretório antes bloqueado — podem levar de horas a alguns dias para surtir efeito no índice.