El spam en WordPress no ha muerto, ha mutado. Los bots modernos son más sofisticados que los de 2012, pero las técnicas para combatirlos también. El clásico truco del .htaccess sigue funcionando en servidores Apache, pero ya no es suficiente por sí solo. Necesitas una estrategia en capas: desde el servidor hasta el WAF, pasando por plugins especializados y servicios en la nube.
En este tutorial repasamos todas las opciones: las reglas .htaccess probadas (con el bloque de código listo para copiar), su equivalente en nginx, y las alternativas modernas más eficaces hoy.
Cada instalación de WordPress publica el mismo endpoint de comentarios (wp-comments-post.php), el mismo archivo de login (wp-login.php) y el mismo protocolo XML-RPC. Los bots los conocen de memoria y los atacan sin parar. El resultado: comentarios basura, registros de usuario falsos y peticiones a formularios de contacto que colapsan tu bandeja de entrada.
Tres frentes que hay que blindar de forma distinta:
wp-comments-post.php.El archivo .htaccess permite interceptar peticiones antes de que WordPress las procese. Eso lo convierte en la primera línea de defensa, porque el bot ni siquiera llega a ejecutar PHP. El coste de servidor es mínimo y el efecto, inmediato.
El truco clásico consistía en bloquear peticiones POST a wp-comments-post.php que no viniesen del propio dominio. Lo enriquecemos aquí con protección para XML-RPC, wp-login.php y user-agents vacíos:
# ── ANTI-SPAM .htaccess para WordPress ─────────────────────────────────
# Sustituye "tudominio.com" por tu dominio real
# 1. Bloquear bots que envían comentarios sin pasar por la web
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post.php$
RewriteCond %{HTTP_REFERER} !.*tudominio.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.*$ - [F,L]
</IfModule>
# 2. Bloquear acceso directo a XML-RPC (si no lo usas)
<Files xmlrpc.php>
Require all denied
</Files>
# 3. Limitar wp-login.php a tu IP (opcional, recomendado en producción)
# <Files wp-login.php>
# Require ip 203.0.113.0/24
# </Files>
# 4. Bloquear user-agents conocidos de spam bots
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|MJ12bot|DotBot|SemrushBot|spambot|harvester) [NC]
RewriteRule ^.*$ - [F,L]
</IfModule>
# 5. Bloquear referrer spam clásico
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} (semalt.com|buttons-for-website.com|darodar.com) [NC]
RewriteRule ^.*$ - [F,L]
</IfModule>
# ─────────────────────────────────────────────────────────────────────────Lenguaje del código: PHP (php)Importante: el bloque 1 usa [F,L] (Forbidden + Last) en lugar del antiguo R=301. El redirect 301 a la IP del bot era una técnica de 2012 que hoy puede causar loops en CDN. [F] devuelve un 403 limpio y es el estándar recomendado.
Si quieres profundizar en otras directivas .htaccess para tu WordPress, revisa la guía completa de .htaccess en WordPress: 15 trucos útiles y cabeceras de seguridad, donde cubrimos caché, redirecciones y cabeceras HTTP.
⚠️ Nginx no lee .htaccess. Si tu hosting usa nginx (LiteSpeed nativo, algunos planes de Cloudways, Kinsta, Flywheel…), estas reglas no tendrán ningún efecto. El equivalente va en el bloque server {} de tu nginx.conf o en el panel de configuración del hosting:
location = /wp-comments-post.php {
if ($http_referer !~ "tudominio.com") {
return 403;
}
if ($http_user_agent = "") {
return 403;
}
fastcgi_pass php_backend;
}
location = /xmlrpc.php {
deny all;
}
En LiteSpeed (cPanel), sí se leen los .htaccess a través de su capa de compatibilidad, así que el bloque anterior funciona igual.
El .htaccess bloquea bots primitivos. Los bots modernos simulan un navegador real, tienen JavaScript activo y envían el referer correcto. Para ellos necesitas plugins que analicen el contenido de la petición, no solo sus cabeceras.
Un WAF (Web Application Firewall) analiza el tráfico antes de que llegue a tu servidor. Es la defensa más robusta porque elimina el problema de raíz.
Wordfence incluye un WAF a nivel de aplicación que se activa dentro de PHP. No tan potente como uno a nivel de red, pero suficiente para la mayoría de sitios. Bloquea IPs con comportamiento de bot, peticiones malformadas y payloads de inyección. La versión gratuita recibe las reglas con 30 días de retraso respecto a la premium.
Si pones tu sitio detrás de Cloudflare (el plan gratuito funciona), tienes acceso a Bot Fight Mode que bloquea bots conocidos sin tocar tu configuración de WordPress. El plan Pro añade reglas WAF más granulares. El plan Enterprise incluye Bot Management completo con detección de bots sofisticados.
Para spam en formularios, Cloudflare Turnstile (mencionado arriba) se puede desplegar sin cambiar de plan: es gratuito y funciona con cualquier hosting.
La seguridad del código que instalas también cuenta: mantener los plugins actualizados reduce la superficie de ataque. Puedes ver cómo WP Beacon vigila la cadena de suministro de plugins de WordPress para detectar dependencias comprometidas antes de que sean un problema.
No existe una bala de plata. La defensa efectiva combina:
| Capa | Herramienta | Qué bloquea | Coste |
|---|---|---|---|
| Servidor | .htaccess / nginx | Bots sin referer, XML-RPC | Gratis |
| Red | Cloudflare (Bot Fight) | Bots conocidos, DDoS | Gratis / Pro |
| Aplicación | Akismet o Antispam Bee | Comentarios spam | Gratis (personal) |
| Formularios | Cloudflare Turnstile / hCaptcha | Envíos automáticos | Gratis |
| WAF completo | Wordfence Premium | Ataques de todo tipo | ~119$/año |
Para sitios pequeños: .htaccess + Cloudflare gratuito + Akismet o Antispam Bee cubre el 90% de los casos sin coste adicional. Para sitios medianos o con presión alta: añade Wordfence Premium o CleanTalk y Cloudflare Turnstile en formularios.
Y si el spam empieza a impactar en la velocidad de carga (muchas peticiones bloqueadas consumen recursos), revísa también la guía de rendimiento de WordPress: la caché bien configurada reduce la carga que llega a PHP incluso cuando hay tráfico de bots.
No, si está bien configurado. Las reglas bloquean peticiones POST sin referer correcto o con user-agent vacío. Los usuarios reales siempre tienen referer (vienen de alguna página de tu sitio) y user-agent (su navegador). Googlebot y otros crawlers legítimos tampoco envían comentarios, así que no se ven afectados.
Depende. XML-RPC lo usan aplicaciones móviles de WordPress, Jetpack, y algunos servicios de publicación remota. Si no usas ninguno de estos, bloquearlo con <Files xmlrpc.php> Require all denied </Files> es lo más seguro. Si usas Jetpack, no lo bloquees del todo: configura Cloudflare para bloquear solo las peticiones con más de X intentos por minuto.
Sí. Akismet lleva desde 2005 aprendiendo de millones de sitios WordPress. Su base de datos de spam es enorme y la tasa de falsos positivos es muy baja. El único punto débil: para spam muy específico de nicho (comentarios en idiomas poco comunes, spam de nicho de foro privado) puede escaparse alguno. Complementar con Antispam Bee en esos casos ayuda.
Son alternativas con enfoque diferente. Turnstile es completamente invisible para el usuario (mejor UX, especialmente en móvil) y gratuito sin límite de peticiones. hCaptcha puede mostrar un desafío visual cuando detecta algo sospechoso, lo que da una capa extra. Para la mayoría de sitios, Turnstile es suficiente y más cómodo para el usuario. Usa hCaptcha si tu hosting ya tiene integración nativa o si necesitas más control sobre los desafíos.
Primero activa la verificación de email en WooCommerce > Ajustes > Cuentas y privacidad. Luego añade Turnstile o hCaptcha al formulario de registro. Si el problema persiste, Stop Spammers Security permite bloquear dominios de email temporales (como mailinator.com o guerrillamail.com) que son los que usan los bots para registros masivos.
