Cloudflare + WordPress: protección paso a paso 2026

En pocas palabras: Activá SSL en modo Full Strict, bloqueá xmlrpc.php con una regla de firewall y habilitá el WAF de WordPress: esos 3 pasos, en menos de una hora, eliminan los vectores de ataque más explotados. El plan gratuito cubre lo esencial; el Pro ($20/mes) suma APO y reglas sin límite.

Con Cloudflare correctamente configurado, tu WordPress queda protegido contra ataques DDoS, intentos de fuerza bruta y exploits conocidos antes de que lleguen al servidor. El plan gratuito incluye SSL, CDN global y WAF básico; el Pro ($20/mes) suma APO y reglas avanzadas. Configurarlo lleva menos de una hora.

¿Qué es Cloudflare y por qué tu sitio WordPress lo necesita?

Cloudflare es una red de distribución de contenido (CDN) y proxy inverso con presencia en más de 300 ciudades del mundo. Cuando activás Cloudflare en tu dominio, todo el tráfico pasa primero por sus servidores: lo que es legítimo llega a tu WordPress, lo malicioso se descarta antes. La protección funciona así para DDoS, ataques de fuerza bruta, inyecciones SQL y exploits de plugins.

WordPress es el blanco favorito de los scanners automáticos, no porque sea especialmente inseguro sino porque representa más del 40% de la web y los bots lo saben de memoria. Cada instalación expone rutas predecibles: /wp-login.php, /xmlrpc.php, /wp-admin/. Sin algo que filtre delante del servidor, esos endpoints reciben cientos de peticiones por día de bots probando credenciales. La configuración de Cloudflare para WordPress que describimos acá apunta exactamente a ese problema.

Lo que no hace Cloudflare: no reemplaza a Wordfence ni a WPVivid. Es una capa de protección perimetral, no el único escudo.

Cómo agregar tu sitio WordPress a Cloudflare

Para integrar Cloudflare con WordPress necesitás crear una cuenta en cloudflare.com, agregar el dominio y luego cambiar los nameservers en tu registrador de dominios. El proceso en sí es rápido; la propagación de DNS es la parte que requiere paciencia. En nuestra guía sobre Sucuri y otras soluciones de firewall, profundizamos en esto.

• Crear la cuenta: Entrá a cloudflare.com y registrate. El plan Free no requiere tarjeta de crédito.
• Agregar el sitio: Hacé clic en «Add a site», escribí el dominio sin www y dejá que Cloudflare escanee los registros DNS existentes automáticamente.
• Elegir el plan: Para la mayoría de los blogs y sitios institucionales, el Free alcanza para empezar. Si necesitás APO o más de 5 reglas de firewall, el Pro a $20/mes es el salto lógico.
• Revisar registros DNS: Cloudflare importa los registros A, CNAME, MX y TXT automáticamente, pero revisalos uno por uno antes de continuar. Si tu proveedor tiene registros personalizados para correo transaccional o Google Workspace, puede no traerlos todos (sí, en serio, pasa más seguido de lo que pensás).
• Copiar los nameservers: Cloudflare te asigna dos nameservers propios, del estilo diana.ns.cloudflare.com. Anotálos.

Cambiar los nameservers: dónde y cómo hacerlo correctamente

El cambio de nameservers se hace en el panel de tu registrador de dominios, no en el hosting. Si registraste el dominio en donweb.com u otro registrador, buscá la sección «Nameservers» dentro de la gestión del dominio y reemplazá los actuales por los dos que te dio Cloudflare.

Un error clásico acá: cambiar el nameserver en el panel del hosting en vez del registrador. No es lo mismo. El hosting controla dónde vive el servidor; el registrador controla a quién le pregunta el mundo «¿dónde está ese dominio?». Si cambiás en el lugar equivocado, no pasa nada visible (todo sigue igual) y perdiste media hora.

La propagación tarda entre 24 y 48 horas, aunque en la práctica suele ser bastante más rápida. Podés verificar que el cambio funcionó usando herramientas como whatsmydns.net o con un simple nslookup tudominio.com 8.8.8.8. Cuando los nameservers de Cloudflare empiecen a responder, el dashboard de Cloudflare te lo confirma con una pantalla de bienvenida.

¿Qué modo SSL/TLS usar en Cloudflare con WordPress?

El modo SSL de Cloudflare controla cómo se cifra la conexión entre el navegador, los servidores de Cloudflare y tu servidor de origen. Para WordPress, el modo correcto es Full o Full (Strict). Usar Flexible es el error más frecuente y el que genera más dolores de cabeza.

• Flexible: cifra solo el tramo entre el navegador y Cloudflare. Entre Cloudflare y tu servidor, el tráfico va sin cifrar. WordPress detecta HTTP en ese segundo tramo, redirige a HTTPS, Cloudflare vuelve a conectar por HTTP y se arma el loop. Si ves ERR_TOO_MANY_REDIRECTS después de activar Cloudflare, el 90% de las veces es esto.
• Full: cifra ambos tramos. Cloudflare acepta el certificado del servidor sin validarlo, así que funciona incluso con certificados auto-firmados. Recomendado para la mayoría de los sitios.
• Full (Strict): igual que Full pero valida que el certificado del servidor sea emitido por una autoridad reconocida. Si tu hosting usa Let’s Encrypt (como hacen casi todos en 2026), este modo funciona perfectamente y es el más seguro de los tres.

Activá también «Always Use HTTPS» en la sección SSL/TLS de Cloudflare. Con eso, cualquier petición HTTP se redirige a HTTPS antes de llegar a tu servidor, sin tocar el .htaccess de WordPress.

WAF de Cloudflare para WordPress: qué reglas activar

El WAF (Web Application Firewall) de Cloudflare analiza cada request HTTP y lo compara con patrones de ataque conocidos antes de dejarlo pasar. Según la documentación oficial de Cloudflare, los conjuntos de reglas administradas incluyen el OWASP Core Ruleset (SQL injection, XSS, path traversal) y el ruleset específico de WordPress, disponible en planes Pro y Business.

Para activarlo: Security, WAF, Managed Rules. Los dos conjuntos principales que te interesan:

• Cloudflare Managed Ruleset: cubre ataques genéricos. El plan Free incluye cobertura básica; en Pro podés ajustar el nivel de paranoia y el umbral de anomalías.
• WordPress ruleset: reglas específicas para explotación de plugins vulnerables, ataques a xmlrpc.php e intentos de acceso al admin. Solo disponible en planes pagos.

¿Qué es el «anomaly threshold»? Cada request acumula un puntaje de amenaza según cuántas reglas activa. Si supera el umbral configurado, Cloudflare bloquea o presenta un CAPTCHA. Con configuración conservadora (umbral alto, paranoia baja) casi no hay falsos positivos. Con configuración agresiva podés bloquear solicitudes legítimas de plugins o de la API REST de WordPress. La recomendación práctica: empezá conservador, revisá el log del WAF durante una semana y ajustá.

Reglas de firewall personalizadas: los casos más importantes

Ponele que tu WordPress recibe miles de peticiones a xmlrpc.php por día. Ese endpoint es una reliquia de cuando WordPress no tenía API REST propia, y hoy casi nadie lo necesita, pero los bots lo usan para ataques de fuerza bruta amplificados donde una sola petición puede probar decenas de combinaciones de credenciales. La regla para bloquearlo es directa:

• Condición: (http.request.uri.path contains "/xmlrpc.php")
• Acción: Block

Ojo: si usás Jetpack, el plugin necesita acceso a xmlrpc.php para sincronizar con WordPress.com. En ese caso, la solución es agregar una excepción que permita el tráfico de las IPs de Automattic antes de aplicar el bloqueo. Sin esa excepción, Jetpack deja de funcionar (spoiler: no es un error agradable de debuggear a las 2am).

Otras reglas útiles para el plan Free (5 reglas en total, así que priorizá):

• Limitar /wp-login.php por país: si tu blog no tiene usuarios en regiones específicas, bloqueá el acceso al login desde esos orígenes. No es solución definitiva, pero reduce el ruido considerable.
• Proteger /wp-admin por IP: si siempre entrás al admin desde las mismas IPs, podés crear una regla que solo permita esas IPs en /wp-admin. Todo lo demás, challenge o block.
• Bloquear bots con User-Agent de scanners conocidos: sqlmap, nikto, masscan tienen firmas identificables. Bloquearlos en Cloudflare ahorra recursos del servidor.

Con el plan Pro y Business, las reglas son ilimitadas y además tenés rate limiting, que te permite, por ejemplo, desafiar con CAPTCHA a cualquier IP que haga más de 5 peticiones por minuto a /wp-login.php.

Cloudflare y la velocidad de WordPress: APO, caché y compatibilidad

La mejora de velocidad más significativa que Cloudflare ofrece a WordPress viene de APO (Automatic Platform Optimization). Según la documentación oficial de Cloudflare para WordPress, APO mejora el rendimiento de páginas estáticas hasta un 44% al cachear el HTML completo de las páginas en la red de Cloudflare, no solo los assets. El visitante recibe la página desde el nodo de Cloudflare más cercano sin que PHP de WordPress se ejecute en cada request.

Para que APO funcione correctamente necesitás instalar el plugin oficial de Cloudflare para WordPress. El plugin maneja la limpieza automática del caché cuando publicás o actualizás un post. Sin esto, los visitantes verían contenido desactualizado hasta que el caché expire.

Una advertencia que pocas guías mencionan: si ya usás un plugin de caché como WP Rocket o LiteSpeed Cache, revisá que no generen conflictos con Cloudflare. Dos capas de caché de HTML pueden causar inconsistencias o, en el peor caso, que usuarios logueados vean páginas cacheadas de otras sesiones. En general, dejá que Cloudflare maneje el caché de CDN y configurá el plugin de caché local solo para optimización de recursos internos. Más contexto en guía completa de 2FA en WordPress.

Comparativa de planes Cloudflare para WordPress

Para un blog o sitio institucional sin transacciones económicas, el Free cubre bastante. Si el sitio genera ingresos o maneja datos de usuarios, el Pro a $20/mes se justifica: el ruleset específico de WordPress en el WAF solo en el Pro ya vale lo que cuesta.

Errores comunes al configurar Cloudflare con WordPress

Error 521: el servidor no responde a Cloudflare

El 521 aparece cuando Cloudflare intenta conectarse a tu servidor de origen y la conexión es rechazada activamente. Las causas más frecuentes: el firewall del servidor tiene bloqueadas las IPs de Cloudflare, el puerto 80 o 443 está cerrado, o el servicio web no está corriendo. Cloudflare publica sus rangos de IP en cloudflare.com/ips; esas IPs deben estar en la lista blanca del firewall del servidor. Si usás un panel como cPanel o Plesk, hay opciones específicas para agregar IPs permitidas en el firewall de servidor.

Error 520: respuesta inesperada del servidor de origen

El 520 es el error «algo salió mal pero no sabemos exactamente qué». Lo genera cuando el servidor de origen devuelve una respuesta que Cloudflare no puede interpretar: un error PHP fatal, un timeout de PHP-FPM, o una respuesta HTTP malformada. Para diagnosticarlo, activá «Development Mode» en Cloudflare (bypasea el caché y conecta directo al servidor) y revisá los logs de error del servidor. El problema casi siempre está del lado del servidor, no de Cloudflare.

Too Many Redirects: el loop del SSL mal configurado

Activás Cloudflare, dejás el modo SSL en Flexible (que es el default), y el sitio larga ERR_TOO_MANY_REDIRECTS. Lo que pasa: Cloudflare manda HTTPS al navegador pero accede al servidor por HTTP, WordPress detecta HTTP y redirige a HTTPS, Cloudflare vuelve a acceder por HTTP, y el loop no para nunca. La solución es cambiar el modo SSL a Full o Full Strict en el panel de Cloudflare. Si el error persiste después del cambio, revisá que en el wp-config.php no haya código forzando HTTPS que interactúe raro con los headers X-Forwarded-Proto de Cloudflare.

El admin de WordPress se ve desactualizado o raro

Si Cloudflare cachea el panel de administración, podés ver contenido viejo o comportamientos raros al guardar cambios. La corrección: crear una Page Rule o una regla de caché con bypass para las rutas /wp-admin/* y /wp-login.php. El plugin oficial de Cloudflare para WordPress aplica estas exclusiones automáticamente si configurás el caché desde ahí. Siempre controlá con una ventana de incógnito si lo que ves en el admin es el contenido real o algo cacheado. Tema relacionado: mejores prácticas de seguridad WordPress.

Preguntas Frecuentes

¿El plan gratuito de Cloudflare es suficiente para proteger WordPress?

Para la mayoría de los blogs y sitios institucionales, sí. El plan Free incluye protección DDoS básica, SSL, CDN y 5 reglas de firewall personalizadas, lo que cubre los vectores de ataque más comunes. Para ecommerce o sitios que manejan datos sensibles de usuarios, el plan Pro ($20/mes) suma el WAF completo con el ruleset específico de WordPress, APO y rate limiting, lo que marca una diferencia concreta frente a ataques dirigidos.

¿Cómo agrego mi WordPress a Cloudflare paso a paso?

El proceso es: crear cuenta en cloudflare.com, agregar el dominio, revisar que los registros DNS se importaron correctamente, copiar los nameservers que te da Cloudflare y cambiarlos en tu registrador de dominios. Después de la propagación (hasta 48 horas), configurar SSL en modo Full, activar WAF y agregar como primera regla el bloqueo de xmlrpc.php. El plugin oficial de Cloudflare para WordPress simplifica la gestión del caché y aplica las exclusiones de /wp-admin automáticamente.

¿Por qué sigo viendo ataques si ya tengo Cloudflare activo?

Probablemente porque el atacante conoce la IP real de tu servidor y se conecta directamente, saltando Cloudflare. Para cerrarlo, configurá el firewall del servidor para aceptar conexiones entrantes solo desde los rangos de IP de Cloudflare. Si la IP del servidor estuvo expuesta antes de activar Cloudflare (por registros DNS públicos o logs de WHOIS), el atacante puede haberla guardado. Cambiar la IP del servidor después de activar Cloudflare cierra ese vector.

¿Cloudflare es compatible con WooCommerce?

Sí, pero las páginas de carrito, checkout y cuenta de usuario no deben estar cacheadas. Si Cloudflare cachea el checkout, los clientes pueden ver el carrito de otro usuario, que es una fuga de datos seria. Agregá reglas de bypass de caché para /cart/, /checkout/ y /my-account/. El plugin oficial de Cloudflare detecta WooCommerce y aplica esas exclusiones automáticamente si configurás el caché desde el plugin.

¿Cloudflare reemplaza a Wordfence o a otros plugins de seguridad?

No. Cloudflare opera a nivel de red, antes de que el tráfico llegue al servidor. Wordfence opera dentro de WordPress, con acceso al contexto de la aplicación (usuarios logueados, intentos de acceso a archivos del servidor, modificaciones de código). Son capas complementarias: Cloudflare filtra el grueso del tráfico malicioso antes de que golpee el servidor; Wordfence atrapa lo que pasa el filtro perimetral y agrega monitoreo de integridad de archivos. Usar los dos juntos es perfectamente válido y no generan conflictos si los configurás bien.

Conclusión

Configurar Cloudflare en WordPress no es magia, pero tiene sus trampas. El error más frecuente no es técnico sino de orden: activar Cloudflare en modo SSL Flexible antes de entender qué hace, o no verificar los registros DNS importados antes de cambiar los nameservers.

Si empezás hoy, el orden correcto es: agregar el dominio a Cloudflare, revisar DNS, cambiar nameservers, esperar propagación, configurar SSL en Full, activar WAF administrado y agregar la regla de bloqueo de xmlrpc.php. Con eso, en menos de una hora, tu WordPress tiene una capa de protección perimetral que la mayoría de los sitios nunca llega a tener. El plan Free alcanza para arrancar; si el sitio crece o empieza a recibir ataques más dirigidos, el salto a Pro a $20/mes trae el ruleset de WordPress en el WAF y reglas de firewall ilimitadas.

Dicho esto, Cloudflare es una capa más, no la solución completa. Backups regulares, plugins actualizados y un plugin de seguridad como Wordfence siguen siendo parte del stack de cualquier WordPress que valga la pena proteger.

Fuentes

• Cloudflare – Improving web security for WordPress (documentación oficial)
• Cloudflare – WAF Managed Rules Reference (documentación oficial)
• WP Beaches – Bloquear xmlrpc.php en Cloudflare con excepción para Jetpack
• AyudaWP – Ataques DDoS en WordPress: protección y mitigación
• Addmira – Seguridad WordPress con Cloudflare: guía práctica de protección