Quando o consumo de recursos em um site de cliente começa a aumentar sem qualquer crescimento real no número de visitas, fazer um upgrade do plano parece ser a decisão certa. Esse é um princípio válido quando o crescimento vem de tráfego real, que aumenta a carga e a necessidade de capacidade.
No entanto, embora o escalonamento adicione mais recursos, ele não reduz o número de solicitações que chegam ao servidor. Se o tráfego de bots estiver contribuindo para essas solicitações e para a carga do servidor, aumentar a capacidade apenas lhes dará mais espaço para continuar operando.
Como resultado, os custos operacionais aumentam, mas os problemas de desempenho permanecem os mesmos. A Proteção contra Bots da Kinsta foi desenvolvida para esse tipo de situação, pois oferece controle sobre o que realmente chega ao seu servidor, em vez de apenas ampliar a capacidade que absorve esse tráfego.
Por que bots não se comportam como tráfego real
Um visitante humano que encontra uma página lenta pode esperar, recarregá-la ou simplesmente sair do site. Em contrapartida, um bot continua enviando o mesmo volume de solicitações, independentemente da resposta do servidor. Esse é o principal problema: como o tráfego de bots não consegue se autorregular quando você adiciona mais recursos, fazer um upgrade do plano apenas oferece aos bots mais capacidade para consumir.
A situação se torna ainda mais complexa quando consideramos como sites WordPress modernos processam solicitações. A maior parte do tráfego de bots não acessa páginas estáticas que podem ser absorvidas pelo cache. Em vez disso, ele atinge endpoints que ignoram os sistemas de cache e obrigam o servidor a trabalhar mais. Em qualquer site que utilize WooCommerce, pesquisa ou filtros, isso significa que os bots acessam diversos elementos:
- Ações de carrinho e variações do parâmetro
?add-to-cart=. - Páginas de produtos com filtros e diferentes combinações de strings de consulta.
- Consultas de pesquisa.
- Etapas do checkout e ações de lista de desejos.
- Interações baseadas em AJAX.
Nenhum desses elementos pode ser armazenado em cache da mesma forma que uma página estática. Para cada solicitação que chega a um desses endpoints, algumas operações acontecem no servidor:
- Execução de PHP. Uma Thread PHP permanece reservada durante toda a duração da solicitação. Sob carga contínua de bots, as Threads PHP se esgotam e os visitantes precisam esperar.
- Consultas ao banco de dados. Páginas dinâmicas consultam o banco de dados a cada carregamento porque não existe uma camada de cache capaz de absorver essas solicitações.
- Gerenciamento de sessão. Páginas de carrinho e checkout criam ou validam sessões em cada solicitação, adicionando sobrecarga até mesmo para bots que nunca concluirão uma compra.
Com base em nossos próprios dados de infraestrutura, um único bot foi capaz de gerar 3,75 milhões de solicitações para URLs de adicionar ao carrinho em um período de 24 horas. Isso equivale a aproximadamente uma solicitação a cada 23 milissegundos, durante todo o dia. Além disso, uma única regra de detecção de loops filtrou 550 milhões de solicitações em toda a plataforma durante um período de 30 dias.
No entanto, esses volumes não representam ataques no sentido tradicional. Eles são resultado de bots projetados para seguir todas as URLs que encontram, incluindo diversas variações de strings de consulta e caminhos baseados em parâmetros.
“Do ponto de vista da infraestrutura, não existe ‘apenas tráfego de bots’. Toda solicitação representa trabalho real. Em escala, rastreamentos ineficientes deixam de ser um problema de tráfego e passam a ser um problema de consumo de recursos.” — Daniel Pataki, CTO da Kinsta
Como fica o custo do tráfego de bots
Um padrão comum entre agências segue um ciclo previsível: quando o consumo de recursos aumenta, o cliente faz um upgrade do plano. Em seguida, o consumo aumenta novamente. Enquanto isso, o desempenho não melhora, porque o volume de solicitações continua exatamente o mesmo.
Como a cobrança da Kinsta não considera tráfego de bots no consumo do plano, você tem uma maneira rápida de identificar se eles são o problema. Os user agents de bots reconhecidos já são filtrados da tela Visitas nas Análises do MyKinsta. Se essas estatísticas parecerem normais enquanto o servidor continua sob pressão, o tráfego automatizado provavelmente é a causa.
A visualização Tráfego de bots e automatizado nas Análises do MyKinsta fornece uma divisão mais detalhada do tráfego que chega ao seu site, incluindo bots verificados, prováveis bots, Crawlers de IA, crawlers agressivos, tráfego automatizado e prováveis humanos.
Isso facilita identificar quando o tráfego automatizado está impulsionando o consumo de recursos. Por exemplo, picos em crawlers agressivos ou tráfego automatizado geralmente indicam bots acessando repetidamente endpoints não armazenados em cache.
O gráfico Resultados da proteção contra bots também mostra como as solicitações são tratadas após a classificação, incluindo o tráfego que foi permitido, submetido à verificação ou bloqueado. Isso oferece uma visão mais clara de como suas configurações atuais de proteção estão afetando o tráfego recebido.
O relatório Principais solicitações por visualizações também mostra o que está gerando carga no seu servidor e inclui todo o tráfego, não apenas as visitas faturáveis. A diferença entre essas duas métricas é justamente onde os custos começam a se acumular sem uma explicação evidente.
Veja como interpretar essa diferença:
- Verifique primeiro Visitas em Sites > nomedosite > Análises > Uso do plano. Se o número de visitas parecer normal, você não está lidando com um aumento real de tráfego humano.
- Abra Principais solicitações por visualizações para visualizar todo o tráfego, incluindo bots. Um agrupamento de solicitações em alto volume para caminhos não armazenáveis em cache, como URLs de adicionar ao carrinho, variações de strings de consulta ou etapas do checkout, confirma que bots estão consumindo recursos que o cache não consegue absorver.
- Consulte rapidamente o relatório Desempenho. Tempos elevados de resposta do PHP ou limites de Threads PHP sendo atingidos normalmente indicam que a carga gerada por bots está pressionando o servidor.
Se você gerencia um portfólio de clientes, cada site afetado pela carga gerada por bots representa um custo difícil de justificar, principalmente quando o desempenho não melhora após um upgrade. O tráfego de bots de IA cresceu 300% no último ano e uma em cada 31 visitas à web já corresponde a um bot de IA. Esse volume não vai desaparecer por conta própria.
A segurança em nível de plataforma da Kinsta já bloqueia o tráfego classificado como malicioso antes que ele chegue ao seu site, incluindo mitigação de DDoS e solicitações originadas de IPs associados a fontes de ataque conhecidas. Entre essa proteção e o tráfego que você deseja permitir existe uma categoria de solicitações automatizadas não verificadas, de alto volume e alto consumo de recursos, que ainda chega ao seu servidor. Os controles da Proteção contra Bots da Kinsta ajudam a reduzir esse volume.
Como funciona a Proteção contra Bots da Kinsta
Os controles da Proteção contra Bots no MyKinsta operam na camada de infraestrutura, e a filtragem acontece antes mesmo que o WordPress seja envolvido. Por isso, não há nenhum plugin para instalar nem configurações do WordPress para ajustar.
A Kinsta classifica cada solicitação usando uma combinação de sua própria análise de tráfego e do sistema de Aprendizado de Máquina (Machine Learning) do Cloudflare, que atribui a cada visitante uma pontuação de bot de um a 99. Pontuações altas indicam que a solicitação provavelmente veio de um humano, enquanto pontuações baixas indicam atividade automatizada.
O tráfego é agrupado em categorias como bots verificados, prováveis bots, Crawlers de IA, crawlers agressivos, tráfego automatizado e prováveis humanos. O nível de proteção selecionado determina como cada categoria será tratada.
Você pode gerenciar a Proteção contra Bots no MyKinsta em Sites > nomedosite > Proteção contra Bots.
Escolhendo um nível de proteção
Há quatro níveis disponíveis no painel Nível de proteção da tela de Proteção contra Bots:
- Bloquear tráfego malicioso é a configuração padrão. Ela realiza a mitigação de DDoS e bloqueia o tráfego proveniente de IPs e endpoints associados a fontes de ataque conhecidas.
- Bloquear automações amplia a proteção padrão para também bloquear tráfego automatizado confirmado, enquanto permite a passagem de bots verificados e visitantes reais.
- Aplicar verificação a bots bloqueia o tráfego automatizado e malicioso e adiciona uma etapa de verificação para prováveis bots. Os visitantes que concluírem a verificação não serão desafiados novamente durante dez dias usando o mesmo navegador e endereço IP.
- Aplicar verificação a todos aplica verificações também aos prováveis humanos. Esse nível é mais indicado para uso temporário durante picos de tráfego.
Para alterar o nível, acesse Sites > nomedosite > Proteção contra Bots e clique em Alterar. Pela tela Sites, você também pode selecionar os sites desejados e usar Ações > Alterar Proteção contra Bots.
No entanto, ao elevar a proteção para Aplicar verificação a bots ou superior, qualquer ferramenta que se conecte programaticamente ao seu site e não esteja listada no diretório de bots verificados do Cloudflare será bloqueada ou submetida à verificação. Isso inclui integrações personalizadas, scripts de implantação e monitores de tempo de atividade auto-hospedados. Se você depende de algum desses serviços, vale a pena verificar se eles aparecem nessa lista antes de aumentar o nível de proteção.
Bloqueando Crawlers de IA
A opção Bloquear Crawlers de IA é direcionada especificamente aos Crawlers de IA. Esses bots coletam conteúdo para treinamento de modelos, geração aumentada por recuperação (RAG) e recursos de pesquisa baseados em IA. Isso não afeta os crawlers dos mecanismos de pesquisa, mas inclui crawlers dedicados, como o GPTBot. O Googlebot e o Bingbot continuam indexando seu site, independentemente de a opção estar ativada ou desativada.
Em geral, 80% de toda a atividade dos Crawlers de IA é destinada ao treinamento de modelos, e não a consultas iniciadas por usuários. Esse tráfego não gera nenhum tráfego de referência para o seu site. Por isso, ativar essa opção costuma ser uma boa decisão. Para habilitá-la, acesse Sites > nomedosite > Proteção contra Bots e clique no botão de alternância ao lado de Bloquear Crawlers de IA. Para vários sites, utilize Ações > Alterar bloqueio de Crawlers de IA na tela Sites.
No entanto, as consequências são uma menor visibilidade em visões gerais e resumos de conteúdo gerados por IA. Se essa exposição for importante para sua estratégia de conteúdo, vale a pena monitorar o impacto antes de manter essa opção ativada permanentemente.
Se sua prioridade é reduzir a carga no servidor, essa abordagem é mais eficiente do que modificar o arquivo robots.txt ou criar regras específicas para cada bot. Ao contrário dessas alternativas, ela atua na camada de infraestrutura, antes mesmo que qualquer solicitação chegue ao WordPress.
Gerenciando a proteção em um portfólio de clientes
Sites diferentes exigem níveis de proteção diferentes. Uma loja WooCommerce com páginas de produtos filtradas, por exemplo, não tem as mesmas necessidades que uma plataforma de conteúdo. Além disso, cada site em um portfólio de clientes possui um perfil de tráfego, um conjunto de integrações e uma tolerância diferente às etapas de verificação. Isso significa que aplicar uma única política para todo o portfólio pode restringir excessivamente alguns sites e deixar outros com proteção insuficiente.
Quando você identificar sinais de que o tráfego de bots está aumentando os custos de um site de cliente, este é um fluxo de trabalho prático:
- Comece pela visualização Tráfego de bots e automatizado nas Análises do MyKinsta. Se o tráfego humano permanecer estável enquanto aumentam o tráfego automatizado, os crawlers agressivos ou a atividade dos Crawlers de IA, a carga gerada por bots provavelmente é a causa.
- Em seguida, abra Principais solicitações por visualizações em Análises e procure altos volumes de solicitações para caminhos não armazenáveis em cache. Um agrupamento de atividade em URLs de adicionar ao carrinho, páginas de produtos com filtros, etapas do checkout, consultas de pesquisa ou variações de strings de consulta é um forte indicativo de consumo de recursos causado por bots.
- O relatório Desempenho ajuda a confirmar esse impacto. Tempos de resposta do PHP mais altos, throughput elevado ou limites de Threads PHP sendo atingidos indicam que o tráfego automatizado está se tornando visível como pressão sobre o servidor.
- A partir daí, aplique o nível de proteção adequado para o site. Bloquear automações normalmente é o melhor ponto de partida, enquanto Aplicar verificação a bots adiciona uma camada extra de verificação para prováveis bots que continuam chegando ao servidor de origem.
- Para sites que dependem de integrações, APIs ou funcionalidades automatizadas do WordPress, configurações como Permitir automações típicas do WordPress e as exceções Sempre permitir ajudam a reduzir o risco de serviços legítimos serem bloqueados.
- As alterações entram em vigor sem qualquer indisponibilidade, e você pode revertê-las imediatamente caso alguma configuração seja mais restritiva do que as integrações do site conseguem suportar. Como esses controles operam fora do WordPress, não há risco para o próprio site durante a avaliação.
Para agências que gerenciam grandes portfólios de hospedagem para WordPress, isso transforma um projeto complexo em uma tarefa rotineira. Quando as configurações de proteção correspondem ao perfil real de tráfego de cada site, o consumo de recursos passa a refletir a atividade de usuários reais. As métricas de desempenho também passam a representar a experiência dos visitantes reais.
“O equívoco é pensar que o tráfego de bots é apenas uma questão de ‘bloquear ou permitir’. Na realidade, trata-se de política, visibilidade e controle econômico.” — Cristian Lopez, editor-chefe da HostingAdvice
A explicação que você fornece ao cliente sobre os custos deve estar relacionada às decisões tomadas sobre o tráfego do site, e não à capacidade adicional que foi necessária para responder a uma carga cuja origem você não consegue identificar.
Pare de aumentar a infraestrutura para contornar um problema que você pode controlar
Escalonar a infraestrutura aumenta a quantidade de carga que o servidor consegue absorver. A Proteção contra Bots reduz a quantidade de carga que chega até ele. Essas não são respostas equivalentes para o mesmo problema: uma adiciona capacidade, enquanto a outra elimina a pressão que fez parecer necessário aumentar essa capacidade.
Usando as Análises do MyKinsta, você pode identificar quando o tráfego automatizado está contribuindo para o aumento do consumo de recursos, mesmo que o tráfego humano permaneça estável. A partir daí, a Proteção contra Bots oferece controles para classificar, aplicar verificação e bloquear tráfego indesejado antes que ele chegue ao WordPress, ao PHP ou ao banco de dados.
Para sites que enfrentam atividade excessiva de crawlers, a opção Bloquear Crawlers de IA também reduz o tráfego gerado por IA sem afetar crawlers tradicionais de mecanismos de pesquisa, como Googlebot e Bingbot.
Se você deseja ter mais controle sobre como o tráfego automatizado chega à sua infraestrutura, a Proteção contra Bots da Kinsta oferece os recursos de visibilidade e filtragem necessários para reduzir a carga desnecessária diretamente pelo MyKinsta.
