Tu WordPress está recibiendo bots: guía práctica para recuperar el control

Hay una escena bastante común: entras al panel de WordPress, notas que la web va lenta, el servidor empieza a quejarse y Analytics muestra tráfico raro desde países donde, casualmente, nunca has vendido ni un tornillo. Enhorabuena: probablemente tienes bots llamando a tu puerta. Y no, no todos vienen a indexarte con cariño.

Los bots en WordPress son como los comerciales insistentes: algunos son útiles, otros molestos y unos cuantos directamente peligrosos. El problema no es que existan, sino no tener un plan cuando empiezan a consumir recursos, llenar formularios, probar contraseñas o hacer scraping de tu contenido.

Este no es un artículo para meter miedo ni para venderte el plugin mágico de turno. Es un plan práctico, de los que aplicaría en una web de empresa, una tienda WooCommerce o un WordPress corporativo que no puede permitirse estar caído porque alguien decidió lanzar 20.000 peticiones contra /wp-login.php a las tres de la mañana.

Primero: no bloquees a lo loco, mira qué está pasando

La primera reacción suele ser instalar tres plugins de seguridad, activar todos los botones rojos y rezar. Mala estrategia. Bloquear sin mirar es una forma elegante de romper cosas.

Antes de tocar nada, revisa los logs del servidor. Apache, Nginx, LiteSpeed, Plesk, cPanel o el panel que uses. Busca patrones:

• Muchas peticiones repetidas a /wp-login.php.
• Accesos masivos a /xmlrpc.php.
• Rastreo agresivo de URLs con parámetros raros.
• User agents vacíos, falsos o sospechosamente genéricos.
• IPs distintas golpeando el mismo endpoint cada pocos segundos.
• Picos de CPU coincidiendo con tráfico no humano.

Si trabajas con hosting gestionado, pide al soporte que te confirme el origen del consumo. Aquí se nota mucho la diferencia entre un proveedor serio y uno que responde con el clásico “optimice su web”. Sobre esto encaja muy bien leer por qué el soporte experto en hosting sigue siendo imprescindible, porque cuando hay bots golpeando producción, una respuesta genérica no sirve de mucho.

Distingue entre bots buenos, bots pesados y bots basura

No todo bot es enemigo. Googlebot, Bingbot, herramientas SEO, validadores, monitores de uptime o integraciones legítimas pueden visitar tu web. El matiz está en el comportamiento.

Un bot bueno respeta ritmos razonables, identifica su user agent y normalmente no intenta iniciar sesión 500 veces. Un bot pesado puede ser legítimo pero torpe: crawlers SEO mal configurados, herramientas de scraping internas, sistemas de monitorización demasiado intensos. Y luego están los bots basura: fuerza bruta, spam, escaneo de vulnerabilidades, scraping agresivo y peticiones a plugins que ni siquiera tienes instalados.

El objetivo no es eliminar todos los bots. El objetivo es que los bots no gobiernen tu servidor.

He visto tiendas WooCommerce perder ventas no por un hackeo espectacular, sino por una tormenta de bots haciendo peticiones constantes al carrito, al buscador interno y a páginas de producto. Nada cinematográfico. Solo CPU al 100%, TTFB por las nubes y clientes reales abandonando porque la web parecía conectada por módem de 1998.

Protege wp-login.php sin convertir WordPress en un búnker inútil

El endpoint /wp-login.php es el timbre de casa. Si lo dejas expuesto, tarde o temprano alguien lo va a pulsar con un martillo.

Medidas sensatas:

• Activa limitación de intentos de inicio de sesión.
• Usa autenticación en dos pasos para administradores.
• Evita usuarios tipo admin, demo o el nombre de la empresa.
• Bloquea países si tu negocio es estrictamente local y los datos lo justifican.
• Protege el acceso con reglas a nivel servidor si tienes IP fija o VPN.
• Revisa usuarios antiguos, cuentas de pruebas y accesos de proveedores.

Cambiar la URL de login puede ayudar, pero no lo vendería como una solución de seguridad seria por sí sola. Es ocultación. Útil, sí. Suficiente, no. Lo importante es limitar el abuso, registrar eventos y tener trazabilidad.

Si quieres una base más amplia, merece la pena complementar este enfoque con la guía rápida para proteger tu web contra hackers y con los errores explicados en los errores más comunes en seguridad web. No porque haya una receta universal, sino porque casi todos los incidentes empiezan por despistes bastante humanos.

XML-RPC: el viejo conocido que sigue dando guerra

xmlrpc.php existe por razones históricas y compatibilidades concretas. El problema es que también es una autopista estupenda para ataques de fuerza bruta amplificados y tráfico inútil.

¿Lo necesitas? Si no usas Jetpack, apps móviles antiguas o integraciones que dependan de XML-RPC, probablemente puedes desactivarlo o limitarlo. Y aquí conviene probar, no hacer el clásico “lo bloqueo y ya veremos quién grita”. Porque alguien grita. Siempre.

En Nginx, Apache o LiteSpeed se puede restringir. También hay plugins que lo hacen. Personalmente prefiero resolver este tipo de cosas lo más arriba posible: firewall, servidor o WAF antes que cargar más lógica dentro de WordPress. WordPress bastante tiene ya con renderizar la web, gestionar plugins y sobrevivir a algunos constructores visuales.

Usa un WAF, pero entiende qué está haciendo

Un Web Application Firewall puede ser Cloudflare, Sucuri, Wordfence, Imunify360, reglas de ModSecurity o una combinación. Bien configurado, es una maravilla. Mal configurado, es ese compañero que bloquea al cliente real y deja pasar al bot educado que sabe disfrazarse.

Configura reglas por capas:

• Rate limiting para rutas sensibles.
• Desafíos JS o CAPTCHA solo donde tengan sentido.
• Bloqueo de user agents claramente maliciosos.
• Reglas específicas para /wp-login.php, /xmlrpc.php y formularios.
• Protección contra escaneo de plugins vulnerables.
• Alertas cuando el tráfico supere umbrales normales.

La clave es no convertir toda la web en un campo de minas. Si pones CAPTCHA en cada página, igual frenas bots, pero también frenas ventas, leads y paciencia humana. En empresas, la seguridad que rompe negocio no es seguridad: es sabotaje con buena intención.

Revisa formularios, comentarios y búsquedas internas

Muchos ataques de bots no buscan entrar al panel. Buscan abusar de formularios, comentarios, endpoints AJAX o buscadores internos. En WordPress esto es bastante habitual, especialmente en webs con formularios de contacto, reservas, encuestas, catálogos o WooCommerce.

Un formulario sin protección puede convertirse en una máquina de spam. Un buscador interno sin control puede generar miles de consultas absurdas contra la base de datos. Y una llamada AJAX mal planteada puede tumbar una web más rápido que un plugin abandonado desde 2017.

Medidas prácticas:

• Añade honeypots invisibles para humanos.
• Limita frecuencia de envío por IP.
• Valida campos en cliente y servidor.
• No proceses formularios pesados sin nonce.
• Evita búsquedas internas infinitas indexables.
• Registra envíos sospechosos antes de borrarlos, al menos durante el diagnóstico.

Si estás automatizando procesos con herramientas externas, cuidado con abrir endpoints sin control. La automatización es fantástica, pero no debe ser una puerta trasera con documentación bonita. En este punto conecta bien la lectura sobre cómo aprovechar n8n sin convertir cada flujo en una ruleta rusa, especialmente si tu WordPress habla con CRMs, ERPs o sistemas de reservas.

Cache, CDN y servidor: los tres adultos de la sala

La seguridad también es rendimiento. Si cada visita obliga a WordPress a cargar PHP, consultar MySQL, ejecutar 40 plugins y montar una página desde cero, los bots lo tienen fácil. No necesitan hackearte; solo pedirte páginas hasta que te canses.

Un buen sistema de caché reduce muchísimo el impacto del tráfico automatizado. Un CDN absorbe parte del golpe. Y un servidor bien configurado marca la diferencia entre “hemos tenido un pico” y “la web se ha ido al suelo otra vez”.

Esto aplica especialmente a WooCommerce, donde no todo se puede cachear alegremente. Carrito, checkout, cuenta de usuario y sesiones necesitan trato fino. Si tienes tienda online, revisaría también cómo escalar una tienda WooCommerce sin romper el negocio, porque muchos problemas atribuidos a bots en realidad aparecen sobre una arquitectura ya al límite.

Plan de acción en 30 minutos, 24 horas y una semana

Cuando una web está bajo presión, no necesitas una auditoría de 80 páginas. Necesitas orden.

En los primeros 30 minutos

• Comprueba si la web está caída, lenta o solo muestra picos en analítica.
• Revisa logs de acceso y error.
• Identifica rutas más atacadas.
• Activa protección temporal en WAF o CDN.
• Limita acceso a /wp-login.php y /xmlrpc.php si procede.
• Haz backup antes de tocar configuraciones críticas.

En las siguientes 24 horas

• Actualiza WordPress, plugins y tema con cabeza, no en modo kamikaze.
• Revisa usuarios administradores.
• Activa 2FA.
• Instala o ajusta un plugin de seguridad si no hay WAF externo.
• Configura rate limits por endpoint.
• Comprueba formularios, comentarios y búsquedas internas.
• Verifica que Googlebot real no queda bloqueado.

Durante la semana siguiente

• Analiza patrones de tráfico con datos suficientes.
• Documenta reglas aplicadas y motivos.
• Revisa rendimiento real del servidor.
• Audita plugins innecesarios o abandonados.
• Automatiza alertas de picos anómalos.
• Prepara un protocolo interno para futuras incidencias.

Esto último parece aburrido, pero salva horas. En empresas pequeñas suele pasar que todo el conocimiento está en la cabeza de una persona. Hasta que esa persona está de viaje, enferma o simplemente no mira WhatsApp un domingo. Documentar no es burocracia; es evitar incendios repetidos.

Qué no haría salvo que tengas muy claro el impacto

Hay medidas que suenan contundentes pero pueden salir caras:

• Bloquear países enteros sin revisar si tienes clientes, proveedores o crawlers legítimos allí.
• Poner CAPTCHA global en toda la web.
• Desactivar REST API sin saber qué plugins dependen de ella.
• Bloquear todos los bots por user agent sin verificar IPs.
• Instalar cinco plugins de seguridad que se pisan entre ellos.
• Cambiar reglas del servidor sin copia de configuración previa.

La seguridad en WordPress no va de acumular candados. Va de entender superficie de ataque, impacto de negocio y mantenimiento. Una web corporativa sencilla no necesita lo mismo que un WooCommerce internacional ni que una plataforma con usuarios registrados, reservas o integraciones con ERP.

Aprendizaje práctico: los bots revelan tus puntos débiles

Esta es la parte incómoda: muchas veces los bots no crean el problema, solo lo enseñan. Una web lenta, sin caché, con plugins obsoletos, formularios blandos y hosting justo va a sufrir antes. Los bots simplemente hacen de auditoría salvaje, sin pedir permiso y sin entregar informe bonito en PDF.

Por eso conviene tratar el incidente como una oportunidad técnica. No en plan frase de taza motivacional, sino con pragmatismo: si un pico de tráfico automatizado tumba tu negocio, tienes una dependencia frágil. Y eso se arregla con arquitectura, mantenimiento, monitorización y decisiones menos improvisadas.

En muchos casos el trabajo real no es instalar un plugin. Es limpiar. Quitar lo que sobra. Actualizar lo que da miedo tocar. Mover reglas al servidor. Revisar formularios. Optimizar consultas. Separar lo crítico de lo decorativo. Lo de siempre, vamos: ingeniería poco glamourosa pero rentable.

Conclusión: no luches contra bots con superstición

Cuando los bots golpean tu WordPress, la diferencia entre una anécdota y una caída seria está en tener método. Mirar logs, identificar patrones, proteger rutas sensibles, limitar abusos, cachear bien, usar WAF con criterio y documentar lo aprendido.

WordPress no es inseguro por defecto, pero tampoco se defiende solo. Es una herramienta potente, abierta y muy popular. Y lo popular atrae de todo: clientes, oportunidades, integraciones útiles y también bots con demasiado tiempo libre.

Mi consejo es simple: no esperes al ataque para pensar en seguridad. Porque cuando el servidor está ardiendo, el cliente llama, el formulario no carga y el panel tarda veinte segundos en abrir, ya no estás diseñando una estrategia. Estás apagando fuego con una cucharilla.