¿Están muriendo las plataformas CMS tradicionales? el impacto real de WordPress y webflow en el desarrollo web moderno

La frase 'el CMS tradicional está muerto' lleva años circulando en canales de Slack para desarrolladores y hilos de LinkedIn. Resurge cada vez que se lanza un nuevo framework headless, cada vez que Webflow agrega una funcionalidad, cada vez que alguien compara el rendimiento de un sitio estático contra un monolito de WordPress y publica una captura de pantalla con la diferencia. Pero la realidad —como ya sabe cualquiera que construya sitios en producción para empresas reales— es considerablemente más matizada de lo que sugiere esa opinión superficial.

La pregunta que vale la pena hacerse no es si las plataformas CMS tradicionales están muriendo. La pregunta es si están evolucionando con la suficiente rapidez, y si los equipos que trabajan sobre ellas están al ritmo de lo que el mercado realmente demanda.

WordPress en 2024: ¿Plataforma Madura o Pasivo Tecnológico?

WordPress impulsa entre el 40% y el 43% de todos los sitios web en internet, dependiendo de qué datos de rastreo se consulten. Esa cifra es simultáneamente impresionante y engañosa. La cuota de mercado bruta habla de la base instalada, no de dónde está ocurriendo el crecimiento, y desde luego no dice nada sobre la calidad de lo que se está construyendo.

El panorama honesto es este: una porción significativa de ese 43% corresponde a sitios abandonados, instalaciones de baja calidad en hosting compartido y temas comprados en Themeforest que no se han tocado desde 2019. Ese es el WordPress al que apuntan los críticos cuando declaran la plataforma muerta. No se equivocan en cuanto al problema —se equivocan en cuanto a la conclusión.

El WordPress sobre el que construye werun.dev es un producto fundamentalmente diferente:

• Full Site Editing (FSE) y block themes han reemplazado el antiguo paradigma de los page builders con una arquitectura composable y basada en estándares que otorga a los desarrolladores un control estructural genuino
• La REST API y WPGraphQL convierten a WordPress en una capa de contenido headless creíble para Next.js, Astro y otros front-ends modernos
• El desarrollo de plugins personalizados utilizando las APIs propias de WordPress —hooks, filters, nonces, verificaciones de capacidades, sanitización— produce software mantenible, seguro y auditable
• WooCommerce, cuando se construye correctamente con tipos de productos personalizados, reglas de precios e integraciones con ERP/CRM, gestiona escenarios de comercio B2B y D2C que Shopify no puede abordar sin un desarrollo de aplicaciones personalizadas considerable

Dónde WordPress Realmente Tiene Dificultades

Las debilidades de la plataforma son reales y vale la pena nombrarlas directamente:

El rendimiento por defecto es deficiente. Una instalación estándar de WordPress con un tema genérico y un conjunto de plugins ensamblado desde el repositorio oficial no obtendrá buenos resultados en Core Web Vitals. Esto no es una limitación fundamental de la plataforma —es una consecuencia de cómo se ensambla la mayoría de los sitios WordPress. Los block themes personalizados construidos con HTML semántico y sin assets que bloqueen el renderizado, combinados con un stack de hosting adecuado (WP Engine, SiteGround o un VPS bien configurado), obtienen de manera habitual puntuaciones de 90+ en Lighthouse. La plataforma no impone el techo de rendimiento —lo impone la implementación.

La experiencia de edición requiere inversión. Gutenberg ha mejorado notablemente desde su turbulento lanzamiento en 2018, pero construir una experiencia de edición que los equipos de contenido no técnicos puedan usar con confianza requiere un diseño deliberado de bloques y patrones. Dejar a los editores frente a una interfaz de Gutenberg sin bloques ni patrones personalizados es un fallo de implementación, no un fallo de la plataforma.

La superficie de ataque en seguridad es amplia. El ecosistema de plugins de WordPress es su mayor fortaleza y su vector de ataque más significativo. Los plugins con sanitización deficiente, verificación de nonce ausente o ciclos de mantenimiento abandonados son la principal fuente de vulnerabilidades en WordPress. Es precisamente por eso que cada plugin que werun.dev entrega incluye verificaciones de capacidades adecuadas, escapado correcto y un sistema de actualización automática basado en GitHub —para que los sitios de los clientes nunca ejecuten código desactualizado.

El Caso del WordPress Headless

Para los equipos que necesitan la familiaridad editorial de WordPress combinada con el rendimiento y la flexibilidad de front-end de un framework JavaScript moderno, WordPress headless es una elección arquitectónica legítima. La REST API de WordPress o WPGraphQL actúa como capa de contenido; Next.js o Astro se encarga del renderizado. Se obtiene:

WordPress Admin (ingreso de contenido)
        ↓
  WPGraphQL / REST API
        ↓
  Next.js / Astro (SSG o SSR)
        ↓
  Entrega en el edge mediante CDN

Esta arquitectura preserva todo lo que los equipos de contenido valoran de WordPress —el admin familiar, los custom post types, Advanced Custom Fields, la biblioteca de medios— mientras entrega tiempos de carga inferiores a un segundo y control total sobre la estructura de componentes del front-end. No es la elección correcta para todos los proyectos, pero para sitios B2B con mucho contenido donde el flujo de trabajo editorial importa y el rendimiento no puede comprometerse, es una opción convincente que mantiene a WordPress relevante en un mundo headless.

El Ascenso de Webflow y Lo Que Realmente Significa para el Desarrollo Profesional

Webflow ocupa una posición genuinamente interesante en el panorama de los CMS. No es un CMS tradicional en el sentido de WordPress, y tampoco es una herramienta no-code básica en el sentido de Wix. Se sitúa en un punto intermedio productivo que, cuando lo utilizan desarrolladores que comprenden su arquitectura, produce resultados que serían difíciles de lograr con cualquier otra herramienta en el mismo plazo.

La narrativa de que Webflow está 'matando a WordPress' malinterpreta para qué sirve cada plataforma. El CMS de Webflow está diseñado específicamente para sitios de marketing, portafolios, publicaciones editoriales y landing pages de productos donde la fidelidad de diseño y la simplicidad editorial son los requisitos principales. No es una plataforma de aplicaciones de propósito general. WordPress sí lo es. Resuelven problemas diferentes para compradores diferentes.

Lo que Webflow ha disrumpido genuinamente es la categoría de sitios de marketing del mercado medio —el sitio de marca de entre $15,000 y $60,000 USD que solía construirse en WordPress con un tema personalizado. Para ese caso de uso, el entorno de desarrollo visual de Webflow, combinado con su CMS integrado, su infraestructura de hosting y sus capacidades de animación nativas, produce tiempos de lanzamiento más rápidos con menor carga de mantenimiento continuo.

Cómo Luce Realmente el Desarrollo Profesional en Webflow

Los proyectos de Webflow que fracasan —y hay muchos— comparten características comunes: nomenclatura de clases inconsistente, arquitecturas de CMS que se rompen bajo flujos de trabajo editoriales reales, ausencia de una capa de código personalizado y ningún plan para las integraciones que el cliente inevitablemente necesitará seis meses después del lanzamiento.

El desarrollo profesional en Webflow, el tipo que entrega werun.dev, luce bastante diferente:

• Arquitectura de clases escalable al estilo BEM diseñada desde el primer componente, no aplicada de manera retroactiva
• Arquitectura de colecciones del CMS diseñada en torno a cómo trabajan realmente los editores, no en torno a lo que es más fácil de construir
• JavaScript personalizado e integraciones con la API de Webflow que conectan el sitio con plataformas CRM, sistemas de pago, bases de datos en Airtable y herramientas internas
• Animaciones con GSAP que van significativamente más allá de lo que puede producir el panel de interacciones nativo de Webflow
• Integraciones con Memberstack u Outseta para contenido restringido, paneles de miembros y portales de clientes
• Implementaciones multiidioma mediante Weglot o la localización nativa de Webflow para marcas internacionales

El Techo del CMS de Webflow

El CMS de Webflow tiene límites estrictos que se vuelven relevantes a escala: límites en los ítems de colección, restricciones en los campos de referencia y la ausencia de modelos de datos relacionales complejos. Para sitios que necesitan una complejidad de contenido genuina —taxonomías anidadas, relaciones entre custom post types, generación programática de contenido— el CMS de Webflow no es la herramienta adecuada. Aquí es donde la arquitectura Webflow-to-Next.js o Webflow-to-Astro se vuelve relevante. Webflow gestiona el diseño y el contenido simple; un front-end personalizado gestiona la capa de datos compleja. Es un patrón que werun.dev implementa para clientes que han superado las limitaciones del CMS de Webflow pero no quieren abandonar el entorno de diseño visual en el que han invertido.

La limitación más significativa es la capa de e-commerce de Webflow. Webflow Commerce existe, pero no es un competidor serio de WooCommerce o Shopify para nada más allá de catálogos de productos simples. Cualquier proyecto de Webflow con requisitos de comercio genuinos —reglas de precios personalizadas, funcionalidad mayorista B2B, facturación por suscripción, integración con ERP— necesita ya sea Shopify integrado mediante Buy Button o una migración completa a una plataforma de comercio dedicada.

El Cambio Hacia Arquitecturas Headless y Composables

El patrón de desarrollo que está disrumpiendo genuinamente a las plataformas CMS tradicionales no es Webflow, y tampoco es un nuevo competidor de WordPress. Es el cambio arquitectónico hacia sistemas composables y API-first —donde el CMS está desacoplado del front-end, y ambos están desacoplados del comercio, la búsqueda, la autenticación y cualquier otra función que solía estar integrada en una plataforma monolítica.

Este cambio importa para los compradores B2B porque modifica el perfil de riesgo de sus decisiones tecnológicas. Un sitio WordPress monolítico que hace todo en una sola base de código es rápido de construir inicialmente y cada vez más costoso de mantener, extender y migrar. Una arquitectura composable donde WordPress gestiona el contenido, Shopify gestiona el comercio, un proveedor de búsqueda dedicado gestiona la búsqueda y un front-end personalizado gestiona el renderizado es más compleja de arquitectar inicialmente y significativamente más duradera en un horizonte de cinco años.

Dónde Entran en Escena la IA y la Automatización

El cambio hacia arquitecturas composables se intersecta directamente con la capa de IA y automatización que los sitios B2B modernos requieren cada vez más. Un sitio WordPress o Webflow headless conectado a un flujo de trabajo de automatización en n8n puede:

• Enriquecer automáticamente los datos de leads entrantes desde formularios de contacto antes de que lleguen al CRM
• Activar secuencias de correo electrónico personalizadas basadas en patrones de consumo de contenido
• Ejecutar clasificación y etiquetado de contenido impulsado por IA en nuevas entradas del CMS
• Alimentar datos estructurados del sitio a un chatbot de conocimiento basado en RAG que gestiona la calificación previa a la venta

Nada de esto es posible con un CMS monolítico tradicional sin un desarrollo personalizado significativo y una carga de mantenimiento continua. La arquitectura headless hace que la superficie de integración sea limpia y predecible. Los flujos de trabajo de n8n se conectan a la API del CMS, la API del CRM y la API del modelo de IA de forma independiente —sin conflictos de plugins, sin sobrecarga del admin de WordPress, sin las limitaciones del Webflow Designer.

Elegir la Arquitectura Correcta para el Proyecto

El marco de decisión práctico para proyectos de sitios B2B en 2024 luce así:

Usa WordPress cuando:

• El proyecto requiere custom post types complejos, taxonomías y relaciones de metadatos
• WooCommerce es la capa de comercio y requiere una personalización profunda (tipos de productos personalizados, precios B2B, integración con ERP)
• El equipo editorial ya está familiarizado con el admin de WordPress
• El desarrollo de plugins a largo plazo y los endpoints de la REST API forman parte del alcance
• Se requiere arquitectura Multisite para gestionar múltiples propiedades de marca

Usa Webflow cuando:

• El entregable principal es un sitio de marketing o de marca de alta fidelidad
• La fidelidad del diseño en producción es la prioridad máxima y el plazo es ajustado
• El modelo de contenido es sencillo y encaja dentro de la arquitectura de colecciones del CMS de Webflow
• El equipo del cliente necesita gestionar el contenido sin intervención de desarrolladores
• Las animaciones con GSAP y el diseño de interacciones son centrales para el proyecto

Usa una arquitectura composable/headless cuando:

• El sitio funciona como un componente dentro de un ecosistema digital más amplio
• El rendimiento del front-end no es negociable y el volumen de contenido es alto
• Múltiples fuentes de datos deben unificarse en la capa de presentación
• Las integraciones de IA y automatización forman parte de la hoja de ruta
• El horizonte de mantenimiento y extensibilidad a cinco años importa tanto como el costo de lanzamiento

Los equipos que declaran muertas las plataformas CMS tradicionales suelen ser los mismos que solo las han visto implementadas de manera deficiente. Un sitio WordPress construido según estándares de codificación —hooks y filters correctos, endpoints de REST API, actualizaciones automáticas basadas en GitHub, puntuaciones de 90+ en Core Web Vitals— no es un pasivo tecnológico. Un sitio Webflow construido con una arquitectura de clases escalable, un CMS diseñado para flujos de trabajo editoriales reales y una capa de código personalizado que lo conecta con el stack de negocio del cliente no es un juguete.

La plataforma rara vez es el problema. La implementación casi siempre lo es.