A Kinsta analisou mais de 10 bilhões de solicitações HTTP em sua infraestrutura de hospedagem e descobriu que bots acessaram URLs de adição ao carrinho em sites WordPress 7,67 milhões de vezes em um único período de 24 horas. Apenas um crawler gerou 550 milhões de solicitações ao longo de 30 dias antes que uma regra o bloqueasse.
Nenhuma dessas solicitações gerou conversões. Nenhuma delas direcionou um visitante de volta ao site. Elas simplesmente continuaram chegando ao acessar páginas de carrinho, URLs de produtos filtrados, consultas de pesquisa e endpoints AJAX, cada uma forçando o servidor a executar PHP, realizar uma consulta ao banco de dados e processar uma sessão para um tráfego que jamais se tornaria cliente.
Os sites que absorviam essa carga não estavam fora do ar. As páginas carregavam. O checkout funcionava. Por todas as métricas convencionais, eles pareciam estar funcionando normalmente. É sobre esse problema que este artigo trata.
O tráfego de bots não é mais apenas um ruído de fundo
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 quem gerencia sites WordPress, a mudança prática é mais específica do que uma porcentagem. O tráfego de bots atual não se resume aos crawlers de mecanismos de pesquisa fazendo seu trabalho. Ele inclui crawlers de treinamento de IA, ferramentas de scraping, bots de auditoria de SEO, monitores de tempo de atividade, user agents falsos e ferramentas de IA agêntica que seguem links de forma muito mais agressiva do que os crawlers tradicionais jamais fizeram.
Alguns indexam conteúdo. Alguns fazem scraping. Alguns testam endpoints. Outros tratam cada combinação de parâmetros de URL como uma página distinta e rastreiam cada uma delas.
Esse último comportamento é particularmente caro para o WordPress. Uma página de produto com filtros de cor, tamanho, ordenação, paginação e estoque aparece como uma única página para um visitante humano. Um bot pode identificar centenas de URLs exclusivas e rastrear cada uma delas.
O tráfego de bots orientado por IA aumentou 300% em um ano. No final de 2025, os bots de IA representavam 1 em cada 31 visitas na web na rede da TollBit, em comparação com 1 em cada 200 no início do ano. A tendência está definida. O que ainda é subestimado é quanto esse tráfego realmente custa.
A largura de banda é o custo mais evidente
A largura de banda corresponde aos dados que seu site transfere quando alguém solicita uma página, imagem, script, arquivo ou outro recurso. Visitantes humanos a utilizam. Os bots também, e depois não compram nada.
Um crawler que acessa um artigo do blog uma vez não é um problema. Um bot que rastreia repetidamente arquivos, páginas de etiquetas, imagens, feeds, scripts e URLs filtradas pode consumir uma quantidade significativa de largura de banda sem gerar qualquer valor para a empresa.
De acordo com os dados de 2025 do Cloudflare, citados no Relatório de Tráfego de IA e Bots da Kinsta, 80% da atividade de rastreamento por IA é destinada ao treinamento de modelos, e não a pesquisas ou consultas iniciadas por usuários, e não gera tráfego de referência de volta ao site. Para sites WordPress com grande volume de conteúdo, essa dinâmica transforma páginas de alto valor em recursos de alto custo.
O problema é que o desperdício de largura de banda muitas vezes aumenta sem causar um problema visível de desempenho. O site continua carregando. O servidor continua respondendo. Mas o consumo continua aumentando porque o tráfego automatizado segue solicitando páginas e recursos de que nenhum visitante humano precisa.
Quando o custo da largura de banda se torna evidente, o site pode já ter passado dias ou semanas atendendo a um tráfego que nunca trouxe qualquer benefício para a empresa.
A carga no backend é o custo mais difícil de identificar
Nem todas as solicitações têm o mesmo custo de processamento. Um artigo do blog armazenado em cache é relativamente barato, pois o servidor retorna uma versão armazenada e segue em frente. As solicitações dinâmicas funcionam de outra forma.
Quando um bot acessa uma ação do carrinho do WooCommerce, uma página de produto filtrada, uma URL de consulta de pesquisa, uma página de login ou um endpoint AJAX, o servidor não pode usar o cache. Ele precisa realizar o processamento a cada solicitação:
- Execução do PHP — uma thread fica reservada durante toda a duração da solicitação
- Consultas ao banco de dados — a página acessa o banco de dados a cada carregamento, sem que o cache absorva essa carga
- Processamento de sessões — as páginas de carrinho e checkout criam ou validam uma sessão por solicitação, mesmo para bots que nunca concluirão uma compra
- Lógica de plugins — qualquer plugin conectado a essas solicitações executa seu código a cada acesso
- Solicitações que ignoram o cache — a solicitação nunca entra no cache, portanto, futuras solicitações idênticas terão o mesmo custo novamente
É nesse ponto que o tráfego de bots se torna mais caro do que parece. O problema não é apenas a quantidade de dados que um bot baixa. É a quantidade de trabalho que a infraestrutura realiza antes de enviar esses dados de volta.
Os dados da infraestrutura da Kinsta deixam clara a dimensão do problema: bots acessaram URLs de adição ao carrinho 7,67 milhões de vezes em um único período de 24 horas, incluindo 3,75 milhões de solicitações somente do ClaudeBot. Cada uma foi tratada como uma nova solicitação no servidor. Cada uma acionou a execução do PHP e uma consulta ao banco de dados. Nenhuma atendeu a um cliente.
Como afirmou Daniel Pataki, CTO da Kinsta, no lançamento: “A maioria das orientações sobre gerenciamento de bots se resume a ‘bloqueie tudo’ ou ‘não faça nada’. Nenhuma dessas abordagens funciona em escala.”
Por que “não tivemos tempo de inatividade” não é o ponto principal
Tempo de atividade significa que o site permanece on-line. Isso não significa que o site esteja operando de forma eficiente.
Um site WordPress pode absorver uma quantidade significativa de tráfego desnecessário antes que os visitantes percebam algum problema. As páginas continuam carregando. O checkout continua funcionando. As telas de administração continuam respondendo. Mas a infraestrutura continua processando cada solicitação de bot que acessa um endpoint dinâmico, e esse processamento tem um custo real, mesmo quando o site parece estável.
Esse custo se manifesta de maneiras menos evidentes do que uma interrupção:
- Maior consumo de largura de banda, aproximando-se gradualmente dos limites do plano
- Mais pressão sobre as threads PHP e as conexões com o banco de dados
- Menos recursos disponíveis quando picos de tráfego real exigem esses mesmos recursos
- Análises distorcidas que confundem sessões de bots com engajamento humano
- Resultados de testes A/B e taxas de conversão distorcidos por tráfego que nunca teve a intenção de converter
- Decisões de infraestrutura tomadas com base em dados que não refletem o comportamento real do público
- Maior dificuldade para solucionar problemas quando o ruído da atividade de bots dificulta a identificação de problemas reais de desempenho
É por isso que “nenhum tempo de inatividade” pode dar às equipes uma falsa sensação de segurança. O site parece estável porque a infraestrutura absorve o trabalho adicional. Absorver esse desperdício ainda tem um custo; ele apenas não se manifesta de forma evidente.
Por que as agências devem resolver isso antes que os clientes percebam
Normalmente, as agências só ficam sabendo do tráfego de bots depois que ele já causou um problema visível. Um cliente percebe um aumento no uso da hospedagem, telas de administração mais lentas, lentidão no checkout, padrões de tráfego incomuns ou análises que não correspondem mais aos resultados da empresa. Nesse ponto, a conversa se torna reativa. A agência precisa explicar o que aconteceu, por que isso é importante e quais mudanças precisam ser feitas.
O tráfego de bots permite que as agências tenham uma conversa proativa.
A abordagem não precisa ser alarmista. Ela pode permanecer prática:
- “Seu site pode estar apresentando um bom desempenho, mas parte desse tráfego pode não vir de visitantes reais.”
- “Algumas atividades de bots são úteis, como crawlers de mecanismos de pesquisa e ferramentas de monitoramento, mas outras apenas consomem recursos.”
- “Podemos reduzir o desperdício sem afetar o tráfego que realmente importa.”
- “Fazer isso corretamente preserva os recursos disponíveis para lidar com picos de tráfego e ajuda a manter o uso previsível.”
Isso relaciona o gerenciamento de bots a questões que os clientes já entendem: custo, eficiência e confiabilidade. Também reposiciona a agência, que deixa de apenas solucionar problemas de forma reativa e passa a atuar como consultora proativa de infraestrutura, criando uma relação mais duradoura.
O objetivo não é bloquear todos os bots
É importante observar que nem todo tráfego de bots é ruim. Crawlers de mecanismos de pesquisa ajudam as páginas a aparecer nos resultados de pesquisa. Ferramentas de monitoramento verificam o tempo de atividade. Plataformas de SEO auditam páginas. Provedores de pagamento, integrações, APIs e automações do WordPress também podem precisar acessar o site para realizar tarefas legítimas.
Os crawlers de IA são mais complexos. Alguns proprietários de sites podem querer visibilidade em experiências baseadas em IA. Outros podem decidir que o rastreamento por IA gera mais custos do que benefícios, especialmente quando faz scraping de grandes bibliotecas de conteúdo sem gerar um volume significativo de tráfego de referência de volta ao site.
É por isso que o objetivo não é bloquear todas as solicitações automatizadas. O bloqueio excessivo pode causar problemas de SEO, interromper integrações e o monitoramento ou interferir nos fluxos de trabalho normais do WordPress.
Uma abordagem melhor é o controle seletivo:
- Permitir tráfego útil
- Bloquear automações que claramente desperdiçam recursos
- Aplicar verificação a tráfego suspeito
- Proteger caminhos que consomem muitos recursos
- Monitorar os resultados
Isso oferece às equipes mais controle sem tratar todos os bots da mesma maneira. O objetivo é reduzir o desperdício e, ao mesmo tempo, preservar o tráfego, as ferramentas e os fluxos de trabalho que continuam contribuindo para a empresa.
Como a Proteção contra bots da Kinsta lida com isso na prática
Quando o tráfego de bots se torna um problema de infraestrutura, a resposta precisa estar de acordo com a situação real do site.
A Proteção contra bots no MyKinsta foi desenvolvida para lidar com essa variabilidade. Ela está incluída em todos os planos sem custo adicional, funciona no nível do ambiente e entra em vigor imediatamente quando as configurações são alteradas.
Níveis de proteção
Acesse Sites > nomedosite > Proteção contra bots > Alterar para escolher entre 4 níveis predefinidos, cada um aplicado de forma independente por ambiente, permitindo usar configurações diferentes nos ambientes de teste, desenvolvimento e produção.
- Bloquear tráfego malicioso — a configuração padrão em todos os sites. Realiza a mitigação de DDoS e bloqueia IPs e endpoints associados a padrões de ataque conhecidos. Todos os sites da Kinsta já contam com essa proteção.
- Bloquear automações — o ponto de partida recomendado para a maioria dos sites que enfrentam carga causada por bots. Bloqueia tráfego automatizado confirmado e tráfego malicioso, enquanto permite a passagem de bots verificados e visitantes reais. É eficaz para sites que recebem acessos repetitivos a URLs dinâmicas sem a necessidade de aplicar verificações ao tráfego de visitantes reais.
- Aplicar verificação a bots — adiciona uma etapa de verificação para prováveis bots e tráfego não classificado. Um visitante que passa pela verificação não precisa realizá-la novamente por dez dias no mesmo navegador e IP. É útil durante picos de tráfego, eventos promocionais ou períodos de scraping ativo em que é necessário equilibrar com mais precisão o bloqueio e o impacto sobre os visitantes.
- Aplicar verificação a todos — a configuração mais rigorosa, desenvolvida para uso de curto prazo durante um ataque ativo ou abuso contínuo. Todo o tráfego não verificado passa por uma verificação, incluindo prováveis visitantes humanos. Não é uma configuração permanente.
Antes de aumentar o nível acima de Bloquear tráfego malicioso, verifique se as integrações essenciais para sua empresa aparecem no diretório de bots verificados do Cloudflare. 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 seja verificada estará sujeita a verificação ou bloqueio.
Controle sobre Crawlers de IA
O botão de alternância Controle sobre Crawlers de IA é um controle separado do nível de proteção. Ele atua especificamente sobre crawlers de IA, incluindo os verificados, como o GPTBot, sem afetar o Googlebot e o Bingbot. A indexação nos mecanismos de pesquisa continua normalmente.
Para sites com grande volume de conteúdo, editoras, bibliotecas de documentação e portais de conteúdo premium nos quais crawlers de IA acessam repetidamente artigos, páginas de arquivos e recursos não armazenados em cache em grande volume, esse controle elimina essa carga sem afetar a visibilidade nos mecanismos de pesquisa.
Existe uma desvantagem que deve ser considerada: bloquear crawlers de IA reduz a frequência com que seu conteúdo aparece em respostas e resumos gerados por IA. Para sites em que a visibilidade em IA é uma prioridade estratégica, permanecer em Bloquear automações ou Aplicar verificação a bots pode ser uma opção mais adequada, pois essas configurações filtram os piores comportamentos e mantêm o conteúdo indexável. Para sites em que o custo dos recursos do servidor e o uso do plano são mais importantes do que a visibilidade em IA, o bloqueio é a opção mais adequada.
Permitir automações comuns do WordPress
Ao aumentar o nível de proteção acima da configuração padrão, habilite Permitir automações comuns do WordPress ao mesmo tempo.
Isso habilita uma lista de permissões gerenciada com caminhos e serviços comuns do WordPress, como solicitações da REST API, rotas do WooCommerce, tarefas em segundo plano, tarefas agendadas e integrações de plugins, para que uma filtragem de bots mais rigorosa não interrompa silenciosamente os fluxos de trabalho dos quais o site depende.
Habilite essa opção sempre que mudar para Bloquear automações ou um nível superior. O objetivo é reduzir o tráfego que desperdiça recursos, não interromper operações legítimas.
Sempre permitir
Alguns serviços nunca devem passar por verificações, independentemente do nível de proteção. A seção Sempre permitir permite adicionar até 50 exceções personalizadas por endereço IP, caminho de URL ou user agent.
Use para:
- Webhooks de provedores de pagamento (Stripe, PayPal)
- Serviços de monitoramento confiáveis (UptimeRobot, Pingdom)
- Integrações de parceiros conhecidos ou consumidores de API
- Intervalos de IPs de desenvolvedores ou escritórios
- Caminhos específicos do WordPress, como /wp-json/* ou /wp-admin/admin-ajax.php, caso ainda não estejam incluídos na lista de permissões de automações do WordPress
Detalhamento de solicitações e resultados da Proteção contra bots
É difícil otimizar o tráfego de bots quando as equipes não conseguem ver como as solicitações são classificadas ou tratadas.
Antes de ajustar qualquer configuração, verifique primeiro a tela Proteção contra bots. O gráfico Detalhamento de solicitações mostra todas as solicitações feitas ao seu site nas últimas 24 horas, classificadas em 7 categorias: Prováveis humanos, Bots verificados, Prováveis bots, Crawlers de IA, Crawlers de IA com taxa excessiva, Tráfego não classificado e Tráfego automatizado.
A questão mudou
A hospedagem sempre foi avaliada com base em uma pequena lista de resultados visíveis: o site está on-line? Ele carrega rapidamente? Os visitantes conseguem concluir o que vieram fazer?
Essas questões continuam importantes. Mas já não contam toda a história.
Um site pode permanecer on-line enquanto desperdiça largura de banda. Ele pode carregar rapidamente enquanto bots consomem as threads PHP e as conexões com o banco de dados de que os visitantes reais precisam. Ele pode passar em um teste de velocidade em uma tarde de terça-feira e depois ter dificuldades com a carga do lançamento de uma campanha na quinta-feira, porque os recursos que deveriam estar disponíveis já foram consumidos processando tráfego que nunca trouxe benefícios para a empresa.
A questão já não é apenas “O site consegue lidar com a carga?”. Agora é “Quanto dessa carga o site realmente deveria estar processando?”.
O tráfego de bots não precisa deixar um site fora do ar para gerar custos. Basta continuar acessando os caminhos que exigem processamento real e fazer isso em um volume que, em todos os painéis de controle, parece uma atividade normal.
Ter visibilidade desse tráfego e controles para agir com base no que você vê é o que muda a situação. Você não pode gerenciar o que não consegue ver e não pode agir sobre o que vê se suas únicas opções forem bloquear tudo ou não fazer nada.
Para equipes de WordPress que gerenciam sites com grande volume de conteúdo, lojas WooCommerce ou grandes portfólios de clientes, a hospedagem gerenciada para WordPress da Kinsta disponibiliza esses controles no MyKinsta, sem custo adicional, com ajustes por ambiente e sem a necessidade de abrir um ticket de suporte. Comece pelo Relatório de Tráfego de IA e Bots para ter uma visão completa do que está acessando a infraestrutura do WordPress e dos custos gerados por esse tráfego.
