Em 2025, os bots representaram 53% de todo o tráfego web, marcando a primeira vez em que o tráfego automatizado superou o tráfego humano em um ano. Em junho de 2026, o Cloudflare Radar apontou esse número em 57,5%, um ponto de virada que, segundo o próprio CEO do Cloudflare, ocorreu anos antes de suas projeções.
Para a maioria das pessoas que gerenciam sites WordPress, nada disso é visível. Seus painéis de controle parecem normais. O número de visitas está aumentando. Mas uma parcela cada vez maior do que impulsiona esses números não é um cliente, leitor ou cliente em potencial, mas um crawler de IA que faz scraping de conteúdo para alimentar um modelo de linguagem, em uma frequência e um volume que os bots de mecanismos de pesquisa nunca alcançaram.
Este artigo explica por que isso afeta os sites WordPress de maneira diferente do rastreamento tradicional e como identificar e responder a esse tráfego diretamente no MyKinsta.
O que é um crawler de IA?
Crawlers de IA são bots automatizados que leem páginas web acessíveis publicamente e coletam seu conteúdo para uso em sistemas de IA. À primeira vista, isso se parece com um crawler tradicional de mecanismo de pesquisa, mas o objetivo é diferente.
Um crawler de pesquisa, como o Googlebot, lê uma página para indexá-la e classificá-la, permitindo que os visitantes encontrem seu site. No entanto, um crawler de IA lê a mesma página para alimentar um modelo de linguagem ou de treinamento. Isso acontece de algumas maneiras:
- Crawlers de treinamento (como GPTBot e ClaudeBot) coletam textos para treinar grandes modelos de linguagem.
- Crawlers de recuperação acessam páginas em tempo real quando alguém faz uma pergunta a uma ferramenta de IA que precisa de informações atualizadas.
- Crawlers de indexação criam o próprio banco de dados de pesquisa de um provedor para reduzir sua dependência de terceiros.
O ponto em comum é que nenhuma dessas atividades direciona um visitante de volta ao seu site. A identificação torna a situação imprevisível. Alguns crawlers de IA usam user agents identificáveis e permanecem dentro de intervalos de IP publicados. Outros usam o user agent de um navegador legítimo, alternam os endereços de origem ou simplesmente não oferecem nenhuma forma confiável de identificação.
Em resumo, esse tráfego é mais difícil de atribuir e está crescendo rapidamente: o Radar Year in Review 2025 do Cloudflare apontou que crawlers de IA, sem incluir o Googlebot, representaram em média 4,2% das solicitações HTML, variando de 2,4% em abril a 6,4% em junho. Ao incluir o Googlebot, que agora rastreia conteúdo tanto para indexação de pesquisa quanto para treinamento de IA, o rastreamento total relacionado à IA chegou a cerca de 8,7% das solicitações HTML em 2025.
As normas de rastreamento estabelecidas pelos crawlers de mecanismos de pesquisa
Para entender essa mudança, é útil observar como funcionava o acordo anterior. O rastreamento para mecanismos de pesquisa seguia um conjunto de convenções compartilhadas que permitia aos proprietários de sites planejar sua infraestrutura de acordo com esse comportamento. O Robots Exclusion Protocol surgiu em 1994 e foi formalizado como um padrão da internet em 2022. A partir dele, surgiram quatro comportamentos que tornaram os crawlers tradicionais previsíveis o suficiente para que a infraestrutura pudesse ser preparada para eles:
- Respeito ao
robots.txt. Um crawler lia o arquivo, identificava quais caminhos estavam fora dos limites e não os acessava. - Limitação automática da taxa de rastreamento. Os principais crawlers reduziam a frequência das solicitações quando um servidor apresentava sinais de sobrecarga, de modo que um site com dificuldades recebia menos solicitações, em vez de mais.
- Identificação consistente. Um user agent estável permitia verificar um crawler e decidir como tratá-lo.
- Operação dentro de um “crawl budget”. O Google define o crawl budget de um site como o conjunto de URLs que o Googlebot pode e deseja rastrear. Isso evita que um único site seja rastreado sem limites.
Relacionado a isso está o “crawl delay”: o tempo que um crawler espera entre as solicitações de páginas. No entanto, essa é uma diretiva não oficial, portanto, o Google nunca ofereceu suporte a ela e não a incluiu no padrão formalizado. Em vez disso, o Googlebot ajusta dinamicamente sua própria taxa de rastreamento com base na rapidez com que seu servidor responde. A expectativa é que um crawler perceba a situação do servidor e modere seu próprio comportamento.
Essas convenções estão incorporadas à forma como a hospedagem funciona. Por exemplo, existem camadas de cache porque crawlers bem-comportados solicitam as mesmas páginas de maneira previsível o suficiente para que elas sejam entregues a partir do cache. Todo o modelo se baseia na suposição de que os crawlers seguem as regras.
Onde os crawlers de IA quebram essas normas
Os crawlers de IA seguem regras diferentes de três maneiras:
- O
robots.txté tratado como opcional. Os relatórios da TollBit mostram aumentos drásticos no número de bots que ignoram as diretivas do robots.txt. Os mesmos relatórios descrevem o Cloudflare identificando um grande provedor de pesquisa com IA acessando conteúdo de sites que haviam proibido explicitamente esse acesso. - Não há limitação da taxa de rastreamento. Muitas implementações de crawlers de IA enviam solicitações em uma frequência alta e constante, independentemente da resposta do servidor. Parte disso nem sequer é intencional, devido a pessoas que estão “criando um bot com vibe coding… e simplesmente o colocando para funcionar” sem sequer verificar o
robots.txt. - Os crawlers ficam presos em loops. Esse é um padrão caro que ocorre por questões estruturais, e não por comportamento malicioso. A maioria dos crawlers segue todos os links que encontra e registra cada URL exclusiva como uma página separada. Os crawlers de IA seguem uma variação, que gera outra, que é seguida novamente, sem perceber que estão andando em círculos.
O problema é que a maior parte do rastreamento por IA é destinada ao treinamento de modelos, e não à pesquisa ou a consultas de usuários, o que significa que não gera tráfego de referência de volta ao seu site.
Por que isso afeta seu servidor como um problema de desempenho
O volume, por si só, não é realmente o problema. Por exemplo, uma página estática entregue a partir do cache praticamente não gera custos, portanto, mil acessos ao cache mal são percebidos. O problema começa quando o tráfego ignora o cache, e crawlers presos em loops são eficientes em encontrar essas rotas.
Em um site WordPress que usa WooCommerce, solicitações de pesquisa ou filtragem representam uma grande parcela das solicitações que chegam a endpoints dinâmicos, em vez de páginas. Normalmente, são ações de carrinho, variações do parâmetro ?add-to-cart=, páginas de produtos filtrados, consultas de pesquisa e interações baseadas em AJAX encaminhadas por meio do admin-ajax.php. Nenhuma delas pode ser armazenada em cache da mesma forma que um artigo do blog, portanto, cada solicitação força o servidor a trabalhar:
- Execução do PHP. Uma thread PHP fica reservada durante toda a duração de cada solicitação. Sob uma carga contínua de bots, as threads se esgotam e os visitantes reais precisam esperar na fila atrás dos bots.
- Consultas ao banco de dados. As páginas dinâmicas acessam o banco de dados a cada carregamento porque não há uma camada de cache para absorver a consulta.
- Processamento de sessões. As páginas de carrinho e checkout criam ou validam uma sessão a cada solicitação, adicionando sobrecarga mesmo para bots que nunca comprarão nada.
Com base nos dados da infraestrutura da Kinsta, um único bot gerou 3,75 milhões de solicitações para URLs add-to-cart em 24 horas. Isso equivale a aproximadamente uma solicitação a cada 23 milissegundos durante todo o dia. Os sintomas aparecem como anomalias de uso, consumo excedente de largura de banda, processos PHP esgotados e tempos de resposta mais lentos para usuários reais. Como resultado, isso parece um rastreamento comum, e não um ataque, o que torna o problema fácil de ignorar.
Como identificar a atividade de crawlers de IA no MyKinsta
Antes de começar a alterar as configurações, você precisa confirmar se os crawlers são a causa. O MyKinsta oferece três visualizações que, analisadas em conjunto, transformam uma suspeita em um diagnóstico.
Primeiro, acesse Sites > nome do site > Proteção contra bots no MyKinsta. Nessa tela, o gráfico Detalhamento de solicitações mostra todas as solicitações feitas ao seu site nas últimas 24 horas e como a Kinsta classifica cada uma delas.
A categoria Crawlers de IA com taxa excessiva isola os bots que geram um volume de solicitações alto o suficiente para ameaçar o desempenho. Quando uma grande parte do gráfico está nessa categoria, você está diante de uma carga gerada por crawlers, e não de um aumento real no número de leitores.
O gráfico Resultados da Proteção contra bots mostra o que aconteceu com o tráfego, dividindo-o entre solicitações permitidas, submetidas a verificação ou bloqueadas. Isso permite ver quanto tráfego automatizado está chegando ao seu site e quanto está sendo filtrado antes de chegar até ele. Lado a lado, esses gráficos permitem entender se a carga já está sendo controlada ou se está chegando diretamente ao seu servidor.
Para relacionar o tráfego à lentidão, verifique a lista Principais IPs de clientes em Análises no MyKinsta:
Essa lista mostra os endereços que enviam mais solicitações, e cada IP contém um link para um serviço de consulta que permite verificar sua origem. Por fim, abra a aba Desempenho e compare os picos no tempo de resposta com os períodos de rastreamento intenso. Caso os picos no uso de recursos e o volume de bots aumentem e diminuam ao mesmo tempo, você saberá que o próximo passo é controlar o tráfego recebido.
Como gerenciar crawlers de IA com a Proteção contra bots da Kinsta
Após confirmar a origem, a Proteção contra bots da Kinsta oferece controle sobre cada categoria de tráfego. Ela funciona em conjunto com as proteções da plataforma que já filtram tráfego claramente malicioso e está incluída em todos os planos.
O painel Nível de proteção na tela Proteção contra bots do MyKinsta oferece quatro configurações:
- Bloquear tráfego malicioso é a configuração padrão. Ela realiza a mitigação de DDoS e bloqueia IPs e endpoints associados a fontes de ataques conhecidas.
- Bloquear automações adiciona uma camada que bloqueia tráfego automatizado confirmado, enquanto permite a passagem de bots verificados e visitantes reais.
- Aplicar verificação a bots adiciona uma etapa de verificação para prováveis bots. Um visitante que passa pela verificação não precisa realizá-la novamente por dez dias no mesmo navegador e endereço IP.
- Aplicar verificação a todos é a configuração mais rigorosa e permite a passagem apenas de bots verificados. Essa configuração deve ser usada por um curto período durante um pico de tráfego ativo.
Em Aplicar verificação a bots ou níveis superiores, qualquer ferramenta que se conecte ao seu site de forma programática e não esteja no diretório de bots verificados do Cloudflare estará sujeita a verificação ou bloqueio. Portanto, confirme se as ferramentas essenciais para sua empresa aparecem nessa lista antes de aumentar o nível de proteção.
A Kinsta aplica suas próprias regras sobre a lista de bots verificados do Cloudflare. Isso significa que ela reclassifica bots de IA verificados que geram um alto volume de solicitações na categoria separada Crawlers de IA com taxa excessiva.
A lógica é avaliar um crawler pelo seu comportamento, e não por suas credenciais, portanto, um bot verificado que começa a sobrecarregar seu site passa a ser tratado como o problema que se tornou. Ao definir a proteção como Aplicar verificação a bots ou um nível superior, um serviço legítimo com alto volume de solicitações pode comprovar sua legitimidade, enquanto crawlers presos em loops são filtrados.
Outras funcionalidades da Proteção contra bots no MyKinsta
O botão de alternância Bloquear crawlers de IA é um controle separado do nível de proteção que atua especificamente sobre crawlers de IA, incluindo os verificados, como o GPTBot. O Googlebot e o Bingbot continuam indexando seu site normalmente, portanto, essa opção elimina a carga dos crawlers de IA sem afetar sua visibilidade nos mecanismos de pesquisa.
Essa é uma opção mais simples do que editar manualmente o robots.txt ou manter regras individuais para cada bot, mas vale a pena considerar as consequências antes de habilitá-la.
Bloquear crawlers de IA reduz a frequência com que seu conteúdo aparece em respostas e resumos gerados por IA e, à medida que as ferramentas de IA se tornam um canal de descoberta mais importante para alguns públicos, optar pelo bloqueio completo tem implicações que vão além da carga do servidor.
Para sites que priorizam o desempenho, como lojas WooCommerce, sites de conteúdo com alto tráfego e plataformas de membros, o custo de recursos causado pelo rastreamento por IA é alto e o retorno é baixo, portanto, o bloqueio pode ser a opção mais adequada caso você identifique problemas. Para sites que priorizam conteúdo e nos quais a visibilidade em IA é uma prioridade estratégica, permanecer em Bloquear automações ou Aplicar verificação a bots filtra os piores comportamentos e mantém seu conteúdo indexável por plataformas de IA.
Não existe uma resposta certa para todos os casos. O botão de alternância existe para oferecer essa escolha.
Uma proteção mais rigorosa pode afetar o tráfego automatizado do qual você depende, portanto, duas configurações garantem que ele continue funcionando. A seção Sempre permitir permite adicionar até 50 exceções por endereço IP, caminho ou user agent. É nela que você adiciona os itens que nunca devem passar por uma verificação, como um serviço de monitoramento, um webhook de pagamento ou um IP confiável do escritório ou de um cliente.
Permitir automações comuns do WordPress habilita uma lista de permissões gerenciada de endpoints e serviços comuns do WordPress, incluindo a REST API e tarefas em segundo plano. Habilite essa opção junto com uma proteção mais rigorosa quando seu site depender de plugins, integrações ou tarefas agendadas que fazem solicitações automatizadas, evitando que o aumento da proteção interrompa silenciosamente um fluxo de trabalho.
As novas regras de rastreamento da web exigem um gerenciamento mais atento
Embora o comportamento na internet tenha mudado, sua hospedagem provavelmente não mudou. Os crawlers de IA não seguem as mesmas regras que os mecanismos de pesquisa passaram duas décadas estabelecendo. O robots.txt é tratado como opcional e o rastreamento ocorre em uma frequência alta e constante. Além disso, você não recebe nada em troca dos recursos utilizados. Isso cria um problema de desempenho e custos que parece ser causado por dificuldades do próprio site, e não pela atividade de crawlers.
A solução é uma sequência curta de ações que está sob seu controle. Primeiro, confirme a causa nas Análises do MyKinsta. Em seguida, defina o Nível de proteção adequado no MyKinsta e habilite Bloquear crawlers de IA para eliminar a carga dos crawlers de IA sem perder visibilidade nos mecanismos de pesquisa. Depois, proteja os serviços dos quais você depende usando Sempre permitir, para que configurações mais rigorosas não interrompam uma integração confiável. Cada alteração entra em vigor sem tempo de inatividade, permitindo ajustar as configurações à medida que os padrões mudam.
Caso gerencie muitos sites de clientes, o Programa de Agência Parceira da Kinsta reúne esses controles com suporte dedicado. Conheça a hospedagem gerenciada para WordPress da Kinsta para colocar esse controle em prática.
