La mayoría de webs en WordPress que están detrás de Cloudflare suelen estar mal configurados. No es que falte información, sino que hay demasiada. El panel de Cloudflare tiene alrededor de cien opciones, y casi todas vienen con una explicación que te anima a activarlas. Algunas realmente mejoran el rendimiento, mientras que otras pueden arruinarlo sin que te des cuenta.
Esta guía es un resumen de lo que activamos en los WordPress que gestionamos y, sobre todo, lo que decidimos dejar sin cambios y por qué. Aborda lo básico (SSL y DNS), el núcleo del rendimiento (caché), los ajustes en la pestaña de Velocidad y la parte de seguridad. Asume que ya tienes tu dominio apuntando a Cloudflare y que la nube naranja está activa. Si aún no lo has hecho, los pasos están en la documentación oficial y no vale la pena reescribirlos aquí.
Antes de continuar, un aviso importante. En el panel principal (Información general) hay dos botones que casi nadie debería tocar. El modo «Under Attack» lanza un desafío agresivo a cada visitante y arruina la experiencia normal del sitio. El modo «Desarrollo» salta el caché durante tres horas. Ambos tienen su utilidad en situaciones específicas, como un ataque DDoS o durante una sesión de edición web, pero en condiciones normales deben estar desactivadas. Si has instalado el plugin oficial de Cloudflare en WordPress, evita pulsar «Apply Recommended Cloudflare Settings for WordPress». La configuración que aplica es demasiado conservadora en algunos aspectos y demasiado agresiva en otros.
Configuración de Cloudflare SSL/TLS
El modo SSL que Cloudflare usa por defecto en muchas cuentas es Flexible, pero te aconsejo que no lo uses nunca. Cifra la conexión entre el visitante y Cloudflare, pero entre Cloudflare y tu servidor el tráfico viaja en HTTP plano. El candado verde aparece, pero suspenderías cualquier auditoría de seguridad seria.
Lo correcto es Full (strict). Cifra los dos tramos y exige que el certificado del origen sea válido. (La opción Full a secas acepta certificados autofirmados sin verificar, dejando la puerta abierta a ataques man-in-the-middle).
Para que Full (strict) funcione, necesitas un certificado en tu servidor:
- Usa el certificado de Let’s Encrypt que ya tengas instalado.
- O bien, puedes generar un Origin Certificate desde SSL/TLS → Origin Server → Create Certificate. Es gratuito, tiene una duración de hasta 15 años y lo puedes instalar directamente en tu panel (Plesk, cPanel, etc.).
Una vez en Full (strict), activa Always Use HTTPS y Automatic HTTPS Rewrites. El primero redirige cualquier HTTP a HTTPS antes de llegar a tu servidor (más rápido que un redirect en WordPress). El segundo reescribe enlaces internos servidos en HTTP para que vayan por HTTPS, lo cual cubre la suciedad histórica de muchos sitios migrados. Activa también TLS 1.3 y Opportunistic Encryption en Edge Certificates. Estas opciones mejoran tanto el rendimiento como la seguridad.
Configuración de DNS de Cloudflare
En la pestaña DNS, cada registro A o CNAME tiene una nubecita. Naranja significa que el tráfico pasa por el proxy de Cloudflare (caché, WAF, optimizaciones). Gris significa que Cloudflare resuelve el DNS y nada más. La regla es simple. El tráfico web va por naranja. El resto, casi nunca.
Lo que no debe pasar por la nube naranja, normalmente.
- Registros MX y los A asociados a mail.tudominio.com. Cloudflare no proxea correo; si los pones en naranja, dejarás de recibir emails.
- Subdominios de paneles (cpanel.tudominio.com o plesk.tudominio.com). El proxy puede causar bucles de redirección o problemas de puertos.
- Registros para FTP y SFTP (no son tráfico HTTP).
- Subdominios de validación de servicios externos (Google Workspace, CRMs).
- Registros TXT (SPF, DKIM, DMARC) no tienen opción de proxy, pero no está de más recordarlo.
Lo que sí pasa por naranja:
- El registro raíz (
@) ywww. - Cualquier subdominio donde sirvas contenido web que quieras acelerar.
Configuración de seguridad de Cloudflare
En la sección de Seguridad, puedes ajustar el nivel de protección general de tu zona. Para un sitio web de WordPress, la seguridad que ofrece Cloudflare es especialmente valiosa, ya que ayuda a reducir el tráfico no deseado, filtra solicitudes sospechosas y protege áreas críticas como el acceso de inicio de sesión.
Bot Fight Mode
Off en la mayoría de sitios. Bot Fight Mode es la opción más extendida del panel de seguridad y la que más se activa por reflejo. Inyecta JavaScript en cada página que intenta detectar bots por comportamiento. Hemos visto el script de Bot Fight añadir entre 1.500 y 2.500 ms de CPU execution time en móviles modestos y bajar la nota de PageSpeed Insights veinte puntos.
Si tienes un problema real de bots (scrapers agresivos, ataques L7), hay opciones mejores. Reglas WAF custom, rate limiting o, si es serio, Super Bot Fight Mode en plan Pro con configuración fina.
La opción para bloquear bots de IA (AI Scrapers) sí merece consideración aparte. No inyecta JavaScript, simplemente bloquea peticiones por User-Agent. Es decisión de marca y SEO, no de rendimiento. Si no quieres que tu contenido alimente modelos de lenguaje, on. Si te interesa aparecer en respuestas de ChatGPT, Perplexity y similares, off.
Reglas WAF custom para WordPress
El plan gratuito de Cloudflare incluye cinco reglas WAF custom. Bien usadas, son más útiles que cualquier toggle automático. Estas son las que aplicamos en casi todos los WordPress que mantenemos.
- Bloquear /xmlrpc.php: Vector típico de fuerza bruta. Acción: Block.
(http.request.uri.path eq «/xmlrpc.php») - Bloquear enumeración de autores: Evita que descubran tus usuarios. Acción: Block.
(http.request.uri.query contains «author=») - Bloquear REST API para no autenticados: El equivalente moderno al punto anterior. Acción: Block.
(http.request.uri.path contains «/wp-json/wp/v2/users») - Rate Limiting en /wp-login.php: El plan gratuito te permite configurar una regla de Rate Limiting sin coste por volumen. Limita a 10 intentos en 5 minutos por IP. Acción: Managed Challenge o Block.
- Bloqueo por País (Geofencing): Si operas solo en un país o región, lanza un challenge al tráfico del resto del mundo. Reduce el ruido drásticamente.
Lo que dejamos quieto
Replace insecure JavaScript libraries. On. Cloudflare detecta librerías vulnerables conocidas (versiones viejas de jQuery con XSS, por ejemplo) y las sustituye en vuelo por versiones parcheadas. Es gratis, no penaliza rendimiento y cubre un vector real.
DDoS Protection. Siempre on, no hay opción de desactivarlo en plan gratuito y tampoco la querrías.
Configuración de velocidad de Cloudflare
La pestaña Speed → Optimization es donde Cloudflare guarda sus features de aceleración. Algunas son una mejora gratis. Otras añaden problemas que tardarás semanas en localizar.
Lo que sí activamos
- HTTP/3 con QUIC. Mejor protocolo de transporte, especialmente en redes móviles con latencia alta. Sin contrapartidas. On.
- HTTP/2 to Origin. Si tu servidor soporta HTTP/2 (la mayoría sí), Cloudflare lo usa para hablar con él. Reduce overhead de conexión. On.
- 0-RTT Connection Resumption. Permite que visitantes recurrentes salten el handshake TLS completo. Mejora visible en navegación entre páginas. On.
- Early Hints. Envía cabeceras de preload y preconnect como respuestas 103 antes de que el HTML llegue. El navegador puede empezar a pedir recursos críticos antes. La pega, en WordPress no funciona out of the box porque la mayoría de themes y plugins meten los preloads como elementos
<link>en el HTML, no como cabeceras HTTP. Hay plugins (Perfmatters, entre otros) que convierten esos<link>en cabeceras y entonces Early Hints sí tiene efecto. Si no tienes plugin que lo soporte, lo dejas activado igualmente, no hace daño, pero el beneficio es marginal.
Lo que desactivamos (y por qué):
- Speed Brain: OFF. Hace prefetch agresivo en segundo plano. En WordPress causa errores al guardar posts, conflictos de caché y problemas con
admin-ajax. El beneficio público no compensa los fallos en el backend. - Rocket Loader: OFF. Sin debate. Rocket Loader añade un JavaScript que reordena la carga de scripts del sitio. En teoría reduce el tiempo de bloqueo inicial. En la práctica rompe themes que dependen de orden específico de carga (casi todos), añade un archivo
rocket-loader.min.jsque aparece marcado en PageSpeed como render-blocking y de larga ejecución en el main thread, y empeora más de lo que mejora. No lo usamos en ningún sitio. - Auto Minify: OFF. Cloudflare deprecó esta opción en 2024 pero todavía aparece en algunos paneles antiguos. Tu plugin de caché ya minifica HTML, CSS y JS mucho mejor que Cloudflare, con control sobre exclusiones (jQuery, scripts críticos) y compatibilidad con tu theme. Dejar que dos sistemas minifiquen el mismo recurso es pedir problemas.
- Cloudflare Fonts: OFF. Off si self-hosteas fuentes (cosa que deberías hacer). Cloudflare Fonts intercepta llamadas a Google Fonts y las sirve desde su CDN. Suena bien hasta que recuerdas que ya no es 2018, que cargar fuentes desde un CDN externo tiene cero ventaja de rendimiento real frente a hostearlas en tu propio dominio, y que self-hostear elimina la conexión a un tercero (mejor en privacidad y en una preconnect menos). Si tus fuentes ya están en tu servidor, esta opción no aporta y mete una intermediación más en el flujo.
- Web Analytics. Off, salvo que sea tu única analítica. Inyecta
beacon.min.jsy, si ya tienes GA4, Fathom, Plausible o cualquier otra solución, estás cargando dos beacons sin razón. La privacidad que aporta es real, pero si tu stack ya cubre analítica, este script sobra.
Configuración de almacenamiento en caché de Cloudflare
Cuando una guía dice que Cloudflare acelera tu web, lo que está diciendo en realidad es que cachea contenido en el borde y se lo sirve al visitante sin que el origen intervenga. Sin un buen caché, Cloudflare es poco más que un DNS rápido con WAF. Con un buen caché, una web normal en un VPS modesto entrega TTFB por debajo de 100 ms en cualquier parte del mundo.
Browser Cache TTL y nivel de caché
En Caching → Configuration, pon Browser Cache TTL a un mes como mínimo. Idealmente un año. Esta opción controla durante cuánto tiempo el navegador del visitante guarda los recursos estáticos antes de volver a pedirlos. Cuanto más largo, mejor cache hit ratio y menos peticiones al origen. PageSpeed Insights deja de quejarse del aviso «Serve static assets with an efficient cache policy» cuando esto está por encima de treinta días.
Caching Level: Standard. La opción Aggressive ignora query strings y puede servir versiones cacheadas viejas si tu plugin de caché añade parámetros para invalidar. Standard se comporta como esperarías.
Cache Everything. Cachear el HTML, no solo los assets
Por defecto, Cloudflare cachea recursos estáticos (CSS, JS, imágenes, fuentes) pero no HTML. Eso significa que cada visita a una página de tu WordPress sigue golpeando al origen para generar la respuesta. Si quieres aprovechar Cloudflare de verdad, hay que cachear también el HTML.
Hay tres formas de hacerlo:
La primera, una Page Rule (o Cache Rule, en el nuevo dashboard) que aplique Cache Everything a las URLs de tu sitio. Algo como *tudominio.com/* con Cache Level: Cache Everything y Edge Cache TTL: 2 horas (o el tiempo que tenga sentido para tu frecuencia de publicación). Es la opción manual y la más flexible.
La segunda, el plugin gratuito Super Page Cache for Cloudflare. Gestiona la lógica de Cache Everything desde dentro de WordPress, incluyendo la purga automática al guardar un post, una página o un comentario aprobado. Es la opción más práctica para sitios que publican a menudo.
La tercera, APO (Automatic Platform Optimization), de la que hablamos enseguida.
APO. Cinco euros al mes que casi siempre valen la pena
APO (Automatic Platform Optimization) es la opción de Cloudflare para WordPress que cachea el HTML completo del sitio en el KV de Workers y lo sirve desde el borde sin pasar por el origen. Cuesta 5 € al mes por dominio, funciona sobre el plan gratuito y requiere el plugin oficial de Cloudflare instalado en WordPress.
¿Vale la pena? Para la mayoría de sitios, sí. Reduce TTFB a 50-100 ms desde cualquier parte del mundo, elimina la necesidad de configurar Page Rules manuales y se invalida en menos de treinta segundos cuando publicas. Para un sitio sin caché de plugin sólido o sin Super Page Cache, la mejora es brutal.
Hay un matiz. Si ya tienes FlyingPress, WP Rocket o LiteSpeed Cache afinados, con HTML cacheado a disco y headers de caché bien puestos, APO se solapa parcialmente y la mejora marginal es menor. En algunos casos puede aparecer doble caché, donde la invalidación del plugin no llega al borde de Cloudflare de forma instantánea. No es un drama, pero hay que verificar que el flujo de publicación deja todo coherente.
Tiered Cache y otros ajustes
En Caching → Tiered Cache, activa Smart Tiered Caching Topology. Es gratis, reduce la carga al origen al designar un data center «de nivel superior» que pide al origen y replica al resto. Útil siempre.
Crawler Hints, on. Notifica a buscadores via IndexNow cuando hay contenido nuevo. Bing, Yandex y DuckDuckGo lo usan. Google todavía no, pero no hace daño.
Always Online, off. Periódicamente crawlea tu sitio y guarda copias en Wayback Machine para servir si tu origen se cae. Suena bien hasta que piensas que añade peticiones de un bot al servidor constantemente y que la web cacheada en Wayback no funciona si tu sitio tiene cualquier interacción dinámica (comentarios, carritos, formularios). Mejor desactivado.
Cache Reserve, opcional. Cuesta dinero (poco) y solo cachea recursos con Content-Length (básicamente imágenes). Para sitios con mucha media y mucho tráfico, mejora el hit ratio. Para el resto, ignorar.
Preguntas frecuentes
¿Sirve el plan gratuito o necesito Pro?
Para el 95% de webs en WordPress, el plan gratuito es suficiente. Incluye CDN, WAF básico, certificado SSL, HTTP/3, cinco reglas custom, rate limiting limitado, Tiered Cache, todos los protocolos modernos y la opción de añadir APO por 5 € adicionales. Pro (25 €/mes) tiene sentido si necesitas más reglas, Image Resizing (Polish), Mobile Redirect, lookup de bots mejorado o WAF gestionado avanzado. Para una web corporativa o un ecommerce pequeño, gratuito + APO cubre todo.
¿Qué pasa si Cloudflare se cae?
Cae tu web, en el escenario peor. Históricamente Cloudflare ha tenido outages globales puntuales (el último relevante fue en 2024). En esos momentos, si todo tu tráfico pasa por su proxy, tu sitio es inaccesible aunque el origen esté perfecto. No hay forma de evitarlo del todo, pero hay mitigaciones. Tener acceso al panel para poner las nubes en gris rápidamente si la caída se alarga (esto bypassea el proxy y deja DNS directo). Mantener un plan B de DNS que puedas activar (algunas empresas usan dos proveedores DNS). Para la mayoría de webs no es razonable más mitigación que esa. Cloudflare tiene una disponibilidad altísima y, cuando cae, cae internet entero, no solo tú.
¿Cloudflare reemplaza a mi plugin de caché de WordPress?
No del todo. Cloudflare cachea HTML en el borde y eso se solapa con la caché de página de tu plugin. Pero los plugins de caché serios hacen más cosas. Minificación con exclusiones, defer y delay de JavaScript, lazy loading inteligente, optimización de imágenes, eliminación de CSS no usado, preload de fuentes, optimización de Core Web Vitals específicas. Cloudflare es el caché de borde, tu plugin es el optimizador de aplicación. Conviven bien si configuras quién manda en cada cosa. Si tu único objetivo es tener una web razonablemente rápida y poco más, APO solo puede ser suficiente. Si quieres exprimir Core Web Vitals, plugin de caché + Cloudflare juntos.
¿Por qué mis formularios fallan desde que activé Cloudflare?
Tres causas típicas. Bot Fight Mode bloqueando submissions legítimos, Security Level en High lanzando challenges en formularios, o reglas WAF demasiado estrictas. Diagnóstico rápido. Mira Security → Events en el panel de Cloudflare, filtra por las últimas horas, busca eventos blocked o challenged en URLs de tu formulario. Casi siempre el culpable aparece ahí. Solución habitual. Bot Fight off, Security Level a Low o Medium, y si una Cache Rule está bloqueando POST, crear una excepción.
¿Es seguro activar Cache Everything si tengo WooCommerce?
Sí, siempre que configures Bypass on Cookie con las cookies de WooCommerce (woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*). Sin esa exclusión, los visitantes pueden ver el carrito de otra persona o intentar pagar productos que ya no están en su carrito. Con la exclusión bien hecha, la home, las páginas de catálogo y las fichas de producto se cachean para visitantes anónimos (que es el 95% de tu tráfico) y cualquier interacción de carrito o checkout se va al origen.
¿APO sigue siendo el feature más impactante en 2026?
Para sitios sin caché de página bien configurada, sí, con diferencia. Reduce TTFB a 50-100 ms desde cualquier parte del mundo y elimina la mayor parte de la complejidad de Page Rules manuales. Para sitios con un plugin de caché afinado más Cache Everything bien configurado, el delta es menor. La diferencia entre activar APO en un sitio recién montado y en un sitio con FlyingPress o WP Rocket bien afinado puede ser de 100 ms a 30 ms, mejora pero no espectacular. Recomendación. Si vas a configurar Cloudflare desde cero y no quieres complicarte, APO. Si ya tienes una configuración madura, evalúalo en staging y mide antes de pagar la cuota.
Cómo ponerlo en práctica
Si vas a aplicar todo esto en una web en producción, hazlo en este orden. SSL/TLS a Full (strict) con el certificado del origen verificado antes de tocar nada más. Revisión de DNS, registros que no deben pasar por proxy en gris. IP real del visitante con mu-plugin o configuración a nivel servidor. Caché en este orden, Browser TTL, Cache Rule de Cache Everything con Bypass on Cookie, integración del plugin de caché de WordPress para purga automática. Speed, los toggles que activamos y los que apagamos. Seguridad, Bot Fight off, Security Level a Low o Medium, las cinco reglas WAF.
Si tu sitio está en mal estado y prefieres no aprender esto a las malas con un cliente delante, una auditoría técnica te dice qué está mal configurado, qué se puede ganar y qué te está costando rendimiento ahora mismo.
