O tráfego de bots costuma ser tratado como um problema de segurança ou de SEO. Mas, na infraestrutura de hospedagem para WordPress, ele se manifesta como um problema de desempenho, especificamente concentrado em um conjunto muito específico de URLs.
Nem todas as solicitações têm o mesmo custo. A diferença entre uma página estática armazenada em cache e um endpoint dinâmico não é apenas uma pequena nuance de desempenho. É a diferença entre uma solicitação que custa quase nada e uma que reserva uma thread PHP, executa uma consulta completa ao banco de dados e gera sobrecarga de sessão, independentemente de o visitante ser um cliente real ou um bot que nunca converte.
Entender por que alguns endpoints são muito mais caros do que outros é o que diferencia uma estratégia de gerenciamento de bots que realmente funciona de uma que bloqueia demais ou de menos.
Nem todas as solicitações são iguais
Quando um visitante acessa uma página típica do WordPress, como um artigo de blog, uma listagem de produtos ou uma página “sobre”, o servidor quase sempre entrega essa resposta a partir do cache.
O cache de página inteira da Kinsta lida com isso no Edge, portanto a solicitação nunca aciona o PHP nem o banco de dados do servidor.
Mas quando uma solicitação chega a um endpoint que não pode ser armazenado em cache, o servidor precisa realizar trabalho real. Uma thread PHP é alocada e mantida durante toda a duração da solicitação, e o banco de dados é consultado. Se a página envolver estado do carrinho, sessões de usuários ou conteúdo personalizado, o gerenciamento de sessão adiciona outra camada de processamento. Nada disso pode ser armazenado em cache, porque a resposta é exclusiva para cada solicitação.
Em um site saudável, com a maioria dos visitantes sendo humanos, isso não é um problema. Seus endpoints dinâmicos atendem clientes reais que adicionam itens ao carrinho, finalizam compras e pesquisam produtos. A carga é proporcional ao uso real.
O tráfego de bots quebra esse modelo. Um crawler não adiciona itens ao carrinho nem converte, mas aciona a mesma execução no servidor que um cliente real acionaria, em uma frequência que nenhum ser humano conseguiria manter.
Os endpoints específicos onde isso causa impacto
Em uma loja do WooCommerce, os seguintes padrões de URL e endpoints não podem ser armazenados em cache por design, e são exatamente os alvos mais frequentes do tráfego de bots.
?add-to-cart=
Este é o exemplo mais intensivo em recursos que documentamos em nosso relatório sobre tráfego de IA e bots. Adicionar um produto ao carrinho exige execução de PHP, gravação no banco de dados e criação ou validação de sessão. Não existe uma versão em cache dessa resposta, pois cada solicitação exige processamento novo.
Para colocar isso em perspectiva: os dados de infraestrutura da Kinsta registraram, em determinado momento, 7,67 milhões de acessos a URLs de adicionar ao carrinho provenientes de cinco bots durante uma janela de 24 horas.
Isso equivale a aproximadamente uma solicitação a cada 11 milissegundos, durante todo o dia e toda a noite, cada uma exigindo execução completa de PHP e banco de dados, sem gerar nenhum resultado útil para o crawler e sem atender nenhum cliente.
/cart e /checkout
Essas páginas são excluídas do cache de página por padrão no WooCommerce. Elas contêm dados de sessão em tempo real, estado personalizado do carrinho e, no caso da página de checkout, lógica de processamento de pagamentos.
Um bot acessando repetidamente /checkout não está realizando nenhuma ação útil, mas o servidor não sabe disso. Ele processa cada solicitação como se pudesse se tratar de uma transação real.
?s= (Consultas de pesquisa)
As pesquisas do WordPress e do WooCommerce executam consultas no banco de dados a cada solicitação. Não existe uma camada de cache capaz de absorver uma string de pesquisa exclusiva.
Um crawler percorrendo variações de URLs com parâmetros ou simplesmente seguindo todos os links de pesquisa que encontra pode gerar uma longa sequência de consultas exclusivas e custosas ao banco de dados.
Navegação facetada e parâmetros de filtro
É aqui que o problema se agrava. Um catálogo típico do WooCommerce gera URLs como:
/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2Para um usuário, essas são apenas pequenas variações da mesma página. Para um bot seguindo links, cada uma delas é uma URL exclusiva que merece ser rastreada, e cada uma exige que o servidor execute uma consulta filtrada ao banco de dados do zero.
A documentação do Google identifica explicitamente a navegação facetada como uma fonte de ineficiência de rastreamento, na qual os crawlers exploram variações praticamente infinitas do mesmo conteúdo. Mas o problema não é apenas o desperdício do orçamento de rastreamento. Cada variação consome recursos reais do servidor para ser gerada.
Interações com tecnologia AJAX
Muitos plugins do WordPress, como listas de desejos, verificações de disponibilidade, atualizações de preços em tempo real e visualizações de calendário, dependem de solicitações AJAX que ignoram completamente o cache de página.
Um bot que aciona essas interações, mesmo indiretamente ao carregar uma página que as executa, gera carga no servidor que não aparece como uma “visualização de página” nas suas Análises, mas aparece no consumo de threads PHP.hshahahahhah
O que acontece quando as threads PHP se esgotam?
Cada acesso a um endpoint dinâmico mantém uma thread PHP ocupada durante toda a duração da solicitação. Esse detalhe pode parecer pequeno isoladamente, mas a capacidade de threads é limitada, e os bots não entram em fila educadamente.
A Kinsta aloca um número fixo de threads PHP para cada site WordPress, e cada solicitação não armazenada em cache reserva uma delas durante toda a sua execução.
Em condições normais de tráfego, isso raramente representa uma limitação. As solicitações chegam, são processadas rapidamente e as threads são liberadas.
Sob carga contínua de bots em endpoints dinâmicos, as threads ficam reservadas e ocupadas. Quando todas as threads estão em uso, as novas solicitações entram em uma fila de espera. Clientes reais tentando adicionar produtos ao carrinho ou concluir uma compra passam a enfrentar lentidão no carregamento das páginas, tempos limite excedidos ou erros HTTP 504.
Essa é a realidade da infraestrutura que torna o tráfego de bots em endpoints dinâmicos significativamente diferente do tráfego de bots em páginas que podem ser armazenadas em cache.
O problema dos loops: quando os bots ficam presos
Grande parte do tráfego de bots que a equipe de infraestrutura da Kinsta observa não é resultado de um ataque intencional. É o resultado de crawlers seguindo todos os links de todas as páginas sem nenhum mecanismo para identificar quando estão andando em círculos.
Veja como um loop de strings de consulta funciona na prática:
- Um bot chega a
/shop/ - A página contém um link para
/shop/?color=blue(uma exibição filtrada) - Essa página contém um link para
/shop/?color=blue&size=M - Essa página contém um link para
/shop/?color=blue&size=M&orderby=price - Essa página contém um link para você adicionar algo ao carrinho:
/shop/?add-to-cart=123 - Cada um deles gera links ligeiramente diferentes que o bot ainda não visitou
O bot segue todos eles. Ele não tem a capacidade de reconhecer que já viu a mesma página de produto em outro estado de filtragem. Cada URL parece nova, é solicitada e aciona um novo processamento no servidor.
Esse padrão exato de bots percorrendo variações de strings de consulta em endpoints dinâmicos foi um dos problemas mais comuns identificados em nosso relatório. Uma única regra de loop acionada por um padrão problemático filtrou 550 milhões de solicitações em 30 dias na infraestrutura da Kinsta. Isso não é um ataque, mas uma automação ineficiente em escala, que se agrava porque nada a interrompeu logo no início.
Como é um bom gerenciamento de bots no nível dos endpoints
Para lojas WooCommerce e sites WordPress com funcionalidades dinâmicas, alguns princípios se aplicam independentemente da configuração específica do seu site.
- O robots.txt é um sinal, não uma barreira de proteção. Você pode, e deve, impedir que crawlers acessem caminhos como
/cart,/checkoute URLs com?add-to-cart=no seu arquivorobots.txt. O Googlebot respeita essas instruções. No entanto, o cumprimento dorobots.txté voluntário. Uma parcela crescente dos crawlers de treinamento de IA não verifica esse arquivo ou simplesmente ignora suas regras. Bloquear um caminho norobots.txtcomunica a sua intenção, mas a aplicação efetiva dessa restrição exige uma regra no nível do WAF. - Reduza a geração excessiva de parâmetros de URL. A configuração padrão do WooCommerce gera uma longa sequência de variações de URLs por meio de tokens de sessão, parâmetros de quantidade e combinações de filtros. Reduzir essa proliferação de parâmetros na origem, utilizando tags canônicas, estruturas de links permanentes mais consolidadas e regras
Disallownorobots.txtpara variações de parâmetros, oferece menos oportunidades para que crawlers fiquem presos em loops. - Monitore os endpoints, não apenas o volume total de solicitações. Um aumento no tráfego geral pode ser resultado de uma campanha. Já um aumento nas solicitações para URLs com
?add-to-cart=provenientes de um agente de usuário que não seja um navegador indica um problema de bots. Registros do servidor e ferramentas de Análises que mostram a distribuição das solicitações por padrão de URL e agente de usuário são a diferença entre identificar o problema em horas ou apenas dias depois. - Trate a capacidade das threads PHP como uma métrica principal. Se suas threads PHP estão frequentemente operando no limite da capacidade e você não observa um aumento correspondente nas sessões de usuários reais, o tráfego de bots em endpoints dinâmicos quase certamente é um fator contribuinte. A ferramenta APM da Kinsta exibe as transações PHP mais lentas por endpoint. Dessa forma, se os caminhos do carrinho ou checkout forem os responsáveis, você verá isso diretamente em vez de depender de suposições.
Como isso se manifesta em diferentes tipos de sites
O problema dos endpoints dinâmicos é mais crítico em lojas WooCommerce, mas aparece de formas diferentes em diversos tipos de sites.
- As lojas WooCommerce enfrentam o maior risco porque seus endpoints mais caros, como carrinho, checkout e páginas de produtos filtradas, são exatamente os que os bots costumam encontrar ao seguir links normalmente. As consequências são diretas: o esgotamento das threads PHP durante picos de tráfego de bots prejudica o desempenho do checkout para clientes reais.
- Sites de conteúdo e blogs são menos expostos no lado do checkout, mas podem ser significativamente afetados por bots percorrendo arquivos paginados, páginas de tags e resultados de pesquisa. Cada consulta de pesquisa exclusiva gera uma nova consulta ao banco de dados. Um crawler agressivo percorrendo sistematicamente um grande arquivo pode gerar carga contínua no banco de dados sem sequer interagir com funcionalidades de loja.
- Sites empresariais e de serviços tendem a ser mais vulneráveis em endpoints de formulários, como formulários de contato, solicitação de orçamento e fluxos de reserva, que normalmente envolvem gerenciamento de sessão e, muitas vezes, gravações no banco de dados. Dados enviados por bots nesses formulários criam outro tipo de problema, como poluição do CRM e desperdício de esforços comerciais, mas o mecanismo subjacente é o mesmo: endpoints dinâmicos que consomem recursos reais a cada solicitação.
- Aplicativos web e produtos SaaS representam o cenário mais sensível. Seus endpoints de API, rotas de painel de controle e lógica do aplicativo não podem ser armazenados em cache, e qualquer tráfego de bots que alcance a camada do aplicativo ignora completamente a infraestrutura de cache. Nesses casos, a resposta adequada geralmente é bloquear completamente todo o tráfego não autenticado para caminhos como
/apie/app, criando listas de permissão explícitas apenas para integrações legítimas.
Mais detalhes: o panorama completo do tráfego de bots
O problema dos endpoints dinâmicos é apenas parte de uma mudança mais ampla na forma como o tráfego de bots afeta a infraestrutura WordPress. Os crawlers de IA cresceram significativamente em volume e mudaram seu comportamento, seguindo links de forma mais agressiva, ignorando com mais frequência as diretivas de rastreamento e direcionando mais tráfego justamente para os endpoints com maior custo de processamento.
Para uma análise completa do que mudou, dos dados por trás dessa mudança e de uma estrutura para tomar decisões sobre gerenciamento de bots com base no tipo e nas prioridades do seu site, consulte o relatório completo da Kinsta, A realidade do tráfego de IA e bots, que inclui análises de mais de 10 bilhões de solicitações processadas pela infraestrutura gerenciada da Kinsta.
Se você está pronto para agir com base no que leu aqui, a Proteção contra Bots da Kinsta lida automaticamente com os padrões mais comuns, incluindo proteção para endpoints dinâmicos de alto custo. Basta habilitar o nível de proteção desejado uma única vez no MyKinsta, e o sistema cuida do restante.
Você também pode entrar em contato com a equipe de suporte caso precise de esclarecimentos adicionais.
