Por qué dejamos WordPress: seguridad, velocidad y el problema de los plugins
Como estudio de desarrollo que gestiona más de 30 proyectos de clientes, nuestras decisiones tecnológicas tienen un peso real. Después de años construyendo y manteniendo sitios en WordPress, tomamos una decisión: Astro es ahora el framework estándar para todos los proyectos de clientes. Estamos migrando seis sitios existentes de WordPress (la mayoría construidos con Elementor o plugins pesados de plantillas) y convirtiendo varios sitios HTML estáticos de más de 100 páginas. Todo proyecto nuevo arranca con Astro. No es solo una preferencia técnica. Es una decisión de negocio impulsada por la seguridad, el rendimiento, los costos y la cordura de todos los que participan en el mantenimiento de estos sitios.
El problema de la seguridad
El núcleo de WordPress recibe parches con regularidad. El equipo de WordPress hace un trabajo sólido en ese frente. Pero el riesgo real nunca ha estado en la plataforma central. Está en el ecosistema de plugins. Cada plugin que instalas introduce una nueva superficie de ataque. Un sitio empresarial típico en WordPress ejecuta entre 15 y 30 plugins, y cada uno está mantenido por un desarrollador independiente o un equipo pequeño con distintos niveles de compromiso con las buenas prácticas de seguridad.
Esto no es teoría. Solo Elementor ha tenido múltiples CVEs críticos. Plugins de formularios han sido explotados para inyección SQL. Plugins de carga de archivos han permitido ejecución remota de código. Cada uno de estos plugins ejecuta PHP del lado del servidor con acceso completo a tu base de datos y sistema de archivos. Un solo plugin comprometido puede exponer todo tu sitio a robo de datos, inyección de malware o toma total del control.
Más allá de los plugins, la arquitectura misma genera riesgos. WordPress expone una página de inicio de sesión en una URL conocida que recibe ataques de fuerza bruta todos los días. Mantiene una conexión activa a la base de datos en cada carga de página. Ejecuta PHP en cada solicitud. Para un desglose detallado de qué vigilar, consulta nuestra lista de verificación de seguridad web.
Astro elimina estos vectores de ataque por diseño. Genera HTML estático en tiempo de compilación. No hay ejecución de PHP en el servidor. No hay base de datos expuesta a la web. No hay página de login que atacar por fuerza bruta. No hay plugins ejecutando código del lado del servidor. La superficie de ataque se reduce prácticamente a cero.
Superficie de ataque de WordPress
Runtime PHP, base de datos MySQL, login de administrador, 15-30 plugins (cada uno con acceso al servidor), temas con código ejecutable, endpoint XML-RPC, REST API, handlers de carga de archivos, tareas cron, gestión de sesiones.
Superficie de ataque de Astro
Archivos estáticos HTML/CSS/JS servidos desde un CDN o un servidor web simple. Sin ejecución de código del lado del servidor, sin base de datos expuesta, sin endpoint de login. El proceso de compilación se ejecuta localmente o en CI.
El problema de la velocidad
Los sitios con Elementor son lentos. No a veces lentos, no de vez en cuando lentos. Consistente y predeciblemente lentos. Una página típica de Elementor carga entre 2 y 4 megabytes de recursos: jQuery (del cual Elementor todavía depende), sus propias librerías JavaScript, CSS que bloquea el renderizado proveniente del tema y de cada plugin activo, fuentes web cargadas de forma ineficiente, y estructuras DOM anidadas cinco o seis niveles de profundidad para tareas de layout simples.
El resultado son puntajes de Lighthouse en los 40 y 50. Fallas en Core Web Vitals en todos los indicadores. Tiempos de Largest Contentful Paint medidos en segundos, no en milisegundos. Cumulative Layout Shift causado por widgets que cargan de forma asíncrona y empujan el contenido. Estos no son casos extremos. Este es el punto de partida de la mayoría de los sitios construidos con Elementor.
La velocidad del sitio no es una métrica de vanidad. Google usa Core Web Vitals como señal de posicionamiento, y los usuarios abandonan las páginas lentas antes de siquiera ver tu contenido.
Astro toma el enfoque contrario. No envía JavaScript al navegador por defecto. Las páginas son HTML pre-compilado que carga de forma instantánea. Cuando necesitas interactividad (un formulario de contacto, un widget de chat, una calculadora dinámica), la arquitectura de islas de Astro hidrata solo ese componente específico, no la página completa. Todo lo demás permanece como HTML estático liviano.
La diferencia en rendimiento es notable. Los puntajes de Lighthouse saltan de los 40 a 95+. Las páginas cargan en menos de un segundo. Core Web Vitals pasa de forma consistente. Google recompensa esto con mejores posiciones en los resultados de búsqueda, y los usuarios permanecen en el sitio en lugar de abandonarlo.
El problema del mantenimiento
Cualquiera que haya gestionado sitios WordPress para clientes conoce el flujo de trabajo de "actualizar y rezar". Un plugin lanza una nueva versión. Haces clic en actualizar. El sitio se rompe porque el plugin entra en conflicto con otro plugin, o con el tema, o con la versión de PHP. Ahora estás depurando un sitio en producción a las 10 de la noche porque el formulario de contacto de un cliente dejó de funcionar.
Esto no es un inconveniente ocasional. Es un costo recurrente de trabajar con WordPress. Las actualizaciones de temas sobrescriben el CSS personalizado. Las actualizaciones de la versión de PHP rompen plugins antiguos. Las actualizaciones del núcleo de WordPress generan problemas de compatibilidad con temas que no se han actualizado en seis meses. La carga de mantenimiento escala de forma lineal con la cantidad de plugins instalados, lo que significa que mientras más funcional sea el sitio, más frágil se vuelve.
Los sitios en Astro no tienen dependencias en tiempo de ejecución en el servidor. Una vez compilados y desplegados, el sitio es una colección de archivos estáticos. No hay plugins que actualizar, no hay versiones de PHP que gestionar, no hay base de datos que optimizar. Los cambios pasan por un flujo de desarrollo: editas el código, pruebas localmente, compilas y despliegas. Si algo sale mal, vuelves al despliegue anterior. Todo el proceso es predecible y repetible. Escribimos sobre este cambio más amplio en nuestro artículo sobre por qué los sitios estáticos están de vuelta.
El problema del costo
WordPress es "gratis" de la misma forma que un cachorro es gratis. El software no cuesta nada, pero los gastos continuos se acumulan rápido. Un sitio empresarial típico en WordPress tiene estos costos anuales:
- Elementor Pro: $59 a $99/año
- Yoast SEO Premium: $99/año
- Licencia de tema premium: $59 a $129/año
- Hosting administrado para WordPress: $25 a $50/mes ($300 a $600/año)
- Plugin de seguridad (Wordfence/Sucuri): $99 a $199/año
- Plugin de respaldos: $50 a $100/año
Eso son entre $600 y $1,000 por año, por sitio, sin contar el trabajo de desarrollo. Multiplica eso por 10 sitios de clientes y estás viendo entre $6,000 y $10,000 en cuotas recurrentes por software que genera vulnerabilidades de seguridad y problemas de rendimiento.
Astro es de código abierto. Alojar un sitio estático de Astro en un VPS cuesta entre $5 y $12 por mes. Sin licencias de plugins. Sin temas premium. Sin sobrecostos de hosting administrado. Sin suscripciones de monitoreo de seguridad (porque la superficie de ataque casi no existe). El ahorro es considerable y se multiplica con cada sitio en tu portafolio.
Y entonces, ¿qué pasa con el CMS?
La pregunta obvia: si dejas WordPress, ¿cómo gestionan los clientes su contenido? Todavía necesitan actualizar páginas, publicar artículos de blog y administrar sus sitios sin llamar a un desarrollador por cada cambio de texto.
En lugar de reemplazar WordPress con otra dependencia SaaS (Sanity a $99/usuario/mes, Contentful a $300/mes), construimos un CMS headless personalizado. Corre sobre FastAPI y MariaDB, incluye un editor potenciado por IA que permite a los clientes describir los cambios en lenguaje natural, y alimenta los sitios Astro a través de una API JSON. Sin tarifas por usuario, sin dependencia de un proveedor, y funciona en todos nuestros sitios de clientes. Cubriremos la historia técnica completa en un próximo artículo: Cómo construimos un CMS headless personalizado para Astro.
WordPress resolvió un problema real cuando se lanzó. Hizo que la creación de sitios web fuera accesible para millones de personas. Pero para sitios empresariales enfocados en contenido en 2026, los riesgos de seguridad del ecosistema de plugins, los costos de rendimiento de su arquitectura y la carga de mantenimiento continuo ya no justifican elegirlo por defecto. Astro te ofrece una experiencia de desarrollo moderna con la seguridad y velocidad de un sitio estático, y cuando se combina con un CMS headless, tus clientes no pierden nada en términos de gestión de contenido. Las cuentas son claras: mejor seguridad, páginas más rápidas, costos más bajos, menos mantenimiento. Por eso cada nuevo sitio de cliente que construimos arranca con Astro.
