El verdadero problema del WordPress autogestionado
Un sitio WordPress en producción nunca es solo WordPress. Necesita una base de datos, un object cache, un page caché, un pipeline de imágenes, certificados TLS, DNS y un firewall — y en un hosting compartido cada uno de esos es un plugin, un add-on de pago, o un servicio que ensamblas tu mismo. Los desajustes de versión entre el runtime de PHP, el servidor MySQL, y un plugin de caché son una fuente constante de pantallas blancas. cdn.com.tr reemplaza ese parche con un solo stack administrado donde el runtime, la base de datos, Redis y el edge ya son compatibles y están aprovisionados juntos.
Redis object cache que realmente reduce la carga de la base de datos
La mayor parte de la lentitud de WordPress bajo carga son queries de base de datos repetidas e idénticas para opciones, menús y metadatos de posts. El add-on de Redis administrado se conecta como un drop-in de object cache de WordPress, así que esas queries se responden desde memoria en lugar de MySQL. Para sitios de WooCommerce y membresía donde las páginas son personalizadas y no se pueden cachear por completo, esto es lo que mantiene rápidas las páginas de carrito y cuenta. Como Redis es administrado, las credenciales se inyectan en el runtime y se rotan por ti en lugar de quedar en una pantalla de configuración de plugin.
caché edge de CDN y optimización de imágenes integrados
Los assets estáticos y el HTML cacheable se sirven desde el edge de cdn.com.tr cerca del visitante, recortando los recorridos de ida y vuelta al origin y absorbiendo picos de tráfico durante campañas. La optimización de imágenes recodifica las subidas a formatos modernos y sirve variantes del tamaño apropiado, lo cual elimina la necesidad de un plugin de optimización pesado que compite con tu sitio por workers de PHP. Las reglas de caché entienden las cookies de login de WordPress y de carrito de WooCommerce, así que los usuarios con sesión iniciada y los compradores evitan correctamente el caché compartido mientras los visitantes anonimos reciben páginas cacheadas.
Auto SSL, DNS y WAF delante de wp-admin
Las URLs más atacadas de cualquier instalación de WordPress son wp-login.php y xmlrpc.php. Como el tráfico llega al edge de cdn.com.tr antes que al origin, el WAF filtra patrones de fuerza bruta y explotación comunes antes de que toquen PHP siquiera. Auto SSL mantiene el HTTPS valido tanto en el apex como en el www sin cron jobs ni certbot, y el DNS se administra en el mismo panel para que un cambio de dominio no requiera hacer malabares con tres dashboards.
Migrar un sitio existente sin reconstruirlo
No tienes que reconstruir el sitio para moverlo. Trae los archivos existentes y la exportación de la base de datos, restáuralos en la plataforma administrada, y valida en una URL name.cdn.com.tr antes de cambiar el DNS. Tú mismo importas el volcado con las credenciales de MySQL administrado que ves en el panel, Redis y el caché edge se activan después de que el contenido se verifica, y el cambio de dominio ocurre al final, así que no hay ninguna ventana en la que el sitio quede inaccesible.
Un solo panel para agencias con muchos sitios
Las agencias sufren más por la inconsistencia: cada sitio de cliente termina en un hosting ligeramente distinto con diferentes plugins haciendo caché y seguridad. Estandarizar en la plataforma WordPress administrada significa el mismo runtime, el mismo modelo de Redis y edge, y el mismo perfil de WAF en todos los proyectos. El purge, los logs y el estado de deploy son visibles por sitio en la misma cuenta, así que entregar un sitio a otro miembro del equipo no significa reaprender una configuración a medida.
Cómo desplegar, paso a paso
Crea la app de WordPress
En el panel abre Platform, elige WordPress, y selecciona el runtime PHP 8 y el tamaño de plan. La plataforma aprovisiona el runtime, un volumen persistente para wp-content, y una base de datos MySQL administrada, así que nunca editas a mano las constantes de base de datos en wp-config.php — se inyectan por ti.
Conecta tu dominio y emite el SSL
Apunta el dominio a cdn.com.tr, o agrégalo como un subdominio name.cdn.com.tr para probar primero. Auto SSL emite y renueva el certificado, y tanto el apex como el www se validan por separado para que un bucle de redirección no deje una variante sin cubrir.
Activa el Redis object cache
Activa el add-on de Redis administrado y agrega el object-caché drop-in desde el panel. WordPress entonces almacena resultados de queries costosas, opciones y transients en Redis en lugar de martillar MySQL en cada solicitud, lo cual es la mayor ganancia individual para tráfico con sesión iniciada y de WooCommerce.
Activa el caché edge de CDN y la optimización de imágenes
Publica el sitio a través del edge para que los archivos estáticos — imágenes, CSS, JS, fuentes — se sirvan desde caché cerca del visitante. La optimización de imágenes recodifica y ajusta el tamaño de los medios al vuelo, así que no necesitas un plugin de optimización separado que ralentice wp-admin.
Define reglas de WAF y purge
Aplica el perfil de WAF delante de wp-login.php, xmlrpc.php y wp-admin, y define reglas de bypass de caché para las cookies de sesión iniciada y el carrito. Configura el purge automático para que publicar un post o actualizar un producto limpie el caché edge relevante sin necesidad de un flush manual.
Escenarios de ejemplo
Un sitio de noticias o blog absorbe picos de campaña con caché de página en el edge mientras Redis mantiene el panel editorial responsivo.
Las páginas de producto y categoría se cachean en el edge, el carrito y el checkout evitan el caché correctamente, y Redis mantiene rápidas las páginas personalizadas bajo carga.
Docenas de sitios de clientes corren en un stack estandarizado con el mismo SSL, WAF y modelo de caché, gestionado desde una sola cuenta.
Preguntas frecuentes
El Redis object cache romperá los plugins de caché de página que ya uso?
El object cache de Redis y el caché de página en el edge resuelven problemas diferentes y trabajan juntos. El object cache sirve resultados de base de datos desde memoria para páginas no cacheables con sesión iniciada; el caché edge sirve respuestas estáticas completas para visitantes anonimos. Normalmente puedes retirar una capa de page-caché basada en plugin una vez que el edge se encarga de eso, y mantener el object cache de Redis administrado para las partes dinámicas.
Cómo se mantiene el checkout de WooCommerce fuera del caché compartido?
Las reglas de caché detectan las cookies de WordPress y WooCommerce — la cookie de sesión iniciada y las cookies de carrito/sesión — y evitan el caché edge para esas solicitudes, así que ningún cliente ve jamás el carrito de otro cliente. Las páginas anonimas de producto y categoría se mantienen cacheadas, que es donde realmente está el tráfico y la ganancia de velocidad.
Sigo necesitando Wordfence, un plugin de caché, y un plugin de imágenes?
El stack cubre lo que esos plugins normalmente hacen: el WAF reemplaza el firewall de un plugin de seguridad delante de wp-admin, el edge y Redis reemplazan los plugins de caché, y la optimización de imágenes integrada reemplaza un plugin de imágenes. Eliminarlos libera workers de PHP, porque esos plugins de otro modo se ejecutan dentro de cada solicitud.
Publicar un post limpia el caché del CDN automáticamente?
Si. El purge automático está ligado a eventos de contenido, así que publicar o actualizar un post, página o producto limpia las entradas de caché edge relevantes. También puedes purgar manualmente desde el panel para cambios puntuales como un ajuste de tema o una imagen corregida.
Puedo mantener mi versión de PHP y plugins actuales durante la migración?
Migras hacia el runtime PHP 8 administrado; la mayoría de temas y plugins mantenidos corren en PHP 8 sin cambios. Validas el sitio en una URL temporal name.cdn.com.tr antes de cambiar el DNS, así que cualquier plugin que necesite una actualización se detecta antes de que los visitantes reales lo vean.
Qué pasa con las credenciales de base de datos de wp-config.php?
La conexion de base de datos administrada se inyecta en el runtime, así que no pegas el host, nombre, usuario o contraseña de la base de datos en wp-config.php a mano. Las credenciales se pueden rotar desde el panel sin editar el archivo, lo cual es más seguro que almacenarlas en texto plano en el repositorio o en disco.