Robots.txt: o que é, sintaxe e como configurar corretamente

Em quase 30 anos de SEO técnico, perdi a conta de quantas vezes um cliente me trouxe um problema grave de indexação que, na investigação, se revelava algo simples: um arquivo robots.txt mal configurado bloqueando exatamente as páginas que deveriam estar sendo rastreadas. É um arquivo pequeno, de texto puro, sem nenhuma sofisticação técnica aparente — mas um único caractere errado nele pode literalmente fazer um site inteiro desaparecer do Google.

Este guia explica o que é robots.txt, como sua sintaxe funciona, os erros mais comuns que causam desastres de indexação, e como configurá-lo corretamente para diferentes cenários.

O que é Robots.txt

Robots.txt é um arquivo de texto simples, localizado na raiz do domínio, que segue o Protocolo de Exclusão de Robôs (Robots Exclusion Protocol) — um padrão da indústria criado em 1994 que instrui crawlers de mecanismos de busca sobre quais áreas do site eles têm permissão para rastrear e quais devem evitar.

É importante entender uma distinção técnica fundamental desde o início: o robots.txt controla rastreamento, não indexação. Bloquear uma URL no robots.txt impede que o crawler visite e processe o conteúdo daquela página — mas não impede necessariamente que ela apareça nos resultados de busca, especialmente se outras páginas linkarem para ela. Para garantir que uma página específica não apareça no índice, a ferramenta correta é a tag noindex, não o robots.txt.

O arquivo deve obrigatoriamente estar localizado em https://www.seudominio.com.br/robots.txt — na raiz exata do domínio. Crawlers de mecanismos de busca verificam esse endereço específico antes de iniciar o rastreamento de qualquer site, e arquivos robots.txt colocados em subdiretórios são simplesmente ignorados.

A Sintaxe do Robots.txt

A estrutura do robots.txt é composta por diretivas simples, organizadas em blocos para diferentes user-agents (os diferentes crawlers que podem visitar o site):

User-agent: Especifica para qual crawler aquele bloco de regras se aplica. Um asterisco (*) representa “todos os crawlers”; nomes específicos como Googlebot ou Bingbot direcionam regras para um motor de busca específico.

Disallow: Especifica um caminho que o crawler não deve acessar. Por exemplo, Disallow: /admin/ bloqueia todo o diretório administrativo.

Allow: Especifica uma exceção dentro de um caminho bloqueado, permitindo acesso a uma sub-área específica mesmo que o diretório pai esteja bloqueado.

Sitemap: Indica a localização do sitemap XML do site, ajudando crawlers a descobrir rapidamente a estrutura completa de URLs disponíveis.

Crawl-delay: Uma diretiva mais antiga, hoje amplamente ignorada pelo Googlebot (que gerencia velocidade de rastreamento através do Search Console), mas ainda respeitada por alguns outros crawlers.

Um exemplo básico de robots.txt para a maioria dos sites:

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

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

Robots.txt e Crawl Budget

Uma das aplicações mais estratégicas do robots.txt é a gestão do crawl budget — o orçamento limitado de recursos que os mecanismos de busca alocam para rastrear cada site. Para sites grandes, especialmente e-commerces com milhares de páginas geradas dinamicamente (filtros de busca, variações de produto, páginas de paginação), bloquear áreas de baixo valor de SEO no robots.txt libera crawl budget para que o Googlebot dedique mais atenção às páginas que realmente importam para o ranqueamento.

Áreas comumente bloqueadas por essa razão incluem: parâmetros de URL de filtros e ordenação, páginas de resultados de busca interna do site, áreas de carrinho e checkout (que não têm valor de SEO e podem gerar páginas infinitas combinando parâmetros), e áreas administrativas do CMS.

Erros Comuns e Catastróficos no Robots.txt

Bloquear o site inteiro acidentalmente: O erro mais catastrófico e, infelizmente, mais comum — geralmente resultado de uma configuração esquecida de ambiente de desenvolvimento ou homologação que migrou para produção. A diretiva Disallow: / sozinha, sem exceções, bloqueia o rastreamento de absolutamente todo o site.

Confundir robots.txt com controle de indexação: Bloquear uma página no robots.txt na expectativa de que ela “saia do Google” é um erro conceitual comum. Se a página já estava indexada e tem backlinks apontando para ela, bloqueá-la no robots.txt pode até fazer com que ela apareça no resultado de busca sem nenhuma descrição visível, já que o Google não conseguirá mais acessar o conteúdo, mas pode manter o registro da URL.

Bloquear recursos necessários para renderização: Bloquear arquivos CSS ou JavaScript essenciais pode impedir que o Googlebot renderize a página corretamente, afetando a avaliação de qualidade e Core Web Vitals, mesmo que o conteúdo textual em si não esteja bloqueado.

Sintaxe incorreta gerando interpretação ambígua: Caminhos especificados sem a barra inicial, capitalização inconsistente entre o robots.txt e as URLs reais do site, ou regras conflitantes entre diferentes blocos de user-agent podem gerar comportamento inesperado e difícil de diagnosticar sem ferramentas específicas de teste.

Robots.txt em Plataformas Específicas

WordPress: Por padrão, o WordPress gera um robots.txt virtual básico automaticamente, mas a maioria dos plugins de SEO (Yoast SEO, RankMath) permite editar esse arquivo diretamente pelo painel administrativo, sem precisar de acesso FTP ao servidor.

E-commerce (WooCommerce, Shopify, VTEX): Plataformas de e-commerce geralmente exigem configuração mais cuidadosa, já que geram automaticamente um volume grande de URLs de baixo valor (filtros, ordenação, busca interna) que se beneficiam de bloqueio estratégico para preservar crawl budget.

Sites headless ou com frameworks JavaScript: Para sites construídos com React, Vue ou frameworks similares, é especialmente importante garantir que arquivos JavaScript essenciais para renderização não estejam bloqueados, já que o Googlebot moderno depende de conseguir executar esse código para entender completamente o conteúdo da página.

Como Testar e Validar o Robots.txt

Antes de publicar qualquer alteração no robots.txt, especialmente em sites já estabelecidos com tráfego significativo, a validação é uma etapa que não deveria nunca ser pulada:

Testador de robots.txt do Google Search Console: Permite simular como o Googlebot interpretaria regras específicas antes de publicá-las, mostrando exatamente quais URLs seriam bloqueadas ou permitidas.

Verificação manual pós-publicação: Após qualquer alteração, acessar diretamente seudominio.com.br/robots.txt no navegador para confirmar visualmente que o conteúdo publicado corresponde exatamente ao que era esperado.

Monitoramento do relatório de cobertura no GSC: Acompanhar o relatório de páginas excluídas por “bloqueado pelo robots.txt” no Google Search Console nas semanas seguintes a qualquer alteração, garantindo que nenhuma página importante foi inadvertidamente capturada por uma regra nova.

Robots.txt e Crawlers de IA

Com a ascensão de sistemas de IA generativa, uma nova camada de complexidade foi adicionada ao protocolo: diversos user-agents específicos de empresas de IA (como GPTBot da OpenAI, ou crawlers usados para treinar modelos de LLM) agora podem ser controlados de forma independente do Googlebot tradicional, permitindo que sites escolham permitir rastreamento para busca tradicional enquanto restringem ou permitem especificamente o uso de conteúdo para treinamento de IA — uma decisão estratégica relevante no contexto de GEO que cada proprietário de site precisa avaliar conforme seus próprios objetivos de visibilidade.

Robots.txt e Subdomínios: regras independentes

Um aspecto técnico frequentemente mal compreendido é que o robots.txt funciona de forma estritamente vinculada ao protocolo e subdomínio específico onde está hospedado. Isso significa que um arquivo publicado em https://www.seudominio.com.br/robots.txt não controla automaticamente o comportamento de rastreamento em https://blog.seudominio.com.br/ ou em https://seudominio.com.br/ sem o www — cada combinação de protocolo (HTTP versus HTTPS) e subdomínio é tratada como uma origem completamente independente pelos crawlers, exigindo seu próprio arquivo robots.txt se regras diferentes precisarem ser aplicadas.

Esse detalhe se torna especialmente relevante para empresas que mantêm múltiplos subdomínios com finalidades distintas — por exemplo, um subdomínio de blog, um subdomínio de loja e um subdomínio de aplicação logada. Cada um desses ambientes precisa ser avaliado individualmente quanto à necessidade de seu próprio arquivo robots.txt, já que aplicar regras pensando apenas no domínio principal pode deixar lacunas de rastreamento indesejado em ambientes que deveriam estar protegidos, como áreas de aplicação ou staging hospedadas em subdomínios separados.

A Relação entre Robots.txt e a Tag Noindex

Já estabelecemos que robots.txt e noindex cumprem funções diferentes, mas vale aprofundar essa distinção porque ela é fonte recorrente de confusão prática entre profissionais menos experientes em SEO técnico. A tag noindex, implementada via meta tag HTML ou cabeçalho HTTP X-Robots-Tag, instrui o mecanismo de busca a não incluir aquela página específica no índice de resultados — mas para que essa instrução seja efetivamente lida e respeitada, o crawler precisa primeiro conseguir acessar a página.

Isso cria uma armadilha técnica comum: se uma página tem a tag noindex implementada corretamente, mas o robots.txt bloqueia o acesso a ela, o Googlebot nunca vai conseguir ler essa instrução de noindex, porque nunca vai conseguir abrir a página para verificar seu conteúdo. Nesses casos, contraintuitivamente, a página pode permanecer indexada com base apenas no registro da URL e em sinais externos (como anchor text de backlinks apontando para ela), mesmo com a intenção clara do proprietário de removê-la do índice.

A sequência correta para remover definitivamente uma página do índice do Google é: primeiro, garantir que ela esteja acessível ao rastreamento (sem bloqueio no robots.txt); segundo, implementar a tag noindex; terceiro, aguardar o próximo rastreamento do Googlebot, que processará a página, identificará a instrução de noindex, e então removerá a URL do índice. Somente depois desse processo completo, se desejado, a página pode ser bloqueada no robots.txt para impedir rastreamentos futuros desnecessários daquela URL já removida.

Robots.txt em Migrações e Trocas de Domínio

Durante processos de migração de site ou troca de domínio, o robots.txt exige atenção redobrada em momentos específicos do processo. É surpreendentemente comum que ambientes de desenvolvimento ou homologação, configurados com Disallow: / para evitar que conteúdo de teste seja indexado prematuramente, acabem migrando para o ambiente de produção com essa mesma configuração bloqueante — um erro que pode passar despercebido por dias ou semanas até que a equipe note a queda abrupta de tráfego orgânico nos relatórios.

A recomendação prática para qualquer processo de migração: incluir a verificação manual do conteúdo do robots.txt como um item explícito e obrigatório no checklist de lançamento, verificado tanto antes quanto imediatamente depois da virada para produção. Esse é exatamente o tipo de erro simples, mas catastrófico, que uma auditoria de SEO técnica completa deveria sempre incluir como etapa de verificação padrão, independentemente de haver ou não uma migração em andamento.

Robots.txt Avançado: Wildcards e Padrões de URL

Além das diretivas básicas, o protocolo de robots.txt suporta o uso de caracteres especiais para criar regras mais flexíveis e abrangentes, especialmente úteis em sites com estruturas de URL complexas e geradas dinamicamente.

O asterisco (*) funciona como um wildcard que representa qualquer sequência de caracteres, permitindo bloquear padrões inteiros de URL em vez de caminhos exatos individuais. Por exemplo, Disallow: /*?ordenacao= bloqueia qualquer URL que contenha esse parâmetro específico de ordenação, independentemente de qual página ou produto venha antes dele na URL — extremamente útil para controlar a explosão combinatória de URLs geradas por filtros em sites de e-commerce.

O símbolo de cifrão ($) indica o final exato de uma URL, permitindo diferenciar entre bloquear um arquivo específico versus bloquear todo um diretório que começa com aquele mesmo nome. Por exemplo, Disallow: /pagina.html$ bloqueia exatamente esse arquivo, sem afetar outras URLs que começem com o mesmo prefixo, como /pagina.html/variante/.

Robots.txt e a Diretiva Crawl-delay: contexto histórico e atual

Vale dedicar atenção especial à diretiva Crawl-delay, que gera confusão recorrente entre profissionais que aprenderam SEO técnico há mais tempo, em uma época em que essa diretiva tinha relevância prática mais ampla. Originalmente criada para permitir que webmasters controlassem a frequência com que crawlers visitavam o servidor, evitando sobrecarga em infraestruturas mais limitadas, essa diretiva especifica um número de segundos de espera entre requisições sucessivas do mesmo crawler.

O Googlebot moderno simplesmente ignora completamente essa diretiva no robots.txt — o controle de velocidade de rastreamento para sites verificados no Google Search Console é feito através de configurações específicas dentro da própria ferramenta, que ajustam automaticamente a frequência de rastreamento com base na capacidade de resposta do servidor observada ao longo do tempo, sem depender de uma instrução estática no arquivo de texto.

Outros mecanismos de busca, no entanto, como o Bingbot e diversos crawlers menores, ainda respeitam essa diretiva em alguma medida. Para sites que enfrentam problemas reais de sobrecarga de servidor causados por rastreamento agressivo de crawlers secundários — frequentemente bots menos conhecidos ou até maliciosos disfarçados de crawlers legítimos — incluir essa diretiva pode ainda oferecer algum valor prático, mesmo que limitado ao conjunto de crawlers que efetivamente a respeitam.

Diferenças de Comportamento entre os Principais Mecanismos de Busca

Embora o protocolo de robots.txt seja tecnicamente um padrão compartilhado, a forma exata como diferentes mecanismos de busca interpretam casos extremos ou ambíguos pode variar de forma sutil mas relevante na prática.

O Googlebot é geralmente considerado o mais rigoroso e previsível na interpretação estrita das regras especificadas, seguindo a documentação oficial publicada pelo próprio Google com bastante consistência. O Bingbot historicamente demonstrou algumas diferenças sutis na priorização de regras conflitantes entre diferentes blocos de user-agent, o que reforça a importância de testar especificamente a interpretação de cada mecanismo de busca relevante para o seu negócio, e não assumir que uma configuração validada apenas no testador do Google Search Console necessariamente produzirá o comportamento idêntico em outros mecanismos.

Para negócios que dependem significativamente de tráfego de mecanismos de busca além do Google — relevante em alguns nichos e mercados internacionais específicos — vale a pena revisar periodicamente a documentação oficial de cada mecanismo relevante, já que pequenas variações de interpretação podem ter impacto desproporcional em sites com estruturas de URL mais complexas e regras de bloqueio elaboradas.

Robots.txt como Ferramenta de Segurança: o que NÃO fazer

Um erro conceitual sério, e surpreendentemente recorrente mesmo entre profissionais técnicos experientes, é tratar o robots.txt como uma ferramenta de segurança ou privacidade. É importante ser absolutamente claro sobre isso: o robots.txt é um arquivo público, acessível por qualquer pessoa que simplesmente visite o endereço correspondente no navegador, e ele funciona apenas como uma solicitação educada para crawlers que optam por respeitá-lo — não como um mecanismo de bloqueio técnico real.

Isso significa duas implicações práticas importantes que merecem atenção redobrada. Primeiro, listar caminhos sensíveis no robots.txt — como diretórios administrativos, painéis de controle ou áreas internas — na verdade revela publicamente a existência e localização exata dessas áreas para qualquer pessoa mal-intencionada que examine o arquivo, o que pode ser contraproducente do ponto de vista de segurança. Segundo, crawlers maliciosos, scrapers não autorizados e bots com intenção de coletar dados de forma abusiva frequentemente ignoram completamente as diretivas do robots.txt, já que o respeito ao protocolo é inteiramente voluntário e depende da boa-fé de quem programou aquele crawler específico.

Para proteção real de áreas sensíveis do site, as ferramentas técnicas apropriadas incluem autenticação adequada (senhas, login), bloqueio por configuração de servidor (como regras de .htaccess ou firewall de aplicação web), e a tag noindex combinada com proteção de acesso real — nunca o robots.txt isoladamente como única camada de proteção contra acesso indevido a informações sensíveis.

Robots.txt como Reflexo da Arquitetura do Site

Depois de quase 30 anos auditando arquivos robots.txt de toda complexidade — desde sites pessoais simples até e-commerces com milhões de URLs geradas dinamicamente — chego sempre à mesma conclusão prática: a qualidade de um robots.txt é um espelho direto da qualidade do planejamento de arquitetura de informação do site como um todo. Sites bem estruturados, com URLs previsíveis e hierarquia clara, geralmente produzem arquivos robots.txt simples e fáceis de manter. Sites com problemas estruturais profundos — geração descontrolada de parâmetros, duplicação de conteúdo, ausência de planejamento de taxonomia — acabam exigindo arquivos robots.txt cada vez mais complexos e frágeis, tentando remediar via bloqueio de rastreamento problemas que, na origem, deveriam ter sido resolvidos na própria arquitetura técnica do site.

A recomendação mais honesta que posso oferecer é tratar a necessidade de regras complexas e numerosas no robots.txt como um sinal de alerta, não apenas como uma tarefa técnica isolada a ser resolvida. Se o seu arquivo está crescendo constantemente com novas exceções e padrões cada vez mais elaborados, vale a pena parar e investigar se o problema real não está em como o site gera URLs em primeiro lugar — e se uma correção na raiz da arquitetura não seria mais sustentável a longo prazo do que continuar empilhando diretivas de bloqueio.

Perguntas Frequentes sobre Robots.txt

O que é robots.txt?

É um arquivo de texto simples na raiz do domínio que instrui crawlers de mecanismos de busca sobre quais áreas do site podem ou não ser rastreadas, seguindo o Protocolo de Exclusão de Robôs.

Robots.txt impede que uma página apareça no Google?

Não necessariamente. O robots.txt controla rastreamento, não indexação. Para garantir que uma página não apareça nos resultados de busca, a ferramenta correta é a tag noindex, não o bloqueio via robots.txt.

Onde deve ficar o arquivo robots.txt?

Deve estar obrigatoriamente na raiz exata do domínio, no endereço https://www.seudominio.com.br/robots.txt. Arquivos colocados em subdiretórios são ignorados pelos crawlers.

Qual o erro mais grave que pode acontecer no robots.txt?

Bloquear o site inteiro acidentalmente através da diretiva Disallow: / sem exceções, geralmente resultado de uma configuração de ambiente de desenvolvimento que migrou incorretamente para produção, impedindo completamente o rastreamento do site.

Como o robots.txt ajuda no crawl budget?

Bloqueando áreas de baixo valor de SEO, como parâmetros de filtro, busca interna e páginas administrativas, o robots.txt libera o orçamento limitado de rastreamento dos mecanismos de busca para que dediquem mais atenção às páginas que realmente importam para o ranqueamento.

Como testar alterações no robots.txt antes de publicar?

Use o testador de robots.txt do Google Search Console para simular como o Googlebot interpretaria as regras antes de publicá-las, e após a publicação, monitore o relatório de cobertura do GSC nas semanas seguintes.

Robots.txt pode controlar crawlers de IA separadamente do Google?

Sim. User-agents específicos de empresas de IA, como o GPTBot da OpenAI, podem ser controlados de forma independente do Googlebot, permitindo decisões estratégicas distintas entre busca tradicional e uso de conteúdo para treinamento de modelos de IA.

Um robots.txt funciona para todos os subdomínios do site?

Não. O robots.txt é vinculado estritamente ao protocolo e subdomínio específico onde está publicado. Um arquivo em www.site.com.br não controla automaticamente o rastreamento em blog.site.com.br ou em site.com.br sem o www — cada combinação é tratada como origem independente, exigindo seu próprio arquivo se regras diferentes forem necessárias.

O robots.txt é seguro para esconder áreas sensíveis do site?

Não. O robots.txt é um arquivo público que qualquer pessoa pode visualizar diretamente no navegador. Listar caminhos sensíveis nele na verdade revela publicamente a existência dessas áreas. Para proteção real, use autenticação, configuração de servidor ou firewall de aplicação, nunca o robots.txt isoladamente.

O que fazer se a tag noindex de uma página não estiver funcionando?

Verifique se a própria página não está bloqueada no robots.txt. Se estiver bloqueada, o Googlebot nunca conseguirá acessar a página para ler a instrução de noindex. A sequência correta é: garantir acesso de rastreamento primeiro, aguardar o Google processar o noindex, e só depois bloquear a URL no robots.txt se desejado.