Adicionar como fonte preferencial no Google
Os bots agora geram mais tráfego na web do que os humanos, mas o mais interessante é o tipo de bot responsável por essas interações. Além disso, vale a pena analisar o que esses bots fazem quando chegam ao seu site.
As discussões sobre tráfego de IA geralmente se concentram em crawlers que coletam seu conteúdo para treinar um modelo, consumindo seus recursos. No entanto, há uma segunda categoria: agentes de IA que acessam seu site em nome de uma pessoa para ler o conteúdo e interagir como um cliente faria. Isso pode gerar receita, mas a tecnologia atual, sem os devidos ajustes, bloqueia os dois tipos de bots, em vez de bloquear apenas aqueles que consomem muitos recursos.
Conheça o visitante que lê como um bot e compra como um cliente
Durante a maior parte da história da internet, um site WordPress recebeu três tipos de visitantes: humanos, crawlers de mecanismos de pesquisa e scripts que executam tarefas repetitivas.
Os agentes de IA agora representam um quarto tipo. Eles leem a estrutura de uma página como um crawler, mas interagem como um ser humano. Para um agente de IA, é relativamente simples verificar o preço de um produto, compará-lo e concluir a compra.
Diante disso, os bots agênticos merecem sua atenção. Os dados de tráfego do Cloudflare agora mostram, pela primeira vez, que as solicitações automatizadas superam as solicitações feitas por humanos. Dentro dessa parcela automatizada, a pesquisa State of AI Traffic, da HUMAN Security, constatou que o tráfego proveniente de agentes de IA e navegadores agênticos cresce em um ritmo muito superior ao de todas as outras categorias.
Na verdade, os agentes de IA já estão presentes em alguns produtos populares:
- O recurso integrado de navegação automática do Chrome pesquisa, compara e conclui tarefas com várias etapas, como processos de checkout nos sites que você acessa.
- O agente de navegação da OpenAI, disponível no aplicativo ChatGPT e em sua extensão para o Chrome, navega pelas páginas e conclui tarefas em nome de uma pessoa.
- O navegador Comet, da Perplexity, lê o conteúdo das abas abertas de uma pessoa para pesquisar e realizar ações em seu nome. Ele está disponível para download gratuito.
- O Claude for Chrome (extensão para navegador da Anthropic) navega, clica e preenche formulários em nome de uma pessoa.
Esses e muitos outros já estão gerando tráfego real em seu site, mas as configurações criadas para bloquear crawlers de treinamento não foram desenvolvidas pensando neles.
O tráfego proveniente de IA converte melhor do que o tráfego humano
Os dados de varejo da Adobe referentes ao primeiro trimestre de 2026, baseados em mais de um trilhão de visitas a sites de varejo dos Estados Unidos, revelam um cenário que seria impossível prever um ano atrás.
Em março de 2025, o tráfego proveniente de IA apresentava uma taxa de conversão 38% menor do que a de canais convencionais, como pesquisa paga e e-mail. Em março de 2026, esse mesmo tráfego apresentava uma taxa de conversão 42% maior. Isso representa uma virada de 80 pontos percentuais em doze meses. Os compradores encaminhados por IA também geraram 37% mais receita por visita do que o tráfego não proveniente de IA, permaneceram 48% mais tempo no site e acessaram 13% mais páginas por visita. Somente no primeiro trimestre de 2026, o volume de tráfego proveniente de fontes de IA cresceu 393% em relação ao ano anterior.
A razão está no comportamento. Uma pessoa que chega por meio da pesquisa orgânica pode estar em qualquer etapa da decisão de compra. Um agente enviado ao seu site já recebeu uma tarefa específica.
É esse o tráfego que lojas WooCommerce, plataformas de assinatura e formulários de orçamento ou reserva querem captar:
- Compradores que pesquisam um plugin enviarão um agente para verificar seus preços e apresentar uma recomendação ao comprador.
- Uma pessoa que verifica a cobertura de um serviço pede a um agente que preencha seu formulário de orçamento e aguarde uma resposta.
- Compradores que comparam níveis de assinatura permitem que um agente conclua o cadastro após o término da comparação.
Agora, cada uma dessas tarefas pode ser concluída do início ao fim por um agente, desde que seu site permita que o agente as execute.
O Cloudflare divide o bloqueio de bots de IA em três categorias
As camadas de infraestrutura estão começando a acompanhar essa evolução. A configuração atual do Cloudflare substitui o antigo controle único para bots de IA por três categorias que podem ser controladas de forma independente e estão disponíveis para todos os clientes.
- Search abrange crawlers que indexam seu conteúdo para que ele possa ser exibido posteriormente em uma resposta gerada por IA, geralmente direcionando algum tráfego de volta ao seu site.
- Training abrange crawlers que coletam seu conteúdo para criar ou ajustar um modelo, sem gerar tráfego de retorno nem apresentar intenção de realizar transações.
- Agent abrange o tráfego em tempo real direcionado pelo usuário, que atua em nome de uma pessoa específica, incluindo sessões que concluem processos de checkout.
Por padrão, o Cloudflare bloqueia Training e Agent em páginas que exibem anúncios, enquanto Search permanece ativado. Os sites existentes manterão as configurações atuais, a menos que você as altere. No entanto, crawlers com várias finalidades, incluindo o Googlebot, são avaliados de acordo com a regra mais rigorosa aplicável. Portanto, um bloqueio geral de Training pode acabar afetando também a visibilidade do seu site nos mecanismos de pesquisa.
A Proteção contra Bots da Kinsta já toma esse tipo de decisão por você. Atualmente, ela agrupa os crawlers de IA em um único controle, em vez de reproduzir a divisão em três categorias específica do painel de controle do Cloudflare. No entanto, você precisa saber como trabalhar com os recursos disponíveis.
3 fatores que determinam se um agente concluirá seu checkout
A conclusão de uma tarefa por um agente em seu site depende de três fatores, todos relacionados à infraestrutura, e não ao conteúdo. Em relação a grande parte desses fatores, as funcionalidades e a infraestrutura da Kinsta podem ser vantajosas.
Os preços e a disponibilidade precisam estar no HTML
Um agente lê a estrutura subjacente de uma página, e não seu layout visual. Quando o preço aparece somente após um clique ou a quantidade em estoque é carregada por meio de uma chamada AJAX após a renderização, um agente que utiliza a árvore de acessibilidade não consegue encontrar essas informações.
No entanto, existem diferentes níveis de eficiência nesse processo. Por exemplo, um estudo que testou um agente de IA em tarefas reais na web constatou que ele obteve sucesso em quase 80% dos casos. Com uma interação realizada apenas pelo teclado, que simula a navegação de uma pessoa que utiliza um leitor de tela, a taxa de sucesso caiu para 42%.
Quando você sabe o que procurar, os problemas mais comuns são previsíveis:
- Seções de perguntas frequentes em formato de acordeão ocultam as respostas até que sejam acionadas por um clique que o agente talvez nunca realize.
- Tabelas de preços com abas geralmente renderizam o conteúdo de somente uma aba na marcação inicial da página.
- Indicadores de estoque carregados por JavaScript podem ainda não existir quando um agente lê a página.
O padrão WebMCP proposto pelo Google é uma tentativa de corrigir esse problema no nível do navegador. Ele permite que um site exponha diretamente suas funções de checkout e preços, em vez de deixar que um agente as deduza com base na página. No entanto, o padrão ainda está em uma fase inicial de testes. Por isso, o HTML semântico é atualmente a solução mais confiável.
Sua página precisa responder antes que o tempo limite do agente se esgote
Um agente que executa uma tarefa com várias etapas não espera que uma página lenta responda como uma pessoa talvez faria. Em vez disso, ele simplesmente abandona a página que não responde, fazendo você perder uma conversão.
Os limites das Principais Métricas da Web são uma referência razoável para avaliar o que um agente pode tolerarr, embora tenham sido desenvolvidos com base na experiência humana em uma página. Um Largest Contentful Paint inferior a 2,5 segundos oferece tempo suficiente para que tanto uma pessoa quanto um agente concluam uma tarefa na mesma sessão.
Além disso, tentar adivinhar como corrigir páginas lentas pode fazer você desperdiçar todo o tempo que pretende economizar. Nesse caso, você pode usar a ferramenta APM da Kinsta para analisar uma página de checkout ou de produto e identificar se o atraso é causado por um plugin, uma consulta ao banco de dados ou uma chamada específica de terceiros.
Após iniciar um período de monitoramento, a visualização Transações mostra qual página ou endpoint está lento. Assim, você pode identificar o plugin ou a consulta responsável, corrigir o elemento certo e economizar tempo, ajudando os agentes a permanecer no site e concluir suas tarefas.
Suas configurações de Proteção contra Bots precisam permitir a passagem das sessões que geram conversões
Se suas configurações de proteção contra bots tratarem todos os visitantes automatizados como crawlers de treinamento, os bots adequados talvez nem sequer consigam acessar seu site. Essas sessões de bots podem parecer iguais para um sistema que não consegue diferenciá-las.
Por isso, a Proteção contra Bots da Kinsta oferece quatro controles separados para você tomar essa decisão:
- Quatro níveis de proteção, que variam de Bloquear tráfego malicioso a Desafiar todos, controlam o rigor com que o tráfego não classificado e provavelmente proveniente de bots é desafiado em todo o site.
- O controle específico Bloquear crawlers de IA elimina imediatamente o tráfego de crawlers de IA, incluindo sessões de Agent que concluem processos de checkout e crawlers de Training.
- Permitir automações típicas do WordPress mantém sua API REST, integrações de plugins e tarefas em segundo plano em execução, mesmo com um nível de proteção mais rigoroso. Isso é importante para sessões de agentes que acessam seus endpoints de checkout e da API.
- As exceções em Sempre permitir, que podem ser adicionadas por IP, caminho ou user agent, permitem especificar o tráfego que nunca deve ser bloqueado nem desafiado, independentemente do nível de proteção.
Uma solução intermediária prática para uma loja WooCommerce ou um site de reservas é ativar Permitir automações típicas do WordPress para impedir que o tráfego do checkout e da API REST seja desafiado por um nível de proteção mais rigoroso. Também é recomendável tratar Bloquear crawlers de IA como uma ferramenta temporária de diagnóstico, em vez de manter essa configuração permanentemente ativada.
Se você pretende bloquear especificamente os crawlers de treinamento sem perder compras realizadas por agentes, as exceções em Sempre permitir para user agents de agentes conhecidos oferecem mais precisão do que o controle isoladamente.
Verifique o que está acontecendo no seu site pelo MyKinsta
Antes de alterar qualquer configuração, é importante verificar como é o tráfego do seu site, em vez de presumir que você já processa corretamente as sessões de agentes. O MyKinsta oferece alguns locais para fazer essa verificação.
Primeiro, a tela Sites > [nome do site] > Proteção contra bots reúne dois conjuntos de informações em um único gráfico. O Detalhamento das solicitações mostra todas as solicitações recebidas pelo site nas últimas 24 horas, separadas em diferentes classificações. Assim, você pode identificar as proporções e a distribuição do tráfego recebido.
O gráfico Resultados da proteção contra bots mostra como esse tráfego foi processado: permitido, desafiado ou bloqueado:
O Detalhamento das solicitações basicamente permite cruzar os próprios dados. Por exemplo, se uma parcela do seu tráfego automatizado estiver sendo desafiada ou bloqueada, você poderá ver a correspondência desses dados com a categoria Crawlers de IA. No entanto, não será possível determinar se são crawlers de treinamento ou sessões de agentes que geram conversões.
Nesse caso, você pode comparar as variações do tráfego bloqueado com as variações do volume de pedidos ou leads do mesmo período. Uma queda em um deles acompanhada por um aumento no outro indica que sessões legítimas de agentes podem estar sendo retidas.
Teste seu checkout sem JavaScript
Um agente que utiliza a estrutura subjacente de uma página tem uma experiência semelhante à de uma pessoa que usa um leitor de tela. Dois testes rápidos podem mostrar onde o processo é interrompido.
Primeiro, abra o DevTools no navegador e acesse Settings > Debugger. Em seguida, marque Disable JavaScript. Depois, recarregue a página e tente adicionar um item ou acessar o checkout.
Falhas ou erros indicam que a etapa depende de um script que talvez nunca seja executado. Por exemplo, um botão Adicionar ao carrinho criado como uma <div> clicável geralmente não apresenta um comportamento alternativo sem seu script.
Você também pode executar um verificador de acessibilidade, como o axe ou o WAVE, no mesmo processo de checkout. Rótulos ausentes, campos ocultos ou botões inacessíveis não ficarão visíveis para um agente. Com os dois testes, você terá uma lista específica dos elementos que precisam ser corrigidos.
Monitore os tempos de resposta sob carga simultânea
Uma sessão de agente que abre várias abas ou verifica diversas páginas de produtos em rápida sucessão se parece mais com um pequeno pico de tráfego simultâneo. Muitas verificações de desempenho não detectam esse tipo de padrão de carga. Por isso, um teste com uma única solicitação pode ser concluído sem identificar nenhum problema.
Na seção Análises do MyKinsta (Sites > nome do site > Análises > Desempenho), consulte o Tempo médio de resposta do PHP + MySQL. Essa informação, junto à lista detalhada na parte inferior da tela, pode ajudar você a encontrar os caminhos mais lentos do site, em vez de mostrar apenas uma média geral que oculta o problema.
Em seguida, execute a ferramenta APM e execute simultaneamente várias sessões que acessem os endpoints do carrinho e da pesquisa. Assim, você poderá identificar onde o tempo de resposta começa a aumentar.
Se o gráfico Limite de threads PHP, na seção Desempenho de Análises, mostrar que seu site está atingindo o limite, você poderá corrigir o problema. Aumentar a alocação de threads PHP em Sites > [nome do site] > Informações > Desempenho do PHP > Alterar é uma maneira simples de oferecer ao site mais capacidade para processar várias sessões de agentes simultaneamente.
O tráfego de agentes deixou de ser apenas ruído de bots e se tornou um canal completo
Para crawlers de treinamento, bloqueá-los e recuperar os recursos consumidos ainda é a medida correta. No entanto, isso não se aplica aos agentes de IA que concluem processos de checkout. Portanto, você precisa aproveitar todas as ferramentas disponíveis para filtrar os bots corretamente.
A solução é verificar se os dados de preços e estoque são renderizados no HTML inicial da página. Rastrear as páginas mais lentas e revisar as configurações da proteção contra bots permite processar o tráfego existente com precisão e utilizar os recursos do servidor com eficiência.
Para entender como a Proteção contra Bots, o APM e a integração da Kinsta com o Cloudflare trabalham em conjunto para manter sua infraestrutura preparada para os dois tipos de visitantes, conheça a hospedagem gerenciada para WordPress da Kinsta.
