Robots.txt: como configurar sem bloquear o Google

Robots.txt: como configurar sem bloquear o Google

O robots.txt é um arquivo de texto simples que fica na raiz do seu domínio e instrui os robôs de busca sobre o que eles podem ou não rastrear. Ele parece trivial — são poucas linhas —, mas é justamente a simplicidade que torna os erros perigosos: uma única barra fora do lugar pode fazer o Googlebot deixar de ver o site inteiro. Este guia mostra a sintaxe correta, os erros mais comuns que bloqueiam o Google sem querer, exemplos práticos por tipo de site, como testar o arquivo e como remediar um bloqueio acidental que já esteja em produção.

A sintaxe do robots.txt

O arquivo é composto por blocos de diretivas agrupados por User-agent. Cada bloco declara para qual robô as regras se aplicam e quais paths estão permitidos ou bloqueados.

Diretivas principais

• User-agent: — nome do robô ao qual o bloco se aplica. * significa "todos os robôs". Para regras específicas do Google, use Googlebot (rastreamento web geral), Googlebot-Image (imagens), Googlebot-News, AdsBot-Google etc.
• Disallow: — path que o robô NÃO deve rastrear. Disallow: / bloqueia o site inteiro; Disallow: (vazio) não bloqueia nada.
• Allow: — exceção dentro de um path bloqueado. Útil quando você bloqueia uma pasta inteira mas quer liberar um subitem.
• Sitemap: — URL absoluta do sitemap XML. Diferente das outras diretivas, é declarada fora dos blocos de User-agent, geralmente ao final do arquivo.

Estrutura mínima

``` User-agent: * Disallow: /admin/ Allow: /admin/public-info.html

Sitemap: https://www.seusite.com.br/sitemap.xml ```

Regras de precedência

Quando há blocos para vários agentes, o Googlebot lê o bloco mais específico que casa com seu nome. Se existir um bloco User-agent: Googlebot e outro User-agent: , o Google segue o bloco específico e ignora o genérico. Isso é uma armadilha comum: pessoas colocam permissões no bloco e restrições no bloco Googlebot achando que se somam — não somam.

Dentro de um mesmo bloco, quando Allow e Disallow conflitam para uma URL, a regra que tem o path mais longo (mais específico) vence. Em caso de empate no comprimento, o Allow prevalece.

Wildcards

• casa qualquer sequência de caracteres. Disallow: /.pdf$ bloqueia todos os PDFs.
• $ marca o final da URL. Sem ele, /*.pdf bloquearia também /relatorio.pdf?ref=email.

Case-sensitivity

Paths são sensíveis a maiúsculas e minúsculas. Disallow: /Privado/ não bloqueia /privado/. Se o seu servidor trata URLs de forma case-insensitive, esse descasamento vira uma brecha silenciosa.

Localização obrigatória

O arquivo precisa estar na raiz do domínio e ser acessível em https://seudominio.com.br/robots.txt. Ele vale apenas para o host onde está publicado: um robots.txt em seudominio.com.br não afeta blog.seudominio.com.br nem www.seudominio.com.br se essas forem consideradas hosts distintos. Cada subdomínio precisa do seu próprio arquivo.

Erros comuns que bloqueiam o Google sem querer

Antes de reescrever seu arquivo, vale conhecer as armadilhas que mais aparecem em auditorias:

1. Disallow: / esquecido do ambiente de staging

Sites em desenvolvimento costumam nascer com um bloqueio total para não serem indexados antes da hora:

`` User-agent: * Disallow: / ``

O erro clássico é o site ir para produção carregando esse arquivo. O Google para de rastrear tudo, e as páginas somem do índice em pouco tempo. Sempre confira o robots.txt no dia do lançamento.

2. Bloquear pastas administrativas junto com CSS e JS

Um WordPress típico traz algo como Disallow: /wp-admin/. Isso é razoável, mas se você bloquear pastas como /wp-includes/ ou /wp-content/plugins/, o Googlebot pode ficar sem acesso a arquivos CSS e JavaScript necessários para renderizar a página. Sem renderização adequada, o Google pode enxergar um layout quebrado e avaliar a página mal (mobile-friendly, conteúdo visível, etc.).

Se você bloqueia uma pasta que serve recursos de renderização, libere-os explicitamente com Allow:.

3. Wildcards mal calibrados

Disallow: /*? para bloquear qualquer URL com query string parece útil para evitar rastreamento de filtros duplicados — mas também bloqueia URLs de campanhas com UTM, paginação e qualquer coisa que use parâmetros. Antes de usar wildcards agressivos, pense em tudo que passa por eles.

4. Confundir Disallow com noindex

Disallow não é uma diretiva de "não indexe". Ela diz "não rastreie". Uma URL bloqueada no robots.txt mas com muitos links externos apontando pode aparecer no índice sem descrição e sem título útil, porque o Google conhece a URL mas não conseguiu ler o conteúdo. Para tirar uma página do índice, use meta noindex — e para isso o Google precisa conseguir rastrear a página. Se você bloquear no robots.txt, o noindex nunca é lido.

5. Bloquear recursos de terceiros necessários

CDNs, fontes, scripts de tag manager, imagens hospedadas em subdomínios: se algum recurso essencial para renderizar a página estiver em um host bloqueado (mesmo que não seja o seu), o Google pode ter dificuldade para avaliar o conteúdo. Isso geralmente escapa porque o robots.txt do outro host não está sob seu controle — mas é bom saber que existe.

6. Diretivas não suportadas

Crawl-delay, Host e noindex dentro do robots.txt não são interpretadas pelo Googlebot. Colocar noindex: /pagina/ no robots.txt não faz nada — a pagina continua indexável. Use os canais corretos: meta tag ou header HTTP.

7. Sintaxe fora do padrão

Comentários fora de linha, uso de ; no lugar de #, blocos sem User-agent, espaços iniciais em linhas: o parser tolera algumas coisas, mas outras invalidam a regra silenciosamente. Mantenha o arquivo limpo, um comando por linha, comentários iniciando com #.

Configurações corretas por tipo de site

Abaixo, exemplos práticos que servem como ponto de partida. Ajuste conforme a estrutura real do seu site.

Site padrão (institucional / blog simples)

``` User-agent: * Allow: /

Sitemap: https://www.seusite.com.br/sitemap.xml ```

Quando não há nada sensível para bloquear, o melhor robots.txt é o mais permissivo possível. Não invente restrições preventivas.

WordPress

``` User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.seusite.com.br/sitemap_index.xml ```

Note o Allow: /wp-admin/admin-ajax.php — muitos plugins e temas usam esse endpoint para carregar conteúdo dinamicamente, inclusive coisas que o Google precisa ver.

Evite bloquear /wp-content/ e /wp-includes/ em bloco. Se precisar restringir arquivos específicos, faça de forma cirúrgica:

``` User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /wp-content/uploads/private/

Sitemap: https://www.seusite.com.br/sitemap_index.xml ```

E-commerce

Lojas geram muitas URLs de filtros, ordenação e busca interna que não têm valor para o índice:

``` User-agent: Disallow: /carrinho/ Disallow: /checkout/ Disallow: /minha-conta/ Disallow: /?orderby= Disallow: /*?filter_ Disallow: /?s= Allow: /

Sitemap: https://www.sualoja.com.br/sitemap.xml ```

Cuide para não bloquear a paginação de categorias (?page= costuma ser útil para o Google descobrir produtos) nem parâmetros de campanha (?utm_).

Staging / ambiente de homologação

`` User-agent: * Disallow: / ``

Isso desestimula o rastreamento, mas não é uma garantia de que a URL não vá aparecer no índice se houver links externos. Para staging, o correto é combinar: bloqueio no robots.txt + autenticação HTTP básica ou IP restrito + meta noindex nas páginas. Nunca dependa só do robots.txt para proteger conteúdo confidencial.

Regra específica para o Googlebot

Se precisar de regras diferentes só para o Google:

``` User-agent: * Disallow: /pasta-interna/

User-agent: Googlebot Disallow: /pasta-interna/ Allow: /pasta-interna/publico/

Sitemap: https://www.seusite.com.br/sitemap.xml ```

Lembre-se: o bloco Googlebot substitui o bloco * para o Google — não soma. Se você quer que o Googlebot siga as regras gerais + uma extra, precisa repetir as regras gerais dentro do bloco dele.

Como fazer o deploy do arquivo

1. Criar o arquivo localmente como robots.txt (texto puro, codificação UTF-8, sem BOM).
2. Enviar para a raiz do servidor via FTP, SFTP, painel de hospedagem, Git ou o mecanismo que você usar. Precisa ficar acessível em https://seudominio.com.br/robots.txt — não em subpasta.
3. Verificar acesso público: abra a URL no navegador anônimo. Deve retornar HTTP 200 e o conteúdo do arquivo. Se retornar 404, o arquivo não está no lugar. Se retornar 403, o servidor está negando leitura — corrija as permissões.
4. Verificar o Content-Type: idealmente text/plain. Alguns servidores mal configurados servem como text/html e alguns parsers ficam confusos, embora o Google seja tolerante.

Em sites que dependem de CDN, lembre que o CDN pode estar cacheando a versão antiga. Faça purge explícito depois de trocar o arquivo.

Como testar antes e depois

1. Testador de robots.txt do Google Search Console

Dentro do Search Console, existe uma ferramenta que mostra a versão do robots.txt que o Google está usando, destaca linhas com erro de sintaxe e permite testar URLs específicas contra as regras. O resultado é literal: "Permitido" ou "Bloqueado por: <linha>". Use antes de publicar mudanças.

2. Inspeção de URL

Para cada URL crítica (home, principais categorias, top de conversão), rode a Inspeção de URL no Search Console. Confirme que:

• A URL está listada como rastreável.
• O status de indexação é o esperado.
• Não há mensagem "Bloqueado pelo robots.txt".

Rode a inspeção também em URLs de recursos (um CSS e um JS importante) — se algum estiver bloqueado, o Google avisa em "Recursos da página".

3. Cobertura / Páginas

Ainda no Search Console, o relatório de páginas mostra a categoria "Bloqueada pelo robots.txt". Depois de qualquer mudança, monitore essa categoria por alguns dias. Um aumento súbito é sinal de bloqueio acidental.

4. Logs do servidor

Se você tem acesso aos logs de acesso, filtre por User-agent contendo Googlebot e observe quais paths estão sendo requisitados e quais respondem 200/301/404. Uma queda abrupta no volume de requisições do Googlebot após uma mudança no robots.txt é indício forte de que algo está bloqueando rastreamento além do esperado.

Robots.txt não é a mesma coisa que noindex

Essa é a confusão mais cara e vale isolar:

| Ferramenta | O que faz | Quando usar | |---|---|---| | robots.txt (Disallow) | Impede o rastreamento — o robô não baixa a página. | Economizar orçamento de rastreamento, evitar carga em áreas administrativas, bloquear seções internas sem valor de índice. | | Meta noindex (na <head> da página) | Permite rastreamento, mas pede para não indexar a página. | Tirar uma página específica do índice mantendo-a rastreável. | | Header X-Robots-Tag: noindex | Igual ao meta, mas por HTTP. Funciona em PDFs, imagens, etc. | Controlar indexação de arquivos que não têm <head>. |

O ponto crítico: para o Google respeitar um noindex, ele precisa poder rastrear a página. Se você bloquear a URL no robots.txt e colocar noindex na página, o Google nunca lê o noindex — e a URL pode continuar aparecendo nos resultados (sem descrição, como um snippet vazio) porque o Google sabe que ela existe pelos links externos.

Regra prática:

• Quer não indexar uma página? Use noindex e não bloqueie no robots.txt.
• Quer não rastrear (mas tudo bem se aparecer sem descrição)? Use robots.txt.
• Precisa de conteúdo realmente inacessível? Use autenticação/permissão de servidor — nenhum desses dois mecanismos oferece confidencialidade.

Como remediar um bloqueio acidental

Se você descobriu que o robots.txt estava bloqueando o Google e páginas importantes caíram do índice, siga esta sequência:

1. Corrija o arquivo imediatamente. Publique a versão correta na raiz e confirme via navegador anônimo que o conteúdo servido é o novo.
2. Confirme no Search Console que a versão que o Google está lendo é a nova. O Search Console mostra a data da última leitura do robots.txt e o conteúdo cacheado. O Google normalmente reavalia o arquivo em intervalos curtos, mas pode demorar algumas horas.
3. Rode Inspeção de URL nas páginas críticas e solicite indexação. Isso empurra o recrawl. Fazer isso em cada página estratégica acelera o retorno.
4. Reenvie o sitemap no Search Console. Um "reenvio" sinaliza que há URLs a serem revisitadas.
5. Monitore o relatório de Páginas / Cobertura nos dias seguintes. A categoria "Bloqueada pelo robots.txt" deve diminuir; as páginas devem voltar a "Indexada" gradualmente. Recuperação total pode levar de dias a algumas semanas, dependendo da autoridade e do tamanho do site.
6. Verifique logs do servidor para confirmar que o Googlebot voltou a acessar as URLs afetadas com status 200.
7. Documente o incidente internamente e adicione uma verificação de robots.txt no checklist de deploy — a maior parte desses acidentes acontece em migrações, mudanças de tema ou promoções de staging para produção sem revisão do arquivo.

Um bloqueio acidental é reversível. O tempo até o índice voltar ao normal é o custo — e ele é proporcional ao tempo em que o arquivo errado ficou em produção, então a velocidade de detecção é o que mais importa.