Duas pessoas fizeram exatamente a mesma pergunta durante nosso evento ao vivo sobre a realidade do tráfego de bots, mas não conseguimos respondê-las durante a transmissão: um arquivo llms.txt realmente impede que a IA sobrecarregue seu site?
Refletimos bastante sobre essa pergunta porque a resposta honesta não é um simples “sim” ou “não”. O llms.txt nunca foi criado para desempenhar nenhuma das duas funções que muitos esperavam, e boa parte do que foi publicado sobre ele este ano acabou levando muita gente a acreditar no contrário.
Essa confusão não acontece apenas em torno do llms.txt. Entre as perguntas que recebemos, robots.txt, llms.txt, crawlers de IA e Proteção contra bots eram frequentemente tratados como se fossem quatro configurações diferentes do mesmo controle, em que alterar qualquer uma delas produzisse o mesmo resultado. Mas não é assim. Cada uma atua em um ponto completamente diferente do fluxo das solicitações, é aplicada por mecanismos totalmente distintos (ou, em um dos casos, nem sequer é aplicada) e confundi-las é justamente o que leva muitos proprietários de sites a fazerem tudo “certo” e, ainda assim, continuarem sendo sobrecarregados.
E isso não é apenas teoria. Em nosso Relatório sobre IA e tráfego de bots, descobrimos que o tráfego de bots de IA nos sites hospedados na Kinsta passou de 1 em cada 200 visitas há um ano para 1 em cada 31 visitas atualmente. Quando tanta gente está tentando abrir a porta, uma placa dizendo “não entre” deixa de fazer muita diferença.
Resumo
- robots.txt é um pedido, não um bloqueio. Crawlers de IA respeitáveis, como os da OpenAI, Anthropic, Google e Perplexity, normalmente leem e seguem suas diretivas. Outros, como o Bytespider, da ByteDance, historicamente não fizeram isso.
- llms.txt não controla o acesso. Ele funciona como um índice de conteúdo para ferramentas de IA que optam por utilizá-lo, e não como um arquivo de permissões. Sua adoção gira em torno de 9% a 10% dos sites, e os principais crawlers de IA praticamente nem o consultam.
- Proteção contra bots é a única camada que realmente impõe regras. Tanto robots.txt quanto llms.txt apenas fazem solicitações aos crawlers. Já a Proteção contra bots da Kinsta e o AI Crawl Control da Cloudflare são responsáveis por bloquear, aplicar verificação ou limitar a taxa de solicitações de crawlers que ignoram essas preferências.
Quatro camadas, quatro funções e uma grande fonte de confusão
| Camada | O que realmente faz | Pode impedir um agente mal-intencionado? |
| robots.txt | Informa suas preferências aos crawlers que decidirem ler o arquivo | Não |
| llms.txt | Fornece às ferramentas de IA um índice organizado do seu conteúdo | Não |
| Crawlers de IA | São os bots que fazem as solicitações | N/A (eles são o alvo do gerenciamento, não um mecanismo de controle) |
| Proteção contra bots (Kinsta / Cloudflare) | Detecta, classifica e aplica ações às solicitações no nível da infraestrutura | Sim |
Quando você observa essas quatro camadas dessa forma, percebe que a maioria das perguntas feitas durante o evento praticamente se responde sozinha. Então, vamos analisá-las uma a uma, começando pela que quase todo mundo acredita já entender.
robots.txt
O robots.txt, padronizado pela RFC 9309, informa aos crawlers quais partes do seu site você prefere que eles não acessem. Ele não possui nenhum mecanismo técnico de aplicação dessas regras, portanto funciona apenas porque os crawlers que o leem decidiram, por política própria, respeitar essas instruções.
A parte tranquilizadora é que os crawlers com os quais você provavelmente mais se preocupa, como os da OpenAI, Anthropic, Google e Perplexity, publicam seus user agents oficialmente e respeitam as diretivas padrão.
O que costuma gerar confusão é presumir que cada empresa opera um único “bot de IA”. Não é assim. Atualmente, a maioria delas separa os crawlers responsáveis pelo treinamento dos modelos daqueles responsáveis pela pesquisa. E essa distinção é, provavelmente, o ponto mais importante de todo este artigo:
- GPTBot (OpenAI): utilizado para treinar modelos fundamentais. Se você bloqueá-lo, seu conteúdo deixará de ser utilizado em futuros treinamentos.
- OAI-SearchBot (OpenAI): indexa páginas para que possam ser citadas na pesquisa do ChatGPT. Bloqueá-lo impede essas citações, mas não afeta o treinamento dos modelos.
- ClaudeBot (Anthropic): utilizado para treinamento.
- Claude-SearchBot (Anthropic): responsável pela indexação para as pesquisas do Claude.
- Google-Extended: controla o uso do conteúdo em treinamentos de IA e nos AI Overviews. Bloqueá-lo não afeta a indexação realizada pelo Googlebot nem o posicionamento do seu site na Pesquisa Google.
- PerplexityBot: crawler do mecanismo de respostas da Perplexity.
Portanto, a verdadeira decisão nunca foi simplesmente “permitir ou bloquear a IA”. A questão é outra: você quer que seu conteúdo seja usado para treinar modelos, aparecer citado em respostas geradas por IA, ambos ou nenhum dos dois? O robots.txt já permite responder a essa pergunta com bastante precisão. O problema é que a maioria dos proprietários de sites nunca pensou nela dessa forma.
Veja como esse nível de controle pode ser aplicado na prática em um arquivo robots.txt. Imagine que você queira impedir totalmente o uso do seu conteúdo para treinamento, mas ainda deseje que ele seja citado quando alguém fizer uma pergunta ao ChatGPT ou ao Claude que seu conteúdo possa responder:
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /Se preferir impedir completamente o acesso a uma seção específica do seu site, tanto para treinamento quanto para pesquisa, basta aplicar a diretiva Disallow apenas ao caminho desejado, em vez de ao site inteiro:
User-agent: GPTBot
Disallow: /premium-reports/
User-agent: ClaudeBot
Disallow: /premium-reports/O problema é que seguir essas regras é uma questão de cortesia, não uma obrigação. Alguns crawlers têm um histórico documentado de simplesmente ignorar as diretivas Disallow. Além disso, existe uma situação mais recente: quando alguém pede ao ChatGPT ou a outro assistente semelhante para acessar uma página específica naquele momento, essa solicitação individual nem sempre se comporta como um rastreamento tradicional, e a lógica do robots.txt nem sempre se aplica a esse tipo de acesso.
llms.txt
Ao longo de 2026, muita gente passou a descrever o llms.txt como uma ferramenta de controle de acesso ou até mesmo como uma técnica de SEO. Na prática, porém, ele é muito mais simples e menos útil do que essas publicações fazem parecer.
O llms.txt é um arquivo Markdown simples, localizado na raiz do seu site, que funciona como uma espécie de índice para ferramentas de IA. Ele aponta para as páginas mais importantes do seu conteúdo, permitindo que um modelo compreenda rapidamente o que seu site oferece sem precisar interpretar uma página HTML inteira renderizada. Esse é todo o propósito da especificação. Em nenhum momento, ela define o que um crawler pode ou não acessar.
Veja um exemplo simplificado:
# Acme Analytics
> Acme Analytics is a WordPress plugin for tracking site performance and uptime.
## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation
## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparisonRepare que não existe nenhuma diretiva como Allow, Disallow, regras por user agent ou qualquer outro mecanismo que informe a um crawler o que ele pode ou não fazer.
As evidências atuais mostram o seguinte:
- A adoção ainda é baixa. Apenas cerca de 9% a 10% dos sites utilizam um arquivo llms.txt, mesmo entre alguns dos maiores domínios da internet, mais de um ano depois de ele começar a ser recomendado.
- Os crawlers mais importantes praticamente não o utilizam. Análises de centenas de milhões de solicitações feitas por bots de IA mostram que GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot e Google-Extended normalmente ignoram esse arquivo e vão diretamente para o HTML.
- O Google já se posicionou oficialmente sobre isso. Representantes da Pesquisa Google afirmaram publicamente que o llms.txt não é utilizado como sinal de classificação nem de rastreamento e chegaram a compará-lo — de forma nada elogiosa — à antiga meta tag keywords, hoje obsoleta.
- Nenhum dos principais laboratórios de IA assumiu o compromisso de tratar o llms.txt como um mecanismo de controle de acesso, seja para treinamento, seja para pesquisa.
Onde o llms.txt realmente agrega valor é como um índice organizado para agentes de programação e ferramentas de desenvolvimento, como Claude Code e Cursor, que se beneficiam de uma estrutura clara da documentação de um site.
Em outras palavras, o llms.txt não impedirá que seu site continue sendo rastreado repetidamente. Ele é um recurso para facilitar a descoberta de conteúdo, não um limitador de taxa nem um mecanismo de controle de acesso.
Crawlers de IA
O termo crawler de IA costuma ser usado para descrever pelo menos três comportamentos completamente diferentes. Misturá-los é o que leva a muitas decisões equivocadas:
- Crawlers de treinamento, que coletam conteúdo periodicamente para compor o conjunto de treinamento de um modelo, como GPTBot, ClaudeBot, Google-Extended, Bytespider e CCBot.
- Crawlers de pesquisa e respostas, que constroem o índice utilizado pelos mecanismos de resposta baseados em IA, como OAI-SearchBot, Claude-SearchBot e PerplexityBot.
- Acessos em tempo real realizados por agentes, em que uma pessoa pede a um assistente para acessar uma página específica naquele momento, e ele faz isso imediatamente.
Os dois primeiros comportam-se como crawlers tradicionais e normalmente se identificam por meio de um user agent documentado, o que torna possível controlá-los com robots.txt. Já o terceiro se parece muito mais com um usuário clicando em um link do que com um crawler tradicional. Por isso, algumas ferramentas de navegação baseadas em IA aparecem nos registros do servidor exatamente como visitantes comuns, e é também por isso que regras genéricas de bloqueio de bots podem acabar afetando atividades legítimas iniciadas por usuários reais.
Esse também foi o ponto destacado por Daniel Pataki durante o webinar: hoje, a maior parte do tráfego gerado por crawlers de IA não é maliciosa; ela é apenas incessante. Esses bots seguem todos os links que encontram, incluindo todas as variações redundantes de URL geradas dinamicamente por páginas do WordPress e do WooCommerce. Como resultado, acabam percorrendo repetidamente páginas praticamente idênticas, produzindo um comportamento que parece um ataque, quando na verdade é apenas um bot incapaz de perceber que já visitou aquela mesma página milhares de vezes.
Explicamos em mais detalhes por que isso afeta especialmente lojas WooCommerce em nosso artigo sobre por que sites WooCommerce são especialmente vulneráveis ao tráfego de bots.
A única camada que realmente impõe regras: Proteção contra bots
Quando você entende que o robots.txt é apenas uma recomendação e que o llms.txt nem sequer é um mecanismo de controle, resta apenas uma camada capaz de agir contra crawlers que ignoram suas preferências: a Proteção contra bots, seja ela da Kinsta, da Cloudflare ou de qualquer outro fornecedor.
A Cloudflare evoluiu rapidamente nessa área. Na Kinsta, porém, seguimos uma abordagem mais específica para WordPress, oferecendo um botão Bloquear crawlers de IA que impede o acesso de crawlers de IA — inclusive os verificados — sem afetar o Googlebot nem o Bing. Também classificamos Crawlers de IA com taxa excessiva, identificando bots tecnicamente verificados, mas que estão enviando solicitações em um volume muito acima do esperado para um rastreamento normal.
Laszlo Farkas, nosso Diretor de Engenharia, resumiu bem esse equilíbrio quando perguntamos a ele como uma solução gerenciada se compara à criação manual de regras:
Se você tem o conhecimento técnico e o tempo necessário para ajustar tudo isso manualmente, provavelmente essa será a melhor opção para você. Caso contrário, acredito que a solução da Kinsta seja a melhor escolha, porque ela é gerenciada, otimizada para WordPress e mantida continuamente por nossa equipe.
Para uma comparação mais detalhada entre a solução da Kinsta e a do Cloudflare, consulte nosso guia Proteção contra bots da Kinsta vs Cloudflare.
Respondendo diretamente às perguntas que recebemos
“Queremos adotar crawlers de LLMs, mas evitar abusos. Existe uma forma confiável de fazer isso?” Sim. A melhor abordagem é separar deliberadamente os crawlers de treinamento dos de pesquisa e respostas. Permita os crawlers responsáveis por pesquisa e respostas se quiser que seu conteúdo seja encontrado e citado. Utilize o robots.txt para impedir especificamente os crawlers de treinamento, caso esse seja o seu objetivo. Depois, deixe que a Proteção contra bots lide com abusos baseados em volume, independentemente de o crawler ser verificado ou não.
“Não queremos bloquear esse tráfego, porque queremos que a IA destaque nossa empresa. O que devemos fazer?” A resposta é praticamente a mesma, apenas sob outra perspectiva. Ser encontrado por mecanismos de IA e controlar o consumo de recursos do servidor não são objetivos conflitantes, porque diferentes crawlers desempenham essas funções. Se sua preocupação estiver relacionada ao treinamento dos modelos ou ao excesso de solicitações, aplique verificação ou bloqueie esses crawlers, mas mantenha liberados aqueles responsáveis por pesquisa e respostas.
“Um paywall impede que bots de IA acessem esse conteúdo?” Parcialmente, e apenas para crawlers que se comportam como crawlers tradicionais. Uma área protegida por login impede o acesso de bots que respeitam a estrutura normal das páginas e não possuem credenciais válidas, exatamente como acontece com visitantes anônimos. No entanto, isso não impede ferramentas de IA que navegam como um usuário comum nem aquelas que acessam o mesmo conteúdo por meio de uma versão armazenada em cache, de um feed RSS ou de qualquer outro caminho alternativo que nunca passe pela lógica do paywall. É uma camada útil, mas não substitui a Proteção contra bots.
“Podemos impedir que crawlers de IA fiquem percorrendo infinitamente os filtros da nossa loja WooCommerce?” Esse problema está mais relacionado ao cache e à estrutura das URLs do que propriamente à proteção contra bots. Os crawlers seguem todos os links que encontram, e parâmetros dinâmicos de filtros e ordenação podem gerar praticamente um número infinito de URLs diferentes para o que, na prática, é a mesma página. Um bom primeiro passo é bloquear esses padrões de parâmetros no robots.txt:
User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=Quando um crawler ignora essas regras, o que alguns realmente fazem, as regras de limitação por taxa da Proteção contra bots são as responsáveis por interromper esse comportamento.
O que você deve levar deste artigo
Pare de enxergar essas quatro tecnologias como alternativas concorrentes e passe a tratá-las como camadas complementares, aplicadas nesta ordem:
- O robots.txt expressa sua intenção, separando os crawlers de treinamento daqueles voltados para pesquisa e respostas, de acordo com seus objetivos.
- O llms.txt, se você decidir utilizá-lo, é apenas uma conveniência para as ferramentas que o leem, e não um mecanismo para reduzir ou controlar o volume de rastreamento.
- O termo crawlers de IA engloba bots de treinamento, bots de pesquisa e acessos em tempo real realizados por agentes, e cada um deles pode exigir uma estratégia diferente.
- A Proteção contra bots é a única camada que realmente impõe regras, pois é a única capaz de agir quando uma solicitação ignora tudo o que você definiu nas demais.
Se sua principal dúvida não for “como controlar isso”, mas sim “como ser encontrado por essas ferramentas”, nossos guias sobre AEO para WordPress e GEO vs AEO vs SEO continuam exatamente de onde este artigo termina. Para explorar os controles abordados aqui, consulte a Proteção contra bots da Kinsta.
