Como bloquear el tráfico de bots en WordPress Analytics

Si tus informes de GA4 muestran picos repentinos desde regiones desconocidas, duraciones de sesión idénticas o páginas de destino que nadie comparte, muchas veces estás viendo bots que aun así disparan la etiqueta de analítica. El objetivo no es bloquear todos los rastreadores. El objetivo es eliminar la basura que contamina las decisiones y dejar tranquilos a Googlebot, Bingbot y los visitantes reales.

Esta guía es para WordPress en un droplet de DigitalOcean (o un VPS similar) con nginx, opcionalmente fail2ban, y GA4. Trata robots.txt, los firewalls de servidor, los plugins de WordPress y las herramientas antibots de la CDN como capas distintas con tareas distintas. Si necesitas trabajo de rastreo y citaciones más allá de la higiene del tráfico, conoce los servicios de optimización SEO y GEO de WPPoland.

#Por qué los bots maliciosos inflan Google Analytics

GA4 cuenta un acceso cuando un navegador (o un navegador headless que se comporta como tal) ejecuta su etiqueta y envía eventos. Eso significa que tres poblaciones distintas aparecen en lugares distintos:

• Los scrapers que ejecutan JavaScript y las herramientas de fraude de clics pueden aparecer en GA4 como sesiones, vistas de página e incluso conversiones si aciertan con las URL adecuadas.
• Los scrapers HTTP simples a menudo no ejecutan JavaScript, así que no llegan a GA4 y aun así cargan PHP, MySQL y cualquier plantilla sin caché en el servidor.
• Los rastreadores de buscadores identificados deberían aparecer en los logs del servidor y en Search Console, no como una gran parte de los “Usuarios” de GA4.

Cuando crece el grupo que ejecuta JavaScript, los informes de adquisición y de interacción se desvían. La tasa de rebote y el tiempo medio de interacción se ven raros. Los informes de pago y orgánicos se llenan de ruido. Los equipos empiezan a optimizar para tráfico que nunca compra nada.

Formas habituales del tráfico malicioso (sin inventar IP concretas):

• Mucho volumen de solicitudes desde un pequeño grupo de ASN de nube, sin referrer y con User-Agents extraños
• Accesos repetidos a /wp-login.php, xmlrpc.php, consultas que enumeran autores o rutas antiguas de plugins
• Sesiones que solo aterrizan en URL pobres y rebotan en menos de un segundo, pero que aun así generan eventos page_view en GA4
• Tráfico “orgánico” que en el mismo periodo nunca coincide con los datos de consultas de Search Console

Proveedores de nube como DigitalOcean y AWS alojan muchísimos sitios legítimos. También alojan scrapers. Ese solapamiento es la razón por la que las reglas generales del tipo “denegar todo este /16” son arriesgadas. Prefiere fuentes confirmadas en tus propios logs antes que listas copiadas de artículos antiguos.

#Cómo detectar tráfico de bots en GA4 y en los logs del servidor

Cambiar algo sin una referencia es contar historias. Recoge una referencia de al menos siete días si puedes, o de una semana laboral completa si el tráfico es estacional.

#Cómo detectar tráfico de bots en los informes de GA4

Antes de tocar nginx o fail2ban, prepara una vista de comparación sencilla:

1. Anota Usuarios, Sesiones, Sesiones con interacción y Vistas de los últimos 7 y 28 días.
2. Abre Adquisición de tráfico y busque fuentes con una interacción absurda (tiempo de interacción cercano a cero, rebote cercano al 100% en todas las páginas de destino).
3. Revisa Tecnología > Navegador y Dispositivo en busca de clientes vacíos, desconocidos o claramente automatizados.
4. Mira en Página de destino las rutas que solo gustan a los bots (/?author=1, spam antiguo en parámetros, ID de productos inexistentes).
5. Exporta el periodo o haz una captura de pantalla para comparar después lo mismo con lo mismo (misma duración, misma mezcla de días de la semana).

GA4 ya elimina por su cuenta los bots conocidos (lo vemos en la siguiente sección), pero esa lista no atrapa a todos los clientes abusivos que ejecutan JavaScript. Trata GA4 como una señal, no como la única.

#Cómo encontrar IP de bots en los logs de acceso de nginx

En DigitalOcean sueles tener los logs de acceso de nginx y, si están activados, los jails de fail2ban. Comprobaciones útiles:

# Direcciones más frecuentes en el último log de acceso (ajuste la ruta)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# Rutas que parecen sondeos
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

Cruza los picos de GA4 con las marcas de tiempo de esos logs. Si GA4 se dispara a las 03:00 UTC y el log de acceso muestra las mismas IP martilleando xmlrpc.php, tienes un problema de servidor que los filtros de analítica por sí solos no resolverán.

Anota también la carga de CPU del servidor y la longitud de la cola de PHP-FPM durante el pico. El ruido de bots que nunca llega a GA4 puede igualmente agotar un droplet pequeño.

#GA4 filtra el tráfico de bots automáticamente

En parte. El artículo de ayuda de Google sobre el tráfico de bots conocidos dice que GA4 excluye automáticamente el tráfico de bots y arañas conocidos. La lista en la que se basa combina la investigación propia de Google con la International Spiders and Bots List que mantiene el Interactive Advertising Bureau (IAB).

Dos detalles de esa página importan aquí. No puedes desactivar la exclusión y no puedes ver cuánto tráfico ha eliminado. Por eso, cuando GA4 sigue mostrando sesiones basura, esos clientes no estaban en la lista: normalmente son navegadores headless en servidores alquilados que ejecutan tu etiqueta como un visitante cualquiera. La exclusión automática tampoco hace nada con las solicitudes que no ejecutan JavaScript, porque GA4 nunca las recibe.

De ese hueco trata el resto de la guía. GA4 se ocupa de los rastreadores que se identifican; tu servidor y tu edge tienen que ocuparse de los clientes que ocultan lo que son.

#Cómo excluir rangos de IP de bots con los filtros de datos de GA4

Los filtros de datos de GA4 son de tres tipos: tráfico de desarrolladores (modo de depuración), tráfico interno (por dirección IP o rango) y nombres de host no deseados. No existe un tipo para bots, así que la única herramienta basada en IP es el filtro de tráfico interno.

Funciona en dos pasos, descritos en la guía de Google para definir el tráfico interno. Primero, en Admin, dentro de Data collection and modification, abre Data streams, elige el flujo web, ve a Configure tag settings, luego a Define internal traffic, y crea una regla. Los eventos que coinciden reciben el parámetro traffic_type. Su valor predeterminado es internal, pero puedes definir el tuyo, por ejemplo bot_do, para que una regla de bots nunca se mezcle con la regla de la oficina. Las condiciones de IP admiten coincidencia exacta, empieza por, termina en, contiene, un rango CIDR o una expresión regular. En el segundo paso, en Data filters, crea un filtro de tipo Internal Traffic que excluye ese valor de traffic_type.

Límites que conviene conocer antes de confiar en él:

• Una propiedad puede tener como máximo 10 filtros de datos.
• Cada filtro está en Testing, Active o Inactive. En prueba, los eventos que coinciden quedan marcados con la dimensión Test data filter name, que puedes revisar en Explore antes de que se elimine nada.
• Un filtro activo cambia los datos entrantes de forma permanente y no se aplica a los datos históricos. Según Google, un filtro puede tardar entre 24 y 36 horas en aplicarse.
• Para una vista temporal sin perder datos, Google remite a los filtros de informe.

Una secuencia más segura: mantén una regla de IP de bots en prueba durante una semana completa, compare las sesiones marcadas con lo que el log de nginx muestra para esas mismas direcciones y actívala solo cuando el tráfico marcado sea claramente basura. Mantén la lista de reglas corta y anota la fecha en que añadiste cada rango. Y recuerda qué es este filtro: un arreglo de los informes. Las solicitudes siguen llegando a nginx, PHP y MySQL; GA4 simplemente deja de contarlas.

#Cómo comprobar a quién pertenece una IP antes de bloquearla

Una dirección en un log dice poco hasta que sabes quién la anuncia. whois te da el registro del registro regional. La API de datos de RIPEstat te da la vista de enrutamiento, es decir, el prefijo y el sistema autónomo (AS) que lo anuncia ahora mismo:

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"

Cuando ejecutamos las dos llamadas a la API el 14 de octubre de 2026, RIPEstat devolvió el prefijo 5.101.96.0/21 anunciado por AS14061 e indicó como titular de AS14061 a DIGITALOCEAN-ASN, DigitalOcean, LLC. El endpoint network-info es gratuito y responde para direcciones de todos los registros regionales, no solo de RIPE.

Lee el sufijo CIDR antes de pegar un rango en cualquier sitio. El número después de la barra indica los bits fijos del prefijo: un /24 contiene 256 direcciones, un /16 contiene 65.536 y un /14 contiene 262.144. Una sola línea antigua como deny from 104.236.0.0/16 deja fuera 65.536 direcciones, casi todas sin relación con el cliente que te molestaba.

#Dónde encontrar los rangos de IP actuales de DigitalOcean

DigitalOcean publica su espacio de direcciones en un archivo CSV, enlazado como DigitalOcean IP Ranges en su documentación de la plataforma, e indica que el archivo se actualiza automáticamente. Cada fila contiene el prefijo, el código de país, la región, la ciudad y el código postal.

El 14 de octubre de 2026 el archivo tenía 1.234 prefijos, 148 de ellos IPv6. Por países, 654 filas correspondían a Estados Unidos, 224 a Países Bajos, 111 a Alemania, 90 a Singapur y 67 a Reino Unido. Esa dispersión es el argumento práctico contra el bloqueo general: en los mismos prefijos funcionan droplets de agencias, herramientas SaaS, monitores de disponibilidad, runners de CI y empresas corrientes, junto a los scrapers.

Usa el archivo para consultar, no como lista de bloqueo. Cuando una dirección domine tu log de acceso, comprueba si está en el espacio de 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

Un True te dice que el cliente funciona en un servidor de DigitalOcean. No te dice que sea malicioso; eso lo decide su comportamiento en el log.

#Puede robots.txt bloquear a los bots maliciosos

robots.txt es un protocolo voluntario. Los rastreadores cooperativos lo leen y se saltan las rutas prohibidas. Los clientes abusivos lo ignoran.

Usa robots.txt para guiar a los bots buenos:

• Prohíbe rutas de staging, URL de resultados de búsqueda y endpoints de administración que no quieras indexados
• Sé moderado con crawl-delay y con reglas Disallow amplias; bloquear de más puede ocultar páginas que todavía quieres en los resultados
• Protege las zonas sensibles con autenticación, no solo con una línea Disallow

No esperes que una regla Disallow detenga el credential stuffing en /wp-login.php. Esa solicitud, en la práctica, nunca consulta robots.txt. El firewall, la limitación de tasa y la autenticación pertenecen al servidor o al edge.

Un reparto práctico:

#Cómo verificar Googlebot antes de bloquear una IP

Bloquear Googlebot por la cadena de User-Agent es un clásico gol en propia puerta. Las cadenas Googlebot falsificadas son habituales; el Googlebot real se verifica con DNS inverso y confirmación directa. Google documenta el proceso en Verificar Googlebot.

Antes de denegar una IP que dice ser Googlebot:

1. Haz una consulta de DNS inverso sobre la IP.
2. Confirma que el nombre de host termina en un dominio de Google según la documentación de Google.
3. Resuelve ese nombre de host en sentido directo y confirma que coincide con la IP original.
4. Solo entonces trata al cliente como Googlebot (o no).

Nunca añadas una regla del tipo “denegar si el User-Agent contiene Googlebot” como control de seguridad. Bloquea al rastreador real cuando alguien falsifica la cadena en otro sitio y no detiene a quien falsifica con otra cadena.

La misma cautela vale para Bingbot y otros rastreadores identificados que te importen. Usa listas de permitidos para rangos de rastreadores verificados solo cuando las mantengas con cuidado; para todo lo demás, prefiere límites basados en el comportamiento.

#Cómo limitar bots en DigitalOcean con nginx y fail2ban

En un droplet LEMP típico, el lugar más barato para cortar abusos es nginx, antes de que arranquen PHP-FPM y el autoload de WordPress.

#limit_req de nginx para wp-login.php y xmlrpc.php

El módulo ngx_http_limit_req_module limita la tasa de solicitudes por clave (normalmente la IP). Un patrón conservador para el login y XML-RPC es este:

# 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;

# ejemplos de 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;
    # Muchos sitios devuelven 403 aquí si no necesitan XML-RPC
}

Ajusta las tasas a partir de tu referencia. Una redacción con muchos editores detrás de un NAT compartido necesitará un burst mayor que un sitio corporativo sencillo. Registra los rechazos de limit_req y vigila los falsos positivos desde las IP de salida de la oficina.

Otros hábitos de nginx que ayudan en los droplets de DO:

• Desactiva o restringe mucho xmlrpc.php si no lo usas
• Limita los POST a admin-ajax.php de clientes anónimos cuando los plugins lo permitan
• Termina TLS en nginx (o en Cloudflare) y deja abiertos en el firewall de nube de DigitalOcean solo los puertos necesarios

#Jails de fail2ban para el login de WordPress y las rutas de sondeo

fail2ban vigila los logs y añade bloqueos temporales en el firewall cuando coincide un filtro. Los jails típicos para WordPress vigilan los logs de nginx en busca de 401/403/404 repetidos en el login y en rutas de sondeo. Mantén los jails acotados:

• Banea durante minutos u horas, no para siempre, hasta que confíes en el filtro
• Excluye la VPN de tu oficina y los servicios de monitorización
• Vuelve a revisar tras actualizaciones de WordPress o de plugins que cambien el formato de los logs

fail2ban es excelente contra escáneres ruidosos. Es un mal sustituto de corregir un endpoint expuesto de un plugin que responde 200 a cada sondeo.

#Qué puertos abrir en el firewall de nube de DigitalOcean

Usa el firewall de DO (o su equivalente) para abrir 22/80/443 a todo el mundo solo si es imprescindible, y prefiere SSH con claves desde IP conocidas. Los bloqueos de red detienen los paquetes antes de nginx. Aun así, no deberían ser “bloquear todos los /16 de DigitalOcean del planeta”, porque atraparían a clientes, agencias y runners de CI alojados en el mismo proveedor.

#Detienen los plugins de firewall de WordPress el tráfico de bots

Plugins como Wordfence, Sucuri y otras suites de seguridad sólidas añaden protección del login, análisis de malware y reglas de aplicación. Ayudan. Pero se ejecutan cuando nginx ya ha aceptado la conexión y PHP ya ha arrancado.

Salvedades que importan para limpiar la analítica:

• Coste de CPU: cada solicitud bloqueada ya pagó el arranque de PHP, salvo que algo la rechazara antes.
• Falsos positivos: reglas agresivas como “bloquear países desconocidos” o “bloquear todos los ASN de nube” pueden dejar fuera a freelancers, agencias y proveedores de pago.
• Solapamiento con la WAF del edge: las reglas duplicadas en Cloudflare y en el plugin complican la depuración cuando un usuario legítimo recibe dos desafíos.
• Ruido en los logs: los logs del plugin y GA4 no coincidirán, porque ven capas distintas.

Las indicaciones del manual de hardening de WordPress siguen vigentes: mantén el núcleo y los plugins actualizados, da a los usuarios de la base de datos los privilegios mínimos y restringe los permisos de archivos. Un plugin de firewall no sustituye esa base.

Orden práctico de trabajo:

1. Corrige endpoints expuestos y credenciales débiles.
2. Añade límites de nginx y fail2ban para las rutas ruidosas.
3. Añade un firewall de WordPress para reglas con contexto de aplicación y alertas.
4. Añade las herramientas antibots de Cloudflare si ya usas esa CDN.

#Cómo bloquear bots con Cloudflare antes de que lleguen a WordPress

Si el sitio está detrás de Cloudflare, usa su documentación sobre bots en lugar de inventar listas de denegación por User-Agent en el servidor. Las reglas en el edge pueden:

• Desafiar o bloquear el tráfico automatizado evidente antes de que llegue a DigitalOcean
• Limitar la tasa en rutas concretas (/wp-login.php, /xmlrpc.php)
• Dejar pasar a los bots verificados de buscadores si lo configuras con cuidado

Las reglas de nginx en el servidor siguen importando como defensa en profundidad si alguien se salta el proxy (nube gris en el DNS, IP directa del servidor). En modo de proxy completo, cierra el firewall del droplet para que solo los rangos de IP de Cloudflare (o tus IP de administración) puedan hablar con los puertos 80/443.

Cloudflare no hace que GA4 sea exacto por arte de magia. Reduce los accesos abusivos que habrían ejecutado etiquetas o agotado PHP. Mide tanto la analítica del edge como GA4 después de cambiar Bot Fight Mode o las reglas de la WAF, porque los desafíos también pueden cambiar la forma en que los usuarios reales completan una sesión.

#Cómo desafiar el tráfico de DigitalOcean con reglas personalizadas de la WAF de Cloudflare

Las reglas personalizadas de la WAF de Cloudflare pueden identificar la red de la que procede una solicitud. El campo es ip.src.asnum, el número de AS de la IP del cliente, y la red de DigitalOcean es AS14061. Una regla dirigida al AS sustituye el mantenimiento manual de 1.234 prefijos.

Mantén el alcance acotado. Una regla que solo afecta al tráfico de DigitalOcean en las rutas que los bots explotan queda así:

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

Elige Managed Challenge como acción, no Block. Una persona que trabaja a través de una VPN alojada en un droplet puede superar el desafío; un script sencillo normalmente no. Block termina la solicitud y, como Cloudflare evalúa las reglas personalizadas en orden, también impide que se ejecuten las reglas personalizadas posteriores para esa solicitud.

El plan decide cuántas reglas de este tipo puedes permitirte. Cloudflare indica 5 reglas personalizadas en Free, 20 en Pro, 100 en Business y 1.000 en Enterprise, y el operador de expresiones regulares solo en Business y Enterprise. En una zona gratuita, una regla para el desafío por ASN en las rutas de login deja cuatro para problemas que no puedes resolver en el servidor.

#Conviene bloquear los rangos de IP de DigitalOcean y AWS

Los consejos antiguos pegaban en .htaccess largas listas deny from para rangos completos de DigitalOcean o AWS. Ese enfoque envejece mal:

• Los rangos de los proveedores cambian
• El tráfico legítimo comparte esos rangos
• La sintaxis deny de Apache no sirve de nada si sirves WordPress con nginx sin Apache

Si todavía usas Apache, prefiere direcciones sueltas confirmadas o bloques CIDR pequeños de tus logs, no una megalista copiada:

# Solo un ejemplo de la forma - sustituya por IP confirmadas en sus propios logs
# Las directivas RequireAll / Require dependen de la sintaxis de autorización de Apache 2.4
<RequireAll>
    Require all granted
    # Require not ip 203.0.113.10
</RequireAll>

En nginx, usa deny dentro de un bloque geo/map o fail2ban, y deja un comentario breve con la fecha y el motivo del bloqueo. Revisa los bloqueos cada trimestre.

Nunca publiques ni te fíes de tablas de “IP de bots conocidos” sacadas de artículos cualquiera sin verificarlas. Se quedan obsoletas y provocan daños colaterales.

Los límites del bloqueo por IP quedaron a la vista en el ataque contra Read the Docs de junio de 2026, que David Fischer describió el 8 de septiembre de 2026. En el pico llegaban más de 5,5 millones de peticiones por minuto, unas 100 veces el tráfico normal, durante casi diez días, desde millones de IP únicas repartidas en cientos de redes (ASN). Los atacantes apuntaron a rutas 404 y redirecciones 302 sin caché; el equipo llevó las redirecciones al borde de Cloudflare en una media hora, y según Fischer lo que probablemente marcó la mayor diferencia fue una regla de “penalty box”, que limita a los clientes que acumulan muchas respuestas 404 o de redirección. La primera lección del texto es que “el bloqueo por IP está obsoleto frente a ataques distribuidos” (traducción propia), y la respuesta más dura de Read the Docs es un desafío JavaScript. En WordPress vale la misma lógica: cachear en el borde las respuestas 404 y las redirecciones y limitar a los clientes sospechosos funciona mejor que bloquear rangos enteros de la nube.

#Cómo comprobar en GA4 que el tráfico de bots ha bajado

Después de aplicar límites o bloqueos, espera el mismo tiempo que duró la referencia (7 o 28 días). Luego compara:

1. Usuarios / Sesiones / Sesiones con interacción: busca que el volumen basura baje mientras las sesiones con interacción se mantienen o suben.
2. Páginas de destino: las URL de sondeo deberían reducirse en GA4 si esos clientes ejecutaban JS; en los logs de nginx deberían reducirse en cualquier caso.
3. Adquisición de tráfico: las fuentes misteriosas sin interacción deberían caer.
4. Métricas del servidor: los workers ocupados de PHP-FPM y las tasas de 5xx fuera del horario laboral deberían aliviarse si el abuso en el servidor era real.
5. Search Console: las estadísticas de rastreo y la cobertura no deberían desplomarse. Si se desploman, probablemente bloqueaste a un rastreador real; revierte el cambio y verifica Googlebot como es debido.

Anota la fecha del cambio en GA4 (Admin > Anotaciones, o el registro de cambios de tu equipo) para recordar más adelante qué movió la línea.

Si GA4 apenas se mueve pero los rechazos de nginx aumentan, los bots nunca ejecutaban tu etiqueta. Sigue siendo una ganancia para la salud del servidor, aunque el gráfico de la analítica se vea tranquilo.

Si GA4 cae con fuerza y se disparan los errores de rastreo en Search Console, deshaz primero la última regla de denegación. Una analítica limpia no vale nada si se rompe la indexación.

#Lista de comprobación para detener el tráfico de bots en WordPress

Sigue este orden:

1. Toma la referencia de GA4 (7/28 días) y una muestra de los logs de acceso de nginx.
2. Confirma si el ruido ejecuta JS (GA4) o solo llega al servidor (logs).
3. Endurece los límites de xmlrpc.php y del login en nginx.
4. Añade jails de fail2ban para sondeos repetidos; excluye tus propias IP.
5. Mantén robots.txt centrado en guiar a los rastreadores, no en el teatro de seguridad.
6. Añade o ajusta un firewall de WordPress sin bloquear proveedores de nube completos.
7. Si el sitio ya usa Cloudflare, activa opcionalmente sus controles de bots y WAF.
8. Vuelve a medir GA4 y los logs en un periodo equivalente; vigila Search Console.

Si quieres ayuda para revisar el ruido de rastreadores, las reglas del servidor y la higiene de la analítica junto con un trabajo de SEO y GEO más amplio, eso encaja mejor que pegar listas de denegación eternas en la raíz de WordPress.