Como bloquear bots da Digital Ocean no WordPress

Se os relatórios do GA4 mostram picos repentinos de regiões desconhecidas, durações de sessão idênticas ou páginas de destino que ninguém partilha, muitas vezes está a olhar para bots que mesmo assim disparam a tag de analítica. O objetivo não é bloquear todos os crawlers. O objetivo é cortar o lixo que distorce decisões e deixar em paz o Googlebot, o Bingbot e os visitantes reais.

Este guia aplica-se ao WordPress num droplet da DigitalOcean (ou num VPS semelhante) com nginx, opcionalmente fail2ban, e GA4. Trata o robots.txt, as firewalls de servidor, os plugins do WordPress e as ferramentas de CDN contra bots como camadas diferentes com funções diferentes. Se precisa de trabalho de rastreamento e citações que vá além da higiene de tráfego, saiba mais sobre os nossos serviços de otimização SEO e GEO na WPPoland.

#Porque é que os bots maus inflacionam o Google Analytics

O GA4 conta um acesso quando um navegador (ou um navegador headless que se comporta como tal) executa a sua tag e envia eventos. Isso significa que três populações diferentes aparecem em sítios diferentes:

• Scrapers que executam JavaScript e ferramentas de fraude de cliques podem aparecer no GA4 como sessões, visualizações de página e até conversões, se acertarem nos URLs certos.
• Scrapers HTTP simples muitas vezes nem executam JavaScript, por isso escapam por completo ao GA4 e continuam a carregar PHP, MySQL e qualquer template sem cache no servidor.
• Crawlers de pesquisa identificados devem aparecer nos registos do servidor e na Search Console, não como uma grande parte dos “Utilizadores” no GA4.

Quando o grupo que executa JavaScript cresce, os relatórios de aquisição e de envolvimento começam a desviar-se. A taxa de rejeição e o tempo médio de envolvimento ficam estranhos. Os relatórios pagos e orgânicos ganham ruído. As equipas começam a otimizar para tráfego que nunca compra nada.

Formas comuns de tráfego mau (sem inventar IPs concretos):

• Grande volume de pedidos a partir de um pequeno conjunto de ASN cloud, sem referrer e com User-Agents estranhos
• Acessos repetidos a /wp-login.php, xmlrpc.php, consultas que enumeram autores ou caminhos antigos de plugins
• Sessões que só aterram em URLs pobres e saem em menos de um segundo, mas que mesmo assim geram eventos page_view no GA4
• Tráfego “orgânico” que, no mesmo período, nunca bate certo com os dados de consultas da Search Console

Fornecedores cloud como a DigitalOcean e a AWS alojam muitos sites legítimos. Também alojam scrapers. Essa sobreposição é a razão pela qual regras gerais do tipo “bloquear todo o /16” são arriscadas. Prefira fontes confirmadas nos seus próprios registos a listas copiadas de artigos antigos.

#Como detetar tráfego de bots no GA4 e nos registos do servidor

Mudar sem uma base de comparação é contar histórias. Recolha uma base de pelo menos sete dias, se puder, ou de uma semana útil completa se o tráfego for sazonal.

#Como identificar tráfego de bots nos relatórios do GA4

Antes de mexer no nginx ou no fail2ban, crie uma vista de comparação simples:

1. Anote Utilizadores, Sessões, Sessões com envolvimento e Visualizações dos últimos 7 e 28 dias.
2. Abra Aquisição de tráfego e procure fontes com envolvimento absurdo (tempo de envolvimento perto de zero, rejeição perto de 100% em todas as páginas de destino).
3. Verifique Tecnologia > Navegador e Dispositivo à procura de clientes vazios, desconhecidos ou claramente automatizados.
4. Veja em Página de destino os caminhos de que só os bots gostam (/?author=1, spam antigo em parâmetros, IDs de produtos que não existem).
5. Exporte ou faça uma captura de ecrã do período, para mais tarde comparar igual com igual (mesma duração, mesma mistura de dias da semana).

O GA4 já remove sozinho os bots conhecidos (ver a secção seguinte), mas essa lista não apanha todos os clientes abusivos que executam JavaScript. Trate o GA4 como um sinal, não como o único.

#Como encontrar IPs de bots nos registos de acesso do nginx

Na DigitalOcean tem normalmente registos de acesso do nginx e, se estiverem ativas, jails do fail2ban. Verificações úteis:

# Endereços mais frequentes no último registo de acesso (ajuste o caminho)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# Caminhos que parecem sondagens
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -40

# User-Agents dominantes
awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Cruze os picos do GA4 com as horas nesses registos. Se o GA4 salta às 03:00 UTC e o registo de acesso mostra os mesmos IPs a martelar o xmlrpc.php, tem um problema do lado do servidor que os filtros de analítica, sozinhos, não resolvem.

Anote também a carga de CPU do servidor e o comprimento da fila do PHP-FPM durante o pico. O ruído de bots que nunca chega ao GA4 pode mesmo assim esgotar um droplet pequeno.

#O GA4 filtra o tráfego de bots automaticamente

Em parte. O artigo de ajuda da Google sobre tráfego de bots conhecidos diz que o GA4 exclui automaticamente o tráfego de bots e spiders conhecidos. A lista por trás disso combina a investigação da própria Google com a International Spiders and Bots List, mantida pelo Interactive Advertising Bureau (IAB).

Dois pormenores dessa página importam aqui. Não pode desativar a exclusão e não consegue ver quanto tráfego ela removeu. Por isso, quando o GA4 continua a mostrar sessões de lixo, esses clientes não estavam na lista: normalmente são navegadores headless em servidores alugados que executam a sua tag como um visitante comum. A exclusão automática também não faz nada aos pedidos que não executam JavaScript, porque o GA4 nunca os recebe.

É dessa lacuna que trata o resto do guia. O GA4 trata dos crawlers que se identificam; o seu servidor e a periferia da rede têm de lidar com os clientes que escondem o que são.

#Como excluir gamas de IP de bots com filtros de dados do GA4

Os filtros de dados do GA4 existem em três tipos: tráfego de programadores (modo de depuração), tráfego interno (por endereço IP ou gama) e nomes de anfitrião indesejados. Não existe um tipo para bots, por isso a única ferramenta baseada em IP é o filtro de tráfego interno.

Funciona em dois passos, descritos no guia da Google para definir tráfego interno. Primeiro, em Admin, na secção Data collection and modification, abre Data streams, escolhe o fluxo web, vai a Configure tag settings, depois a Define internal traffic, e cria uma regra. Os eventos que correspondem recebem o parâmetro traffic_type. O valor predefinido é internal, mas pode definir o seu, por exemplo bot_do, para que uma regra de bots nunca se misture com a regra do escritório. As condições de IP aceitam correspondência exata, começa por, termina em, contém, uma gama CIDR ou uma expressão regular. No segundo passo, em Data filters, cria um filtro do tipo Internal Traffic que exclui esse valor de traffic_type.

Limites que convém conhecer antes de confiar nisto:

• Uma propriedade pode ter no máximo 10 filtros de dados.
• Cada filtro está em Testing, Active ou Inactive. Em teste, os eventos correspondentes ficam marcados com a dimensão Test data filter name, que pode inspecionar em Explore antes de qualquer coisa ser removida.
• Um filtro ativo altera os dados recebidos de forma permanente e não se aplica a dados históricos. Segundo a Google, um filtro pode demorar 24 a 36 horas a entrar em vigor.
• Para uma vista temporária sem perda de dados, a Google remete para os filtros de relatório.

Uma sequência mais segura: mantenha uma regra de IPs de bots em teste durante uma semana completa, compare as sessões marcadas com o que o registo do nginx mostra para os mesmos endereços e só passe a ativo quando o tráfego marcado for claramente lixo. Mantenha a lista de regras curta e anote a data em que cada gama foi adicionada. E não se esqueça do que este filtro é: uma correção dos relatórios. Os pedidos continuam a chegar ao nginx, ao PHP e ao MySQL; o GA4 apenas deixa de os contar.

#Como verificar a quem pertence um IP antes de o bloquear

Um endereço num registo diz pouco até saber quem o anuncia. O whois dá-lhe o registo do registry. A API de dados do RIPEstat dá a vista de encaminhamento, ou seja, o prefixo e o sistema autónomo (AS) que o anuncia neste momento:

whois 5.101.96.1 | grep -iE "orgname|org-name|netname"
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=5.101.96.1"
curl -s "https://stat.ripe.net/data/as-overview/data.json?resource=AS14061"

Quando corremos as duas chamadas à API a 14 de outubro de 2026, o RIPEstat devolveu o prefixo 5.101.96.0/21 anunciado pelo AS14061 e indicou como titular do AS14061 DIGITALOCEAN-ASN, DigitalOcean, LLC. O endpoint network-info é gratuito e responde para endereços de todos os registos regionais, não só do RIPE.

Leia o sufixo CIDR antes de colar uma gama em qualquer lado. O número depois da barra conta os bits fixos do prefixo: um /24 tem 256 endereços, um /16 tem 65 536 e um /14 tem 262 144. Uma única linha antiga como deny from 104.236.0.0/16 bloqueia 65 536 endereços, quase todos sem relação com o cliente que o incomodou.

#Onde encontrar as gamas de IP atuais da DigitalOcean

A DigitalOcean publica o seu espaço de endereços num ficheiro CSV, com a ligação DigitalOcean IP Ranges na documentação da plataforma, e indica que o ficheiro é atualizado automaticamente. Cada linha contém o prefixo, o código do país, a região, a cidade e o código postal.

A 14 de outubro de 2026 o ficheiro tinha 1234 prefixos, 148 deles IPv6. Por país, 654 linhas eram dos Estados Unidos, 224 dos Países Baixos, 111 da Alemanha, 90 de Singapura e 67 do Reino Unido. Essa dispersão é o argumento prático contra o bloqueio geral: os mesmos prefixos alojam droplets de agências, ferramentas SaaS, monitores de disponibilidade, runners de CI e empresas comuns, ao lado dos scrapers.

Use o ficheiro para consulta, não como lista de bloqueio. Quando um endereço domina o registo de acesso, verifique se está no espaço da DigitalOcean:

curl -s -o do-ranges.csv https://www.digitalocean.com/geo/google.csv
python3 -c 'import csv,ipaddress,sys; nets=[ipaddress.ip_network(r[0]) for r in csv.reader(open("do-ranges.csv")) if r]; ip=ipaddress.ip_address(sys.argv[1]); print(any(ip in n for n in nets))' 5.101.96.1

Um True diz-lhe que o cliente corre num servidor da DigitalOcean. Não diz que é malicioso; isso decide-o o comportamento no registo.

#O robots.txt consegue bloquear bots maus

O robots.txt é um protocolo voluntário. Os crawlers cooperantes leem-no e saltam os caminhos proibidos. Os clientes abusivos ignoram-no.

Use o robots.txt para orientar os bons bots:

• Proíba caminhos de staging, URLs de resultados de pesquisa e endpoints de administração que não quer indexados
• Seja moderado com o crawl-delay e com regras Disallow amplas; bloquear demais pode esconder páginas que ainda quer na pesquisa
• Coloque áreas sensíveis atrás de autenticação, não apenas atrás de uma linha Disallow

Não espere que uma regra Disallow trave o credential stuffing em /wp-login.php. Esse pedido, na prática, nunca consulta o robots.txt. Firewall, limitação de taxa e autenticação pertencem ao servidor ou à periferia da rede.

Uma divisão prática:

#Como verificar o Googlebot antes de bloquear um IP

Bloquear o Googlebot pela string do User-Agent é um autogolo clássico. Strings Googlebot falsificadas são comuns; o Googlebot verdadeiro verifica-se com DNS inverso e confirmação direta. A Google descreve o processo em Verificar o Googlebot.

Antes de recusar um IP que diz ser o Googlebot:

1. Faça uma consulta de DNS inverso ao IP.
2. Confirme que o nome do anfitrião termina num domínio da Google indicado pela documentação da Google.
3. Resolva esse nome do anfitrião no sentido direto e confirme que devolve o IP original.
4. Só então trate o cliente como Googlebot (ou não).

Nunca acrescente uma regra do género “recusar se o User-Agent contiver Googlebot” como medida de segurança. Bloqueia o crawler verdadeiro quando alguém falsifica a string noutro lado e não trava quem falsifica com outra string.

A mesma cautela aplica-se ao Bingbot e a outros crawlers identificados que lhe interessam. Use listas de permissão para gamas de crawlers verificados só quando as mantém com cuidado; para tudo o resto, prefira limites baseados no comportamento.

#Como limitar bots na DigitalOcean com nginx e fail2ban

Num droplet LEMP típico, o sítio mais barato para cortar abusos é o nginx, antes de o PHP-FPM e o autoload do WordPress arrancarem.

#limit_req do nginx para wp-login.php e xmlrpc.php

O módulo ngx_http_limit_req_module limita a taxa de pedidos por chave (normalmente o IP). Um padrão conservador para o login e o XML-RPC fica assim:

# contexto http
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=wp_xmlrpc:10m rate=1r/s;

# exemplos para server / location
location = /wp-login.php {
    limit_req zone=wp_login burst=5 nodelay;
    include fastcgi_params;
    # ... handler PHP existente ...
}

location = /xmlrpc.php {
    limit_req zone=wp_xmlrpc burst=2 nodelay;
    # Muitos sites devolvem 403 aqui se não precisam de XML-RPC
}

Ajuste as taxas a partir da sua base. Uma redação com muitos editores atrás de um NAT partilhado precisa de um burst maior do que um site institucional. Registe as rejeições do limit_req e esteja atento a falsos positivos vindos dos IPs de saída do escritório.

Outros hábitos de nginx que ajudam em droplets da DO:

• Desative ou restrinja fortemente o xmlrpc.php se não o usa
• Limite os POST a admin-ajax.php de clientes anónimos quando os plugins o permitem
• Termine o TLS no nginx (ou na Cloudflare) e mantenha abertas na firewall cloud da DigitalOcean apenas as portas necessárias

#Jails do fail2ban para o login do WordPress e caminhos de sondagem

O fail2ban vigia os registos e acrescenta banimentos temporários na firewall quando um filtro corresponde. Os jails típicos para WordPress vigiam os registos do nginx à procura de 401/403/404 repetidos no login e em caminhos de sondagem. Mantenha os jails estreitos:

• Bana por minutos ou horas, não para sempre, até confiar no filtro
• Exclua a VPN do escritório e os serviços de monitorização
• Volte a verificar depois de atualizações do WordPress ou de plugins que alterem o formato dos registos

O fail2ban é excelente contra scanners ruidosos. É um mau substituto para corrigir um endpoint exposto de um plugin que responde 200 a cada sondagem.

#Que portas abrir na firewall cloud da DigitalOcean

Use a firewall da DO (ou equivalente) para abrir 22/80/443 ao mundo só se for mesmo necessário, e prefira SSH com chaves a partir de IPs conhecidos. Os bloqueios de rede travam pacotes antes do nginx. Mesmo assim, não devem ser “bloquear todos os /16 da DigitalOcean do planeta”, o que apanharia clientes, agências e runners de CI alojados no mesmo fornecedor.

#Os plugins de firewall do WordPress travam o tráfego de bots

Plugins como o Wordfence, o Sucuri e outras suites de segurança sólidas acrescentam proteção do login, análise de malware e regras de aplicação. Ajudam. Mas só correm depois de o nginx ter aceitado a ligação e de o PHP ter arrancado.

Ressalvas que importam para limpar a analítica:

• Custo de CPU: cada pedido bloqueado pagou na mesma o arranque do PHP, a menos que algo o tenha rejeitado antes.
• Falsos positivos: regras agressivas como “bloquear países desconhecidos” ou “bloquear todos os ASN cloud” podem deixar de fora freelancers, agências e fornecedores de pagamentos.
• Sobreposição com a WAF na periferia: regras duplicadas na Cloudflare e no plugin dificultam a depuração quando um utilizador legítimo é desafiado duas vezes.
• Ruído nos registos: os registos do plugin e o GA4 não vão coincidir, porque veem camadas diferentes.

As orientações do manual de hardening do WordPress continuam válidas: mantenha o núcleo e os plugins atualizados, dê aos utilizadores da base de dados o mínimo de privilégios e restrinja as permissões de ficheiros. Um plugin de firewall não substitui estas bases.

Ordem prática de trabalho:

1. Corrija endpoints expostos e credenciais fracas.
2. Acrescente limites no nginx e fail2ban para caminhos ruidosos.
3. Acrescente uma firewall do WordPress para regras conscientes da aplicação e alertas.
4. Acrescente as ferramentas da Cloudflare contra bots se já usa essa CDN.

#Como bloquear bots com a Cloudflare antes de chegarem ao WordPress

Se o site está atrás da Cloudflare, use a documentação sobre bots deles em vez de inventar listas de bloqueio de User-Agent no servidor. As regras na periferia conseguem:

• Desafiar ou bloquear tráfego automatizado evidente antes de chegar à DigitalOcean
• Limitar caminhos específicos (/wp-login.php, /xmlrpc.php)
• Deixar passar bots de motores de pesquisa verificados, quando configura isso com cuidado

As regras do nginx no servidor continuam a contar como defesa em profundidade, caso alguém contorne o proxy (nuvem cinzenta no DNS, IP direto do servidor). Em modo de proxy completo, feche a firewall do droplet para que só as gamas de IP da Cloudflare (ou os seus IPs de administração) falem com as portas 80/443.

A Cloudflare não torna o GA4 exato por magia. Reduz os acessos abusivos que teriam executado tags ou esgotado o PHP. Meça tanto a analítica da periferia como o GA4 depois de alterar o Bot Fight Mode ou as regras da WAF, porque os desafios também podem mudar a forma como os utilizadores reais concluem uma sessão.

#Como desafiar o tráfego da DigitalOcean com regras personalizadas da WAF da Cloudflare

As regras personalizadas da WAF da Cloudflare conseguem identificar a rede de onde vem um pedido. O campo chama-se ip.src.asnum e contém o número de AS do IP do cliente; a rede da DigitalOcean é o AS14061. Uma regra dirigida ao AS substitui a manutenção manual de 1234 prefixos.

Mantenha o âmbito estreito. Uma regra que só toca no tráfego da DigitalOcean nos caminhos que os bots exploram fica assim:

(ip.src.asnum eq 14061 and http.request.uri.path in {"/wp-login.php" "/xmlrpc.php"})

Escolha Managed Challenge como ação, não Block. Uma pessoa a trabalhar através de uma VPN alojada num droplet passa o desafio; um script simples normalmente não. Block termina o pedido e, como a Cloudflare avalia as regras personalizadas por ordem, também impede todas as regras personalizadas seguintes para esse pedido.

O plano decide quantas regras destas pode ter. A Cloudflare indica 5 regras personalizadas no Free, 20 no Pro, 100 no Business e 1000 no Enterprise, e o operador de expressões regulares só no Business e no Enterprise. Numa zona gratuita, uma regra para o desafio por ASN nos caminhos de login deixa quatro para problemas que não consegue resolver no servidor.

#Deve bloquear as gamas de IP da DigitalOcean e da AWS

Conselhos mais antigos colavam no .htaccess longas listas deny from para gamas inteiras da DigitalOcean ou da AWS. Essa abordagem envelhece mal:

• As gamas dos fornecedores mudam
• O tráfego legítimo partilha essas gamas
• A sintaxe deny do Apache não serve de nada se serve o WordPress através do nginx sem Apache

Se ainda usa Apache, prefira endereços individuais confirmados ou pequenos blocos CIDR dos seus registos, não uma megalista copiada:

# Apenas um exemplo da forma - substitua por IPs confirmados nos seus próprios registos
# As diretivas RequireAll / Require dependem da sintaxe de autorização do Apache 2.4
<RequireAll>
    Require all granted
    # Require not ip 203.0.113.10
</RequireAll>

No nginx, use deny dentro de um bloco geo/map ou o fail2ban e deixe um comentário curto com a data e o motivo do banimento. Reveja os banimentos todos os trimestres.

Nunca publique nem confie em tabelas de “IPs de bots conhecidos” de artigos aleatórios sem as verificar. Ficam desatualizadas e provocam danos colaterais.

Os limites do bloqueio por IP ficaram à vista no ataque à Read the Docs em junho de 2026, que David Fischer descreveu a 8 de setembro de 2026. No pico chegavam mais de 5,5 milhões de pedidos por minuto, cerca de 100 vezes o tráfego normal, durante quase dez dias, a partir de milhões de IP únicos em centenas de redes (ASN). Os atacantes visaram caminhos 404 e redirecionamentos 302 sem cache; a equipa passou os redirecionamentos para o edge da Cloudflare em cerca de meia hora, e segundo Fischer o que provavelmente fez mais diferença foi uma regra de “penalty box”, que limita os clientes que acumulam muitas respostas 404 ou de redirecionamento. A primeira lição do texto é que “o bloqueio por IP está obsoleto para ataques distribuídos” (tradução própria), e a resposta mais dura da Read the Docs é um desafio JavaScript. No WordPress aplica-se a mesma lógica: coloque em cache no edge as respostas 404 e os redirecionamentos e limite os clientes suspeitos, em vez de bloquear gamas inteiras de nuvem.

#Como confirmar no GA4 que o tráfego de bots desceu

Depois de aplicar limites ou banimentos, espere o mesmo tempo que durou a base (7 ou 28 dias). Depois compare:

1. Utilizadores / Sessões / Sessões com envolvimento: procure uma descida do volume de lixo enquanto as sessões com envolvimento se mantêm ou sobem.
2. Páginas de destino: os URLs de sondagem devem encolher no GA4 se esses clientes executavam JS; nos registos do nginx devem encolher de qualquer forma.
3. Aquisição de tráfego: as fontes misteriosas sem envolvimento devem cair.
4. Métricas do servidor: os workers ocupados do PHP-FPM e as taxas de 5xx fora do horário devem aliviar, se o abuso no servidor era real.
5. Search Console: as estatísticas de rastreamento e a cobertura não devem colapsar. Se colapsarem, provavelmente bloqueou um crawler verdadeiro; reverta e verifique o Googlebot como deve ser.

Anote a data da alteração no GA4 (Admin > Anotações, ou o registo de alterações da equipa) para mais tarde se lembrar do que mexeu na linha.

Se o GA4 quase não se mexe mas as rejeições no nginx sobem, os bots nunca executaram a sua tag. Continua a ser um ganho para a saúde do servidor, mesmo que o gráfico da analítica pareça calmo.

Se o GA4 cai a pique e os erros de rastreamento na Search Console disparam, desfaça primeiro a última regra deny. Uma analítica limpa não vale nada se a indexação partir.

#Lista de verificação para travar tráfego de bots no WordPress

Siga-a por ordem:

1. Crie a base do GA4 (7/28 dias) e recolha uma amostra dos registos de acesso do nginx.
2. Confirme se o ruído executa JS (GA4) ou se só chega ao servidor (registos).
3. Aperte os limites de xmlrpc.php e do login no nginx.
4. Acrescente jails do fail2ban para sondagens repetidas; exclua os seus próprios IPs.
5. Mantenha o robots.txt focado em orientar crawlers, não em teatro de segurança.
6. Acrescente ou afine uma firewall do WordPress sem bloquear fornecedores cloud inteiros.
7. Opcionalmente, ative os controlos de bots e WAF da Cloudflare se o site já usa a Cloudflare.
8. Volte a medir o GA4 e os registos num período equivalente; acompanhe a Search Console.

Se quer ajuda para rever o ruído de crawlers, as regras do servidor e a higiene da analítica em conjunto com um trabalho de SEO e GEO mais amplo, isso faz mais sentido do que colar listas de bloqueio eternas na raiz do WordPress. Bloquear gamas de IP é fácil, bloquear apenas aquilo que se quer mesmo bloquear é que dá trabalho; quando essa afinação tiver de conviver com cache, CDN e analítica, conte com a nossa experiência em desenvolvimento e manutenção WordPress.