Checklist de Cloudflare para WordPress de alto tráfico
Un checklist práctico de Cloudflare para proteger, acelerar y operar portales WordPress con más previsibilidad en alto tráfico.
WordPress de alto tráfico no puede depender solo de un plugin de cache.
Un plugin ayuda, pero está dentro de la aplicación. Cuando el tráfico sube, la mejor defensa es hacer que menos requests lleguen a PHP, a la base de datos y al servidor de origen. Ahí Cloudflare deja de ser solo “DNS con CDN” y se convierte en una capa operativa importante.
Este checklist es lo que usaría como punto de partida para un portal WordPress que necesita seguir en línea con previsibilidad: cache bien definido, origen protegido, wp-admin menos expuesto y reglas lo suficientemente simples como para mantenerse.
La mentalidad correcta
Antes de configurar cualquier botón, hay que separar tres cosas:
- Qué puede cachearse en el borde.
- Qué necesita llegar a WordPress.
- Qué debería bloquearse antes de llegar al servidor.
Esa separación cambia el juego.
Página pública de noticia, artículo, categoría y etiqueta generalmente puede recibir cache agresivo, siempre que exista estrategia de purga. Área logueada, carrito, checkout, preview, comentarios administrativos y wp-admin necesitan bypass. Tráfico malicioso, scans e intentos repetidos de login deben filtrarse antes de consumir recursos del origen.
El objetivo no es esconder un WordPress frágil detrás de Cloudflare. El objetivo es reducir superficie, carga y variabilidad.
DNS, SSL y origen
Lo básico debe estar correcto antes del cache.
Checklist inicial:
- usar proxy activo en los registros públicos del sitio;
- mantener SSL en modo adecuado, preferentemente de punta a punta;
- garantizar certificado válido también en el origen;
- eliminar exposición innecesaria de la IP real del servidor;
- revisar registros DNS antiguos;
- separar subdominios administrativos cuando tenga sentido;
- mantener redirects centralizados y previsibles.
Un error común es configurar Cloudflare al frente, pero dejar el servidor aceptando tráfico directo por la IP. En ese escenario, parte de la protección puede ser eludida. Cuando sea posible, el origen debe aceptar requests solo de la capa esperada o de redes confiables.
También vale revisar headers, compresión, HTTP/2 o HTTP/3 y reglas de redirección. El rendimiento no nace solo en el cache. Empieza en el camino entre usuario, borde y origen.
Cache sin romper login
Cache en WordPress exige cuidado porque no toda página es igual.
Para contenido público, el borde puede aliviar mucho el servidor. Para contenido personalizado, un cache mal configurado puede filtrar estado, mostrar una barra administrativa indebida o entregar una página desactualizada a quien no debería verla.
Un diseño conservador:
- cachear posts, páginas, categorías y etiquetas públicas;
- ignorar query strings innecesarias cuando sea seguro hacerlo;
- bypass para
wp-admin,wp-login.php, previews y endpoints sensibles; - bypass cuando existan cookies de usuario logueado;
- definir TTL de borde según la frecuencia editorial;
- mantener purga por URL o por grupo cada vez que un post se actualice;
- probar comportamiento en ventana anónima y con usuario logueado.
El punto más importante: un buen cache debe ser previsible.
Si el equipo editorial publica muchas actualizaciones durante el día, el plan de cache debe conversar con esa rutina. No sirve tener cache agresivo si la operación necesita limpiar todo manualmente a cada cambio.
WAF, bots y wp-admin
WordPress es un objetivo constante porque es popular. Eso no significa que sea inviable. Significa que la superficie debe tratarse con seriedad.
Yo empezaría con reglas para:
- desafiar o bloquear intentos abusivos contra
wp-login.php; - proteger
/wp-admin/por país, IP, Access o regla específica cuando sea posible; - bloquear métodos HTTP que el sitio no usa;
- crear rate limit para endpoints sensibles;
- monitorear XML-RPC y desactivarlo cuando no sea necesario;
- bloquear patrones obvios de explotación;
- revisar bots que consumen muchos recursos sin aportar valor.
Aquí vale una observación pragmática: demasiadas reglas también son un riesgo.
Una configuración difícil de entender tiende a ser abandonada. Es mejor empezar con pocas reglas claras, medir impacto y evolucionar con base en logs. Una buena seguridad reduce riesgo sin transformar cada publicación en miedo de romper el sitio.
Operación y monitoreo
Cloudflare no es una configuración de una sola vez. Es parte de la operación.
Después de la configuración inicial, yo acompañaría:
- tasa de cache hit;
- páginas más accedidas;
- tráfico bloqueado por el WAF;
- origen recibiendo picos inesperados;
- errores 5xx;
- tiempo de respuesta del origen;
- reglas accionadas con frecuencia;
- URLs que deberían estar cacheadas, pero no lo están.
También mantendría un pequeño runbook:
- Cómo activar modo de desarrollo.
- Cómo purgar una URL.
- Cómo purgar un grupo de páginas.
- Cómo desactivar una regla problemática.
- Cómo identificar si el error viene del origen o del borde.
En alto tráfico, improvisar cuesta caro. El equipo necesita saber qué hacer antes de la crisis.
El mejor uso de Cloudflare en WordPress no es apilar recursos. Es diseñar un borde inteligente: cachear lo que es público, proteger lo que es sensible y dejar que el origen trabaje solo cuando realmente necesita trabajar.