Muito acesso e nenhuma venda: como analisar logs do servidor para separar cliente de robô antes de comprar capacidade

Antes de perguntar se a VPS aguenta o tráfego, pergunte se esse tráfego merece ser atendido: o log de acesso mostra, por user-agent, caminho pedido e ritmo por IP, se quem está pesando é cliente, buscador, raspador de preço ou enxurrada de requisições sem intenção de compra.

Analisar logs do servidor para separar cliente de robô é ler o arquivo de acesso da máquina e contar quem pediu o quê, quando e em que ritmo. É o passo que vem antes de qualquer decisão de capacidade: sem essa separação, dá para pagar por máquina maior só para atender melhor quem nunca ia comprar.

Todo termo técnico abaixo vem explicado na primeira aparição.

Por que o site fica pesado se o Analytics mostra quase ninguém

A resposta direta: o Google Analytics e o log do servidor contam coisas diferentes, e quem manda na conta de recurso é o log. Não há erro de medição aí — há diferença de escopo.

O Analytics só registra quem carrega a página e executa o JavaScript de medição no navegador. Robô, raspador e script não executam esse JavaScript: pedem o HTML, pegam o que queriam e vão embora. Para o relatório, a visita nunca aconteceu. Para o servidor, ela consumiu processador, memória e banco como qualquer outra.

Visitante humano também some do relatório por outros motivos — bloqueador de anúncios, recusa do banner de consentimento, aba fechada antes do carregamento. Por isso a diferença entre as duas contagens nunca é só robô, e o que interessa aqui é descobrir qual parte dela é.

O log de acesso é o arquivo em que o servidor web anota cada requisição recebida, venha de quem vier. Ele conta tudo, inclusive o que o Analytics não vê.

E requisição não é visitante: é cada pedido individual feito ao servidor. Uma única página de produto costuma gerar várias — o HTML, o CSS, cada imagem, cada arquivo JavaScript, cada chamada de API que o tema dispara.

Por isso “pouca gente no Analytics e servidor no talo” é um cenário comum, não um mistério.

Onde fica o log de acesso e o que cada campo de uma linha significa

Nos caminhos usuais: /var/log/nginx/access.log no nginx e /var/log/apache2/access.log no Apache em sistemas Debian e Ubuntu — em distribuições da família Red Hat, o Apache costuma escrever em /var/log/httpd/access_log. Em hospedagem gerenciada você raramente tem terminal, mas o painel quase sempre oferece o download do arquivo.

No formato combinado, o padrão da maioria das instalações, cada linha traz, entre outros campos: IP de origem (o primeiro da linha), data e hora, método e caminho pedido, código de resposta, bytes enviados, referenciador (a página de onde veio o clique) e user-agent.

O user-agent é o texto que o programa cliente envia se identificando — um navegador, um robô de busca ou uma biblioteca de script. Guarde isto, porque muda tudo mais adiante: é uma declaração, não uma prova. Qualquer um pode escrever ali o que quiser.

O código de resposta, em uma linha cada: 200 entregue, 301 e 302 redirecionado, 404 o caminho não existe, 429 recusado por excesso de pedidos, 5xx erro do servidor.

Se a loja está atrás de CDN ou proxy, o IP da linha pode ser o do intermediário, não o do visitante — e aí toda contagem por IP vira uma só linha gigante. O IP real chega no cabeçalho X-Forwarded-For, e o log precisa estar configurado para registrá-lo. Esse cabeçalho também é forjável: só confie nele quando a requisição vier do seu próprio CDN ou proxy. Confira isso antes de tirar conclusão de qualquer ranking.

Se o log já foi rotacionado e comprimido (arquivos terminados em .gz), o histórico do dia ruim continua ali e pode ser lido sem descompactar, com zcat e zgrep. É justamente esse dia que interessa.

Os quatro perfis de carga e a assinatura de cada um no log

Quatro perfis explicam quase todo volume de uma loja. Cada um deixa um rastro diferente:

O detalhe mais útil da tabela é a coluna dos arquivos estáticos. Navegador de gente puxa a página e tudo que ela referencia; script quase sempre quer só o HTML. Uma proporção estranha entre páginas pedidas e imagens pedidas é um dos indícios mais baratos que existem.

E a regra de leitura honesta: assinatura é indício, não veredito. Combine três sinais — caminho, ritmo e estáticos — antes de concluir qualquer coisa. Buscador se confirma pelo IP, nunca pelo user-agent, porque o texto “Googlebot” é trivial de forjar; o como está na próxima seção.

Como analisar logs do servidor para separar cliente de robô na prática

A ideia é mais simples do que parece: contar e ordenar. Três contagens respondem quase tudo.

1. Quem mais pediu. Conte as linhas por IP e ordene do maior para o menor: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20. O topo dessa lista é por onde começar.
2. Quem diz ser o quê. A mesma receita aplicada ao user-agent mostra se o volume vem de navegador, de robô identificado ou de biblioteca de script.
3. O que foi pedido. Contando por caminho, você vê quanto do volume é página de produto, quanto é busca interna, quanto é checkout e quanto é caminho que nem existe na loja.

Depois, o ritmo. Pegue um IP do topo da lista e conte as requisições dele por minuto. O que distingue cliente de script é a cadência: gente lê, hesita e pausa; script tende a manter o mesmo número minuto após minuto.

Para confirmar um buscador legítimo, use DNS reverso: peça o nome associado ao IP e, em seguida, resolva esse nome de volta para IP. Um Googlebot verdadeiro fecha o ciclo em domínio do próprio Google; um forjado cai nessa checagem. Google e Bing também publicam as faixas de IP dos seus robôs, o que serve para a mesma conferência.

Quem não quer linha de comando pode usar o GoAccess, que lê o mesmo arquivo e gera um relatório navegável por IP, user-agent e caminho. A ferramenta muda, a leitura não.

O passo que fecha o diagnóstico é o cruzamento: ponha lado a lado o horário do pico no log, o gráfico do monitoramento da VPS e o que o Analytics registrou no mesmo intervalo. Se o servidor subiu e o Analytics não, você já sabe de que lado procurar.

A medida certa para cada perfil — e o que cada uma não resolve

Cada assinatura tem um tratamento diferente, e cada tratamento tem um limite que vale dizer em voz alta.

Rastreador de buscador pesando demais. Use o robots.txt — o arquivo que diz aos robôs o que não rastrear — para tirar do caminho filtro de catálogo, busca interna e parâmetros de ordenação, que multiplicam URLs. Ele só vale para robô que resolve obedecer: buscador grande respeita, raspador ignora.

Não conte com a diretiva crawl-delay: alguns robôs respeitam, o Google a ignora. O Google também não oferece mais ajuste manual de taxa de rastreamento no Search Console — o que sobra por lá é o relatório de estatísticas de rastreamento, para acompanhar o efeito. Googlebot reduz o próprio ritmo quando o servidor demora a responder ou devolve 429, 500 e 503. O Bing Webmaster Tools ainda tem controle de rastreamento.

Cliente real em volume. Cache de página e CDN na frente: a requisição é respondida sem acordar PHP e banco de dados — é a mesma dupla que sustenta o roteiro de preparar a loja para a Black Friday sem trocar de servidor. É a única medida desta lista que aumenta o que você consegue atender, em vez de reduzir o que entra — com a ressalva de que carrinho, checkout e área logada não são cacheáveis, e é justamente aí que o trabalho pesado continua.

Raspador de catálogo. Limite de taxa por IP no servidor web, respondendo 429 acima do ritmo definido. Bloquear por user-agent conhecido ajuda pouco, porque trocar esse texto é questão de uma linha de código. E assuma o resto: raspador determinado troca de IP. Você não o elimina, só o encarece.

Enxurrada de requisições. Bloqueio na borda, antes de chegar na VPS — filtro do CDN ou do provedor. Filtrar dentro da máquina adianta pouco quando o gasto de receber e processar o pacote já aconteceu.

Limite de taxa mal calibrado barra cliente real, principalmente quando muita gente sai do mesmo IP: rede corporativa, operadora móvel, qualquer NAT. Calibre contra a sua linha de base e comece em modo de registro, sem bloquear, para ver quem cairia antes de deixar alguém cair.

O limite comum a quase todas elas: filtrar reduz o que entra, não aumenta o que a máquina dá conta de produzir. Só o cache empurra o teto para cima, e apenas nas páginas que ele consegue guardar.

Depois de filtrar, refaça a conta: o que sobra é cliente pagante?

Medida aplicada, volte ao log no próximo período comparável e conte de novo. O número que interessa é quanto do volume anterior era tráfego que você não queria atender.

Aí compare o que sobrou com o teto medido da máquina. Se você ainda não mediu, esse número não sai da descrição do plano de hospedagem — sai de um teste de carga.

Do cruzamento saem três desfechos, e só um deles é sobre comprar máquina:

• Sobrou pouco e a VPS folga. Não compre nada. O problema era o que você acabou de tirar do caminho.
• Sobrou cliente real dentro do teto, mas a loja engasga. O gargalo é a aplicação, não a máquina — e trocar de servidor leva o gargalo junto. O roteiro está em como achar o gargalo na sua VPS.
• Sobrou cliente real acima do teto. Aí é capacidade mesmo, e a decisão vira servidor maior ou reforço só no pico.

A ordem não é detalhe: filtrar, medir de novo, depois decidir capacidade.

Por que o SwarmBurst não distingue cliente de robô — e o que isso muda

O agente decide por pressão de recurso: ele observa uso de processador e memória do cluster e dispara o burst quando passa do limiar que você configurou. Burst, em uma frase, é subir nó extra na nuvem pública durante o pico e removê-lo quando a demanda cai, encerrando a cobrança dele ali — o conceito inteiro está em o que é cloud bursting.

O limite, sem rodeio: pressão de recurso é pressão de recurso. O agente não lê user-agent e não sabe se a requisição veio de cliente ou de raspador.

A consequência é direta. Se o que satura a VPS é tráfego lixo, o burst multiplica a conta para servir quem não compra — e a loja continua pesada, porque a fonte não parou. Máquina extra não filtra nada, do mesmo jeito que subir réplica dentro da mesma VPS não cria capacidade que não existe.

Onde o burst é a resposta certa: quando, já filtrado, o que sobra é cliente real acima do teto medido da VPS e concentrado em janelas curtas — campanha, lançamento, uma das datas sazonais do e-commerce brasileiro. Quando não é: se o pico dura o mês inteiro, a conversa passa a ser comparar com aumentar o plano — ou com manter tudo na nuvem em tempo integral.

Se você já filtrou, já mediu e o que sobra continua acima do teto, a conversa começa pelos seus números:

Quero o piloto do primeiro pico

É uma conversa no WhatsApp, sem compromisso. A gente diz na hora se o seu caso encaixa.

Perguntas frequentes

Por que o Google Analytics mostra pouca gente e o servidor está no limite?

O Analytics só registra quem carrega a página e executa o JavaScript de medição no navegador. Robôs, raspadores e scripts não executam esse JavaScript: pedem o HTML e saem. Para o relatório, essas requisições nunca aconteceram. Para o servidor, elas consumiram processador, memória e banco como qualquer outra. O log de acesso registra tudo que chega ao servidor, independentemente de origem, por isso mostra muito mais volume que o Analytics.

Como saber se o tráfego que derrubou minha loja era cliente de verdade ou robô?

Compare três sinais no log de acesso: quem mais pediu (conte requisições por IP), quem diz ser o quê (user-agent), e o que foi pedido (caminhos acessados). Cliente real segue sequência lógica de categoria para produto para carrinho, puxa arquivos estáticos junto e tem ritmo irregular com pausas. Raspador e script repetem caminhos, ignoram CSS e imagem, e mantêm ritmo constante sem pausa humana.

Para confirmar buscador legítimo, use DNS reverso: peça o nome associado ao IP e resolva de volta para IP. Um Googlebot verdadeiro fecha o ciclo em domínio do Google. Também compare com as faixas de IP publicadas pelo Google e Bing. Finalmente, cruze o horário do pico no log com o gráfico de monitoramento da VPS e o que o Analytics registrou: se o servidor subiu e o Analytics não, você já sabe de onde vem o tráfego.

O Googlebot pode derrubar meu site — e dá para pedir que ele acesse menos?

O Googlebot só derruba seu site se passar por caminhos que multiplicam URLs exponencialmente, como filtros de catálogo, busca interna e parâmetros de ordenação. Use o robots.txt para tirar esses caminhos. Não conte com a diretiva crawl-delay: Google a ignora. O Google também não oferece mais ajuste manual de taxa de rastreamento no Search Console, mas reduz o próprio ritmo quando o servidor demora a responder ou devolve 429, 500 e 503. O Bing ainda oferece controle de rastreamento no Bing Webmaster Tools.

Bloquear raspador de preço por user-agent funciona?

Ajuda pouco. Trocar o user-agent é questão de uma linha de código no script do raspador. Um limite de taxa por IP no servidor web, respondendo 429 acima do ritmo definido, é mais efetivo. Mas assume o resto: raspador determinado troca de IP. Você não o elimina, só o encarece.

Vale a pena filtrar o tráfego antes de contratar um servidor maior?

Sim. Depois de aplicar uma medida de filtragem, refaça a contagem no log e compare o que sobrou com o teto da sua máquina. Se sobrou pouco e a VPS folga, não compre nada — o problema era o tráfego que você tirou. Se sobrou cliente real dentro do teto mas a loja engasga, o gargalo é a aplicação. Se sobrou cliente real acima do teto, aí é capacidade. A ordem importa: filtrar, medir de novo, depois decidir capacidade.