Rastreamento e indexação: robots.txt, sitemap e status HTTP

O Google só mostra uma página depois de três etapas: o Googlebot baixa a URL (rastreamento), o Google processa o conteúdo e decide se o guarda no índice (indexação) e, a cada busca, escolhe quais páginas do índice exibir. Quando uma página não entra no índice, os motivos que estão do lado do site são poucos e todos verificáveis: o robots.txt impede o rastreamento, a página tem noindex, a URL canônica aponta para outra página, o servidor não responde 200, o conteúdo parece uma página de erro (soft 404), o conteúdo só aparece depois do JavaScript, ou o Google rastreou e preferiu não indexar. O relatório Indexação de páginas, no Search Console, diz qual desses motivos vale para cada URL.

Escopo: este guia trata do Google Search e se baseia na documentação do Google Search Central e na ajuda do Search Console, consultadas em outubro de 2026. Bing e outros buscadores seguem padrões parecidos (o robots.txt, por exemplo, é padronizado na RFC 9309), mas os comportamentos descritos aqui são os do Google.

Rastreamento, indexação e exibição

O Googlebot é o programa do Google que baixa as páginas. Ele descobre URLs seguindo links de páginas que já conhece e lendo sitemaps. Durante o rastreamento, o Google renderiza a página e executa o JavaScript com uma versão recente do Chrome (Google Search Central, como a Pesquisa funciona).

Na indexação, o Google analisa texto, imagens e vídeos e guarda o resultado no índice. Páginas com conteúdo igual ou parecido formam um grupo, e o Google escolhe uma delas como canônica: a versão que pode aparecer nos resultados.

Na exibição, o Google escolhe entre as páginas indexadas as que considera mais relevantes para a busca. A mesma documentação diz que o Google não garante que vai rastrear, indexar ou exibir uma página e que não aceita pagamento para rastrear mais vezes ou posicionar melhor.

Essa separação ajuda no diagnóstico. Um problema de rastreamento impede o Google de ler a página; um problema de indexação acontece depois que ele leu. Os controles também são diferentes: o robots.txt age no rastreamento, enquanto noindex e canônica agem na indexação. Dados estruturados atuam na exibição, tornando a página elegível a resultados aprimorados como trilha de navegação e preço, e só valem para páginas que o Google consegue rastrear e indexar. As diretrizes de dados estruturados pedem que essas páginas não sejam bloqueadas por robots.txt, noindex ou outro controle de acesso. O artigo sobre dados estruturados trata dessa parte.

robots.txt controla o rastreamento, não a indexação

O robots.txt é um arquivo de texto na raiz do site (https://www.exemplo.com.br/robots.txt) que diz quais caminhos cada robô pode rastrear. As regras valem só para o protocolo, o host e a porta em que o arquivo está publicado (Google, como o Google interpreta o robots.txt).

User-agent: *
Disallow: /carrinho/
Disallow: /busca

Sitemap: https://www.exemplo.com.br/sitemap.xml

O Google descreve o arquivo como uma forma de controlar o tráfego de robôs, para não sobrecarregar o servidor e para evitar o rastreamento de páginas sem importância ou duplicadas. A mesma página avisa que ele não serve para manter uma página fora do Google: uma URL bloqueada ainda pode ser indexada se outras páginas linkarem para ela, só que aparece sem descrição (Google, introdução ao robots.txt). No Search Console, esse caso aparece como "Página indexada, mas bloqueada pelo robots.txt".

Para tirar uma página do índice, o Google indica três caminhos: noindex, senha no servidor ou remover a página. A regra noindex escrita dentro do robots.txt não é suportada pelo Google (Google, bloquear a indexação com noindex).

Um erro no próprio robots.txt pode parar o rastreamento do site inteiro. Se o arquivo responder com erro 5xx, o Google deixa de rastrear o site por 12 horas enquanto tenta buscá-lo de novo. Depois disso, por até 30 dias, usa a última versão boa que tiver em cache. O arquivo também tem limite de 500 KiB; o que passar disso é ignorado. O Google costuma manter o robots.txt em cache por até 24 horas, então uma correção pode levar um dia para valer.

Liberar ou bloquear robôs de IA, como GPTBot e ClaudeBot, também passa pelo robots.txt. O artigo sobre robôs de IA no robots.txt trata dos nomes de cada robô e da diferença entre robôs de busca, de acesso do usuário e de treinamento.

noindex: meta robots e X-Robots-Tag

noindex é a regra que pede ao Google para não mostrar a página nos resultados. Ela pode ir numa meta tag no HTML ou no cabeçalho HTTP X-Robots-Tag, com o mesmo efeito (Google, bloquear a indexação com noindex).

<meta name="robots" content="noindex">

X-Robots-Tag: noindex

O cabeçalho é a forma de aplicar a regra ao que não é HTML, como PDF, imagem e vídeo. Na meta tag, name="robots" vale para todos os buscadores que aceitam a regra e name="googlebot" vale só para o Google.

A armadilha está na combinação com o robots.txt. Para o noindex funcionar, o Google precisa rastrear a página e ler a regra. Se o robots.txt bloqueia a URL, o Googlebot nunca vê o noindex, e a página pode continuar indexada a partir de links de outros sites (Google, especificações da meta tag robots e do X-Robots-Tag). Quem quer tirar uma página do índice precisa deixar o rastreamento liberado até o Google ler o noindex.

Além de noindex, o Google aceita nofollow (não seguir os links da página), none (equivale a noindex e nofollow juntos), nosnippet, max-snippet, max-image-preview, max-video-preview, unavailable_after, indexifembedded, notranslate e noimageindex. Quando duas regras entram em conflito, vale a mais restritiva. noarchive e nocache são ignoradas.

Em sites com JavaScript, o noindex pede um cuidado extra. Se o HTML original tem noindex, o Google pode pular a renderização, e um script que remove a regra depois pode não ter efeito. Se você quer a página indexada, o noindex não pode estar no código original (Google, noções básicas de JavaScript para SEO).

Qualquer mudança nessas regras só vale depois que o Googlebot rastreia a página de novo. Em páginas menos importantes, a documentação diz que isso pode levar meses; a Inspeção de URL permite pedir um novo rastreamento.

Canônica: qual URL de um grupo de duplicatas aparece

Duplicatas são URLs diferentes com o mesmo conteúdo, ou quase o mesmo. Acontece com http e https, com e sem www, com e sem barra no final, com parâmetros de campanha (?utm_source=) e com filtros de loja virtual. O Google agrupa essas URLs e escolhe uma como canônica. Você indica a sua preferência; a escolha final é do Google.

<link rel="canonical" href="https://www.exemplo.com.br/produto/tenis-azul">

Os sinais se somam: a tag canônica e o sitemap apontando para a mesma URL reforçam a escolha. O problema é o sinal contraditório, como um sitemap que lista uma URL e uma tag canônica que aponta para outra. O Google também desaconselha usar robots.txt ou noindex para escolher canônica: o primeiro deixa a URL ser indexada sem conteúdo, e o segundo tira a página da busca por completo (Google, como especificar uma URL canônica).

Na Inspeção de URL do Search Console aparecem a canônica que você declarou e a que o Google selecionou. Quando são diferentes, o relatório Indexação de páginas mostra o motivo "Cópia, o Google e o usuário não escolheram a mesma página canônica" (ajuda do Search Console, Inspeção de URL).

Quando a duplicata deve sumir, como numa mudança de http para https, o sinal certo é o redirecionamento. O artigo sobre redirecionamentos, cadeias e loops trata dos tipos de redirecionamento e de como testar.

Sitemap: a lista das URLs que você quer indexadas

O sitemap é um arquivo, normalmente XML, que lista as URLs do site. O Google trata o envio como uma dica: pode nem baixar o arquivo e não promete rastrear tudo o que está nele (Google, criar e enviar um sitemap). As regras da documentação:

• Cada arquivo aceita até 50.000 URLs ou 50 MB sem compressão. Acima disso, divida em vários sitemaps e liste todos num arquivo de índice de sitemaps.

• A codificação deve ser UTF-8.

• As URLs devem ser completas (https://www.exemplo.com.br/pagina), porque o Google rastreia exatamente o que está escrito.

• Entram só as versões canônicas, as que você quer nos resultados.

• O Google usa o lastmod só quando ele é consistente e verificavelmente correto. A data deve refletir a última mudança significativa da página. Um sitemap que marca todas as URLs com a data do dia a cada geração não cumpre esse critério.

• priority e changefreq são ignorados pelo Google.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.exemplo.com.br/produto/tenis-azul</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
</urlset>

Para enviar, há três caminhos: o relatório Sitemaps do Search Console, a API do Search Console ou uma linha Sitemap: no robots.txt.

O sitemap não tem relação com o llms.txt, um arquivo proposto para modelos de linguagem. Em junho de 2026 o Google acrescentou à documentação que arquivos llms.txt não são necessários para o Google Search e não afetam visibilidade nem posição (Google Search Central, registro de atualizações). O artigo sobre llms.txt explica para que ele serve fora do Google.

Status HTTP: o que o Googlebot faz com cada resposta

O código de status é o número de três dígitos que o servidor devolve junto com a página. O significado de cada código está na RFC 9110; o tratamento que o Google dá a eles está na documentação de rastreamento do Google.

Soft 404 é a página que responde 200 mas mostra uma mensagem de erro ou vem vazia, como um "produto não encontrado" servido com status de sucesso. Para o servidor está tudo certo; para o Google, é uma página de erro. A correção é responder 404 ou 410 quando o conteúdo não existe, ou pôr conteúdo real se a página deveria existir. Em sites grandes, o guia de orçamento de rastreamento lembra que páginas soft 404 continuam sendo rastreadas e gastam esse orçamento.

JavaScript: quando o conteúdo depende de renderização

Em sites que montam a página no navegador, o HTML que o servidor entrega pode chegar quase vazio. O Google processa essas páginas em três fases: rastreia, renderiza e indexa. Toda página com status 200 entra numa fila de renderização, a menos que tenha noindex. Ela pode esperar alguns segundos ou mais até que um Chromium sem interface execute o JavaScript. Páginas com status diferente de 200 podem nem ser renderizadas (Google, noções básicas de JavaScript para SEO).

Pontos que a documentação destaca:

• O Google só descobre links que são elementos <a> com atributo href. Navegação feita só com evento de clique não serve como link.

• Rotas com fragmento (#/produtos) não são resolvidas de forma confiável. Use a History API com caminhos reais.

• Em aplicações de página única, uma rota inexistente costuma responder 200. O Google sugere redirecionar por JavaScript para uma URL que responda 404 ou inserir noindex nas telas de erro.

• Um noindex no HTML original pode fazer o Google pular a renderização.

O Google continua recomendando renderização no servidor ou pré-renderização, porque nem todo robô executa JavaScript.

Os motivos do relatório Indexação de páginas

No Search Console, o relatório Indexação de páginas lista as URLs que o Google conhece e, para as não indexadas, o motivo. Os nomes abaixo são os da interface em português (ajuda do Search Console, relatório de indexação de páginas).

Entre as páginas indexadas, o relatório pode mostrar dois avisos: "Página indexada, mas bloqueada pelo robots.txt" e "Página indexada, mas sem conteúdo", quando o Google não conseguiu ler o conteúdo.

Checklist: a página não foi indexada

1. Abra a URL na Inspeção de URL do Search Console. Ela mostra o status, o último rastreamento e a canônica escolhida pelo Google. O resultado padrão é a versão indexada; o teste ao vivo busca a página na hora.

2. Confira o status HTTP. A URL precisa responder 200 por conta própria, sem redirecionamento:

   curl -sI https://www.exemplo.com.br/pagina

3. Confira se o robots.txt libera o caminho para o Googlebot.

4. Procure noindex no HTML original e no cabeçalho X-Robots-Tag. O comando do passo 2 mostra os cabeçalhos.

5. Confira a canônica. A tag deve apontar para a própria URL, ou para a versão que você quer indexada, e o sitemap deve listar essa mesma URL.

6. Veja o HTML que o Google recebeu (a Inspeção de URL mostra o HTML e os cabeçalhos). O conteúdo principal precisa estar ali, e não só aparecer depois de cliques no navegador.

7. Descarte soft 404: a página tem conteúdo próprio e não parece uma mensagem de erro.

8. Garanta que a página pode ser encontrada: ela está no sitemap e recebe links <a href> de outras páginas do site.

9. Leia o motivo no relatório Indexação de páginas e siga a linha correspondente da tabela acima.

10. Se o motivo for "Rastreada, mas ainda não indexada", não há bloqueio técnico a remover. A recomendação aqui é revisar o conteúdo, não a configuração: páginas muito parecidas com outras do site ou com pouco texto próprio são as primeiras candidatas. O Google não publica os critérios exatos dessa decisão.

11. Se o motivo for "Detectada, mas não indexada no momento", olhe para o servidor: respostas 5xx e 429 fazem o Google reduzir o ritmo de rastreamento. O guia de orçamento de rastreamento foi escrito para sites grandes (por volta de 1 milhão de páginas, ou 10 mil com mudança diária, números que o próprio Google chama de aproximados) e para sites com muitas URLs nesse estado.

12. Depois de corrigir, peça a indexação na Inspeção de URL. Há limite diário de pedidos e o pedido não garante indexação; para muitas URLs, o caminho é o sitemap.

Como verificar o seu site

Parte dessas checagens pode ser feita com as ferramentas grátis do WebVyze. O validador de robots.txt confere a sintaxe, o sitemap declarado e quais robôs (Google, Bing e robôs de IA, separando busca e treinamento) podem rastrear um caminho. Há também o validador de sitemap, o verificador de redirecionamentos e o validador de dados estruturados. Essas ferramentas leem as páginas públicas do site; o motivo exato de uma URL não estar indexada só aparece no Search Console.