Um caso real: 67.000 acessos de bots que ninguém estava monitorando
Seu cliente jura que o site está lento. Você verifica o Google Analytics — o tráfego parece normal. As notas do PageSpeed estão razoáveis. O servidor não está sobrecarregado. Nada óbvio.
Parece familiar?
Acabamos de diagnosticar exatamente esse cenário em um site real em produção. O culpado não era um plugin pesado, um plano de hospedagem ruim ou imagens sem otimização. Era tráfego invisível que nenhuma ferramenta de analytics padrão estava capturando — e que vinha martelando o servidor há meses.
Veja o que encontramos, como encontramos, e o que isso significa para todo site WordPress que você gerencia.
A reclamação
O cliente vinha relatando lentidão há meses. Intermitente. Difícil de reproduzir. “Às vezes funciona bem, às vezes trava.”
Sintomas clássicos de um problema de contenção de recursos — algo está consumindo capacidade do servidor periodicamente, deixando usuários legítimos esperando. Mas todos os diagnósticos padrão não apontavam nada.
O problema: todas as ferramentas de diagnóstico que eles haviam tentado só enxergam tráfego baseado em browser. Google Analytics, Plausible, Fathom — todos funcionam executando um snippet de JavaScript no navegador do visitante. Sem navegador, sem dados. E uma parcela significativa do que estava chegando ao servidor não tinha navegador nenhum.
O que a análise no nível do servidor revelou
Quando analisamos o tráfego bruto do servidor usando o SysWP Radar — que captura cada requisição no nível do servidor, antes do JavaScript ser executado — o quadro mudou completamente.
Só o bucket de tráfego “desconhecido” continha ~68.000 requisições na janela de análise. Tráfego completamente invisível para os analytics existentes deles. Veja o que estava dentro:
O principal problema: Go-http-client/1.1 — 67.323 acessos
Esse único user agent representou 99% de todo o tráfego desconhecido.
Go-http-client/1.1 é o cliente HTTP padrão da linguagem de programação Go. Não é um navegador, não é um crawler legítimo — é uma biblioteca. Com 67.000+ requisições, isso não é acidental. Alguém construiu um scraper automatizado em Go e está varrendo o site sistematicamente em escala industrial.
O que causa em performance: Cada uma dessas 67.000 requisições consumiu um worker PHP, consultou o banco de dados e gerou um render completo de página WordPress. O plano de hospedagem do site tinha um número fixo de workers PHP concorrentes. Quando o scraper estava ativo, competia diretamente com visitantes reais por esses workers — causando exatamente a lentidão intermitente que o cliente vinha reportando.
Nível de risco: Alto. Esse tipo de scraping sistemático pode:
- Esgotar o pool de workers PHP, causando erros 503 para usuários reais
- Inflar custos de hospedagem em planos que cobram por uso de recursos
- Roubar conteúdo para treinamento de IA, análise de concorrentes ou republicação direta
- Degradar as notas de Core Web Vitals medidas a partir de dados de usuários reais
Outros atacantes encontrados no mesmo bucket
As ~750 requisições restantes revelaram um ecossistema completo de atividade maliciosa e suspeita:
axios/1.15.0 — 308 acessos Axios é uma biblioteca HTTP para Node.js. Usada aqui como scraper. Não é um navegador, não é um buscador — é um script fazendo requisições automatizadas.
User agents de browser falsificados — ~370 acessos combinados Vários clusters de requisições usavam strings de user agent que pareciam navegadores reais, mas continham inconsistências reveladoras:
Mozilla/5.0 (Mac/Win)... AppleWebKit/605... Safariacessando/wp-json/wp/v2/— um UA de Safari aparentemente legítimo sendo usado para enumerar endpoints da REST API do WordPress. O endpoint/wp-json/wp/v2/usersé especificamente visado para coletar nomes de usuário em ataques de força bruta.Mozilla/5.0 AppleWebKit/537.36sem identificador de plataforma — malformado, um sinal claro de UA falsificado.Mozilla/5.0 (Windows NT 10) AppleWebKit/605 Chrome/X— o mismatch é o indício. O Chrome real usa WebKit 537. AppleWebKit/605 pertence ao Safari. Um bot copiou uma string de UA e errou.
getwp/1.0 (WP tespit) — 2 acessos “Tespit” é turco para “detecção.” Esta é uma ferramenta de fingerprinting WordPress — projetada especificamente para identificar instalações WordPress e suas configurações. Dois acessos não são muito, mas indicam um scan de reconhecimento.
Bibliotecas HTTP em escala: curl, wget, python-requests, Apache-HttpClient, Java — múltiplos acessos Ferramentas automatizadas sondando o site. Alguns podem ser benignos (monitores de uptime, fetchers de oEmbed), mas nesse contexto contribuem para o consumo agregado de recursos.
A matemática: o que isso custa em performance
Vamos ser concretos sobre o impacto no servidor.
Considere um plano de hospedagem WordPress gerenciado modesto com 4 workers PHP concorrentes — típico para planos de entrada no WP Engine, Kinsta, Cloudways ou plataformas similares.
Durante um burst de scraping do Go-http-client em escala:
- O scraper envia requisições mais rápido do que o WordPress consegue responder
- Cada requisição ocupa um worker PHP durante todo o render da página
- Com 4 workers ocupados pelo tráfego de bots, requisições de visitantes legítimos ficam em fila ou sofrem timeout
- O usuário vê um site lento ou um erro 503
- O Google Analytics não registra nada — o visitante real pode ter saído antes do JavaScript carregar
O scraper nunca aparece nos seus analytics. A lentidão aparece como “problemas de performance intermitentes” sem causa óbvia. O cliente reporta, você investiga, não encontra nada nas ferramentas padrão, e o ciclo se repete.
Por que o Google Analytics não vê isso
Esse é o problema central, e é arquitetural.
O Google Analytics (e a maioria das plataformas de analytics) funciona injetando um snippet JavaScript nas suas páginas. Esse snippet roda no navegador do visitante, coleta dados e os envia aos servidores do GA. Isso significa:
- Bots sem motor JavaScript são completamente invisíveis
- Requisições que nunca renderizam uma página completa (acessando endpoints da REST API, XML-RPC, páginas de login diretamente) não geram nenhum evento no GA
- Requisições bloqueadas antes da página carregar não geram dado algum
- Crawlers, scrapers, bibliotecas HTTP — nenhum deles executa JavaScript
Nesse caso, o scraper Go fez 67.000 requisições e cada uma delas era invisível para o GA. Os analytics do cliente mostravam tráfego normal e saudável. O servidor contava uma história completamente diferente.
O que procurar nos seus próprios sites
Se seus clientes estão enfrentando lentidão intermitente sem causa óbvia, verifique esses padrões no nível do servidor:
User agents de alto volume nos logs brutos Qualquer UA não-browser com milhares de acessos é um sinal de alerta. Crawlers legítimos (Googlebot, Bingbot) têm bom comportamento e não vão acertar um site pequeno milhares de vezes em uma janela curta.
Requisições para endpoints específicos do WordPress
/wp-json/wp/v2/users— enumeração de usuários/wp-login.php— força bruta/.env,/wp-config.php.bak,/.git/config— coleta de credenciaisxmlrpc.php— vetor de amplificação de DDoS
Incompatibilidades de user agent Números de versão do WebKit não correspondem ao browser declarado. Identificadores de plataforma ausentes ou inconsistentes. Strings de UA truncadas.
Bibliotecas HTTP em volume curl, wget, python-requests, axios, Go-http-client, Apache-HttpClient, java/ — esses não são navegadores. Alguns poucos acessos podem ser legítimos. Centenas ou milhares é atividade automatizada.
Requisições de ferramentas de scanner conhecidas Qualquer UA contendo “scan”, “test”, “probe”, “check”, “spider”, “bot” que não seja um crawler verificado deve ser investigado.
A solução
Uma vez identificado o padrão de tráfego, a remediação foi direta:
- Bloquear Go-http-client no nível do firewall — essa única regra eliminou 99% do tráfego problemático
- Bloquear
/wp-json/wp/v2/usersno nível da aplicação para impedir enumeração de usuários - Rate limiting para user agents desconhecidos — requisições de UAs não reconhecidos recebem um limite rigoroso por IP
- Adicionar os IPs ofensores à lista de bloqueio — e compartilhá-los com a rede de inteligência coletiva para que outros sites se beneficiem automaticamente
Após implementar essas mudanças, a lentidão intermitente que o cliente vinha reportando há meses desapareceu.
A lição mais ampla
O tráfego de bots não precisa atacar ativamente seu site para prejudicá-lo. Scraping passivo em escala consome os mesmos recursos do servidor que visitantes reais. O dano é indireto — tempos de resposta mais lentos, 503s ocasionais, custos de hospedagem inflados — e porque as ferramentas de analytics padrão são completamente cegas a isso, pode persistir sem detecção por meses ou anos.
Todo site WordPress tem algum nível de tráfego não-humano. A questão é se você está medindo.
Como o SysWP Radar e o Shield resolvem isso
O SysWP Radar realiza análise de tráfego server-side que captura cada requisição independentemente de vir de um browser. Ele classifica todo o tráfego em nove categorias — visitantes humanos, bots verificados (Googlebot, Bingbot), crawlers de IA, crawlers de SEO, leitores RSS, requisições internas do WordPress, health checks, atacantes e desconhecidos — dando visibilidade sobre o quadro completo do tráfego, não apenas a fatia baseada em browser.
Nesse caso, o Radar identificou o scraper Go-http-client, as tentativas de enumeração da REST API e os padrões de UA falsificados em minutos após a instalação.
O SysWP Shield usa essa inteligência para bloquear. Quando o Radar identifica um padrão de ameaça, o Shield pode bloqueá-lo com um clique. Mais importante, a rede de inteligência coletiva do Shield significa que quando um site identifica um IP malicioso ou padrão de comportamento, esse bloqueio se propaga automaticamente para todos os outros sites da rede — seus clientes se beneficiam da inteligência de ameaças combinada de toda a base de usuários.
Se você gerencia sites WordPress profissionalmente e seus clientes estão reportando problemas de performance intermitentes, vale a pena investigar. O tráfego que seu analytics não está mostrando pode ser exatamente o problema.
Experimente o SysWP Radar gratuitamente no seu primeiro site — radar.syswp.com.br
Sem cartão de crédito. Instalação em 5 minutos. Veja o quadro completo do seu tráfego em tempo real.
