El auge de WordPress y webflow: cambios clave que están transformando el panorama de los CMS
El mercado de los CMS nunca ha sido tan competitivo — ni tan interesante. Durante casi una década, WordPress mantuvo una posición prácticamente incontestada como la opción predeterminada para todo, desde blogs personales hasta sitios de marketing empresarial. Luego llegó Webflow, maduró y comenzó a atraer hacia un modelo fundamentalmente diferente a un segmento específico y valioso del mercado. Hoy, estas dos plataformas coexisten de una manera que nos dice mucho sobre hacia dónde se dirige el desarrollo web, qué necesitan realmente los clientes y cómo deben posicionarse las agencias para entregar valor real.
Esta no es una historia sobre una plataforma que vence a otra. Es una historia sobre segmentación de mercado, expectativas de compradores en evolución y las decisiones técnicas que separan los proyectos que escalan de los que se estancan.
Por Qué WordPress Sigue Dominando — y Hacia Dónde Está Evolucionando
WordPress impulsa aproximadamente el 43% de todos los sitios web en internet. Ese número se cita con frecuencia, se cuestiona con frecuencia y, en última instancia, sigue siendo notable. Refleja no solo el impulso histórico sino una utilidad genuina: una plataforma que ha demostrado que puede manejar desde un sitio de cinco páginas hasta una red multisitio global que atiende a millones de visitantes diarios.
Lo que ha cambiado es cómo se utiliza WordPress a nivel profesional, y qué separa el desarrollo serio de WordPress del trabajo de baja calidad que le ha dado a la plataforma una reputación mixta.
La Curva de Madurez de Gutenberg
El editor de bloques — Gutenberg — pasó sus primeros años siendo ampliamente rechazado. Los desarrolladores que habían construido flujos de trabajo en torno al Editor Clásico o Advanced Custom Fields resistieron el cambio. Los clientes encontraban la interfaz confusa. El ecosistema de plugins que extendía Gutenberg era inmaduro.
Ese panorama ha cambiado sustancialmente. Full Site Editing (FSE) y los temas de bloques ahora ofrecen un modelo genuinamente poderoso para construir layouts editables y estructurados sin acoplar las decisiones de diseño a las plantillas PHP. El sistema theme.json le da a los desarrolladores un control detallado sobre tipografía, espaciado, paletas de colores y restricciones de layout — todo expuesto al editor de una manera que evita que los clientes rompan sus propios sitios.
En werun.dev, nuestro trabajo con WordPress refleja esta madurez. Construimos bloques y patrones personalizados de Gutenberg que le dan a los equipos editoriales una flexibilidad real mientras se mantiene la consistencia del diseño. Un bloque construido correctamente — con registro en block.json, renderizado del lado del servidor donde corresponde e InspectorControls que exponen solo las opciones que tienen sentido — es una herramienta de contenido fundamentalmente mejor que un shortcode o un widget de un page builder.
El Desarrollo de Plugins como una Disciplina de Producto
Uno de los indicadores más claros del desarrollo profesional de WordPress es cómo se construyen los plugins. El WordPress Plugin API — hooks, filtros, la REST API, verificaciones de capacidades, nonces, sanitización y escapado — existe por una razón. Proporciona un contrato entre tu código y el núcleo de WordPress que hace que las actualizaciones sean manejables y las auditorías de seguridad sean factibles.
Las agencias y freelancers que tratan el desarrollo de plugins como una disciplina de producto — entregando con documentación, manteniendo changelogs, implementando sistemas de actualización automática mediante GitHub releases — están entregando algo cualitativamente diferente de quien simplemente agrega algunas funciones en functions.php y lo da por terminado.
Nuestra práctica de desarrollo de plugins está construida en torno a estos estándares. Cada plugin personalizado que entregamos incluye:
- Uso adecuado de las APIs de WordPress: Settings API, Options API, WP_Query, WP_REST_Controller
- Verificación de nonce en todos los envíos de formularios y solicitudes AJAX
- Verificaciones de capacidades antes de cualquier operación privilegiada
- Sanitización en la entrada, escapado en la salida — siempre
- Un sistema de actualización automática basado en GitHub para que los sitios de los clientes se mantengan actualizados sin intervención manual
- Documentación que cualquier desarrollador que nunca haya visto el código pueda seguir
WooCommerce como Plataforma Empresarial
WooCommerce ha madurado en una dirección que sorprende a quienes lo descartaron como un simple plugin de carrito de compras. Tiendas mayoristas B2B complejas, sistemas de facturación por suscripción, configuradores de productos personalizados e integraciones con ERP están todos en producción sobre WooCommerce — construidos por equipos que comprenden los puntos de extensión que ofrece la plataforma.
La clave es tratar WooCommerce como un framework en lugar de un producto terminado. Los tipos de productos personalizados, las reglas de precios construidas sobre la cadena de filtros woocommerce_get_price, la lógica de campos de checkout y las integraciones de fulfillment mediante la REST API te brindan una plataforma de comercio que puede satisfacer casi cualquier requerimiento de negocio. La limitación casi siempre es el conocimiento del desarrollador, no la capacidad de la plataforma.
En esto es donde se enfoca la práctica de WooCommerce de werun.dev: builds complejos que requieren comprender los internos de la plataforma, no la personalización de plantillas.
El Ascenso de Webflow y la Convergencia entre Diseño y Desarrollo
Webflow ocupa una posición diferente en el mercado, y entender esa posición con claridad es más útil que el debate ya agotado sobre si es una herramienta de desarrollo "real".
Webflow es un entorno de desarrollo visual que genera HTML y CSS limpio y semántico. No es un constructor de sitios web de arrastrar y soltar en el sentido de Wix. La distinción importa porque el output de Webflow es markup de calidad de producción — y porque el CMS, la API y el modelo de extensibilidad de la plataforma son lo suficientemente sofisticados como para soportar requerimientos de negocio serios.
El segmento del mercado que se ha movido hacia Webflow es identificable: equipos de marketing orientados al diseño, agencias con prácticas sólidas de diseño visual y empresas que necesitan que su sitio de marketing avance rápido sin depender de un desarrollador para cada actualización de contenido.
La Arquitectura del CMS como una Preocupación de Primer Nivel
El modo de falla más común en los proyectos de Webflow es tratar el CMS como una ocurrencia tardía. Un sitio construido con Colecciones de CMS mal estructuradas — o con contenido que debería ser dinámico codificado de forma estática en páginas estáticas — genera una deuda editorial que se acumula con el tiempo. Los editores de contenido no pueden hacer su trabajo. El sitio no puede escalar. La agencia recibe las críticas.
Construir correctamente la arquitectura del CMS de Webflow significa pensar en el modelo de datos antes de tocar el Designer. ¿Qué tipos de contenido necesitan Colecciones? ¿Qué relaciones existen entre ellos — y cómo se modelan esas relaciones dentro de las restricciones de los campos de referencia de Webflow? ¿Cómo sirve la estructura de URL de las páginas de Colección tanto al SEO como al flujo de trabajo editorial?
En werun.dev, tratamos la arquitectura del CMS como un problema de diseño que precede al diseño visual. La estructura de tus Colecciones determina qué pueden hacer tus editores, qué pueden mostrar tus páginas y a qué pueden acceder tus integraciones mediante la API de Webflow.
Código Personalizado, GSAP y los Límites del Designer
El Designer de Webflow maneja una cantidad notable de cosas sin código personalizado. Pero los sitios de producción para negocios serios casi siempre requieren ir más allá. Las interacciones personalizadas de JavaScript, las integraciones con APIs de terceros, la lógica de membresías y autenticación, y las secuencias de animación avanzadas requieren código que vive fuera de la capa visual de Webflow.
Las animaciones de GSAP integradas mediante embeds de código personalizado te brindan capacidades de diseño en movimiento que las interacciones nativas de Webflow no pueden igualar — secuencias activadas por scroll, SVGs que se transforman, animaciones de entrada controladas por timeline. Cuando se implementan con el rendimiento en mente (respetando prefers-reduced-motion, evitando el layout thrash, cargando GSAP solo donde se necesita), agregan valor genuino en lugar de ser simplemente ruido visual.
Nuestra práctica de Webflow también cubre los casos en que Webflow es el backend de CMS correcto pero el frontend necesita ir más allá del hosting de Webflow. Los builds de Webflow a Next.js — usando la API de Webflow para llevar el contenido del CMS a un frontend de Next.js o Astro — te brindan la experiencia editorial de Webflow con control total sobre el renderizado, el rendimiento y el enrutamiento.
Integraciones que Conectan Webflow con el Stack del Negocio
Un sitio de Webflow que existe de forma aislada del resto de los sistemas de un negocio es una oportunidad desaprovechada. Las plataformas que importan — HubSpot, Salesforce, Stripe, Airtable, Memberstack, Outseta — todas tienen APIs. Webflow tiene una API. La pregunta es si tu agencia sabe cómo conectarlas.
Patrones de integración comunes que construimos:
- Captura de leads hacia el CRM: Envíos de formularios enrutados a HubSpot o Salesforce con mapeo de campos, etiquetado y activadores de flujos de trabajo
- Portales de membresía: Áreas de contenido restringido construidas con Memberstack u Outseta, con Webflow gestionando el diseño y la plataforma de membresía gestionando la autenticación y los permisos
- Contenido dinámico desde fuentes externas: Airtable o una base de datos personalizada expuesta en Webflow mediante JavaScript personalizado y la API de Webflow
- Flujos de pago con Stripe: Experiencias de checkout personalizadas integradas en páginas de Webflow, con manejadores de webhooks que actualizan el contenido del CMS o activan automatizaciones posteriores
La capa de middleware — frecuentemente n8n, que también construimos y mantenemos — es lo que hace que estas integraciones sean confiables a escala en lugar de scripts frágiles de un solo uso.
Cómo Elegir entre WordPress y Webflow: Un Framework de Decisión Técnica
La pregunta que las agencias y sus clientes enfrentan con mayor frecuencia no es "cuál plataforma es mejor" sino "cuál plataforma es la correcta para este proyecto específico". Responder esa pregunta correctamente requiere un framework que vaya más allá de las comparaciones superficiales.
Complejidad del Contenido y Flujo de Trabajo Editorial
WordPress gana en flexibilidad bruta para el modelado de contenido. Los custom post types, las taxonomías personalizadas, los campos meta gestionados mediante ACF o la meta API nativa, y la REST API te brindan una capa de datos que puede representar casi cualquier estructura de contenido. Si tu equipo editorial gestiona miles de elementos a través de taxonomías complejas — un archivo multimedia, un catálogo de productos con estructuras de atributos profundas, una publicación multilingüe — WordPress es casi con certeza la elección correcta.
El CMS de Webflow es capaz y agradable de usar, pero tiene restricciones estructurales: límites de ítems de Colección en los planes inferiores, limitaciones en los campos de referencia y sin soporte nativo para relaciones de contenido profundamente anidadas. Para sitios con mucho contenido y modelos de datos complejos, estas restricciones importan.
Velocidad de Diseño y Fidelidad Visual
Webflow gana en velocidad de diseño a producción y fidelidad visual. Un archivo de Figma traducido a Webflow por un desarrollador que comprende la arquitectura de clases escalable puede estar en producción en una fracción del tiempo que lleva construir un tema equivalente de WordPress desde cero. El ciclo de retroalimentación visual — hacer un cambio en el Designer y verlo inmediatamente en el navegador — acelera la iteración.
Para proyectos donde el entregable principal es un sitio de marketing visualmente distintivo que necesita avanzar rápido, el modelo de Webflow tiene una ventaja de productividad genuina.
Extensibilidad y Funcionalidad Personalizada
WordPress gana en extensibilidad. El ecosistema de plugins — a pesar de su variación en calidad — te da acceso a problemas ya resueltos. Pasarelas de pago, sistemas de reservas, plataformas de membresía, sistemas de gestión del aprendizaje y cientos de otras categorías de funcionalidad existen como plugins de WordPress. Cuando necesitas algo que no existe, el plugin API te brinda una forma limpia de construirlo.
La extensibilidad de Webflow es real pero de naturaleza diferente. Los embeds de código personalizado y la API de Webflow son poderosos, pero siempre estás trabajando dentro de un entorno de hosting que no controlas completamente. Para aplicaciones que necesitan lógica del lado del servidor, acceso a bases de datos o procesamiento complejo en segundo plano, WordPress (o una arquitectura headless) es la opción más natural.
Rendimiento y Arquitectura de Hosting
Ambas plataformas pueden lograr excelentes puntuaciones en Core Web Vitals cuando se construyen correctamente. La variable es la calidad de implementación, no la capacidad de la plataforma.
WordPress en hosting administrado — WP Engine, SiteGround o un VPS bien configurado — con caché adecuado (object caching, full-page caching, CDN) entrega tiempos de carga inferiores a un segundo. El hosting de Webflow está respaldado por Fastly y distribuido globalmente por defecto, lo que elimina una categoría de decisiones de infraestructura del alcance del proyecto.
Para equipos que desean minimizar la gestión de infraestructura, el modelo de hosting de Webflow es genuinamente atractivo. Para equipos que necesitan control sobre la configuración del servidor, la estrategia de caché o la residencia de datos, WordPress en hosting administrado es la respuesta.
La Matriz de Decisión en la Práctica
Cuando llega un nuevo brief de proyecto a werun.dev, la decisión de plataforma sigue una lógica consistente:
- E-commerce complejo con lógica personalizada → WordPress + WooCommerce
- Sitio con mucho contenido y taxonomías complejas → WordPress
- Sitio de marketing orientado al diseño con necesidades moderadas de CMS → Webflow
- Portal de membresía o contenido restringido → Webflow + Memberstack/Outseta, o WordPress con una solución personalizada
- Sitio de marketing empresarial que necesita velocidad editorial y fidelidad de diseño → Webflow, potencialmente headless
- Funcionalidad similar a una aplicación con requerimientos significativos de backend → WordPress o un stack personalizado
La respuesta honesta es que ambas plataformas son capaces de más de lo que la mayoría de las personas les reconoce. El modo de falla no es elegir la plataforma incorrecta — es elegir la plataforma correcta y luego implementarla mal.
La Oportunidad para las Agencias: Profundidad sobre Amplitud
El cambio en el panorama de los CMS crea una oportunidad específica para las agencias que eligen la profundidad sobre la amplitud. El mercado está saturado de agencias generalistas que construirán un sitio de WordPress o Webflow sin opiniones sólidas sobre cómo debería hacerse. Ese trabajo está commoditizado, y la presión sobre los precios lo refleja.
Las agencias que están creciendo — y cobrando tarifas que reflejan el valor que entregan — son las que han desarrollado una experiencia genuina en las plataformas con las que trabajan. Conocen los casos límite. Saben qué falla a escala. Saben cómo estructurar un CMS para un equipo de contenido que lo usará en tres años. Saben cómo construir un plugin que sobreviva una actualización mayor de WordPress.
Cómo Se Ve Realmente la Experiencia en una Plataforma
Para WordPress, significa comprender el sistema de hooks con suficiente profundidad como para extender cualquier plugin sin modificar su código fuente. Significa saber cuándo usar wp_remote_get versus una consulta directa a la base de datos. Significa construir extensiones de WooCommerce que usen las clases CRUD en lugar de escrituras directas a la base de datos. Significa escribir endpoints de REST API que respeten la autenticación, las verificaciones de capacidades y el pipeline de validación de datos de WordPress.
Para Webflow, significa construir arquitecturas de clases que un nuevo desarrollador pueda leer y extender seis meses después del lanzamiento. Significa estructurar las Colecciones del CMS para que las respuestas de la API de Webflow sean predecibles y utilizables en integraciones posteriores. Significa saber cuándo GSAP es la herramienta correcta y cuándo las interacciones nativas de Webflow son suficientes. Significa comprender las compensaciones entre el hosting de Webflow y una arquitectura headless antes de que el cliente lo pregunte.
El Mantenimiento como Línea de Servicio
Uno de los diferenciadores más claros entre las agencias que entregan valor a largo plazo y las que solo entregan proyectos es el retainer de mantenimiento. Tanto los sitios de WordPress como los de Webflow requieren atención continua — WordPress para actualizaciones de seguridad, compatibilidad de plugins y monitoreo de rendimiento; Webflow para la evolución de la arquitectura del contenido del CMS, actualizaciones de código personalizado y mantenimiento de integraciones a medida que las APIs de terceros cambian.
En werun.dev, los retainers de mantenimiento mensuales son una parte central de nuestro modelo de servicio para ambas plataformas. No son un upsell — son el mecanismo por el cual los sitios que construimos continúan funcionando al nivel en que fueron lanzados. Un sitio de WordPress sin mantenimiento activo es una responsabilidad de seguridad en el plazo de dieciocho meses. Un sitio de Webflow sin alguien monitoreando sus integraciones fallará silenciosamente cuando una API cambie.
El Rol de la IA y la Automatización en el Trabajo con Plataformas
El cambio en el panorama de los CMS también está siendo moldeado por las herramientas de IA y automatización. Los flujos de trabajo de n8n que conectan los envíos de formularios de Webflow con pipelines de CRM, los chatbots de IA integrados en sitios de WordPress mediante endpoints personalizados de REST API, y los pipelines de enriquecimiento de datos que populan las Colecciones del CMS de Webflow desde fuentes externas — estas no son capacidades futuras. Están en producción hoy.
Nuestra práctica de IA y automatización en werun.dev está cada vez más entrelazada con nuestro trabajo de CMS. Un sitio de Webflow conectado a un flujo de trabajo de n8n que califica leads, enriquece datos de contacto y enruta oportunidades al representante de ventas correcto es un activo significativamente más valioso que un sitio de marketing estático. Una base de conocimiento de WordPress conectada a un chatbot con tecnología RAG que puede responder preguntas de clientes con citas a publicaciones específicas es una herramienta de soporte al cliente, no solo un repositorio de contenido.
Las agencias que comprenden tanto la capa del CMS como la capa de automatización — y pueden conectarlas — están posicionadas para entregar algo que ni una agencia especializada exclusivamente en WordPress ni un consultor especializado exclusivamente en automatización pueden ofrecer por sí solos.