Polimake

CMS: de Vignette en 1995 a WordPress, Shopify y la era headless de 2026

Qué es un CMS explicado con su historia real desde Vignette StoryServer en 1995 hasta WordPress (lanzado en mayo de 2003), Drupal (2001), Joomla (2005), Shopify (2006), Webflow (2013), y la era headless con Contentful (2013) y Strapi (2015). Las decisiones de arquitectura (tradicional, headless, hybrid) y cómo elegir según contexto.

· Platform

El equipo detrás de Polimake. Exploramos la intersección entre tecnología, creatividad y automatización.

Publicado:

Un CMSContent Management System, o sistema de gestión de contenido— es el software que permite crear, editar, organizar y publicar contenido en una web sin tener que programar cada página manualmente. Para alguien acostumbrado a publicar en WordPress, Shopify o Webflow, la idea suena tan obvia que parece haber existido siempre. No es así: el CMS como categoría de software tiene unos treinta años, una historia industrial bien documentada, y una serie de decisiones de arquitectura cuyo impacto se siente durante años después de elegir.

Conviene situar el concepto históricamente para entender por qué hay tantas opciones tan distintas, y por qué la pregunta práctica "¿qué CMS uso?" tiene mejor respuesta cuando se reformula como "¿qué tipo de CMS para qué tipo de proyecto?"

Una historia industrial de tres décadas

Mediados de los 90: la era del CMS empresarial caro. El primer CMS comercial ampliamente reconocido fue Vignette StoryServer, lanzado por Vignette Corporation alrededor de 1995, originalmente desarrollado para CNET. Era software empresarial caro (cientos de miles a millones de dólares por licencia + implementación) que se vendía a grandes corporaciones y medios. Otros CMS empresariales de la época: Documentum, Interwoven (más orientado a publicación digital), Tridion.

Esa era estaba dominada por software propietario, instalación local pesada, y precios fuera del alcance de cualquier proyecto que no fuera corporativo. Una página web personal o una pequeña empresa hacían su sitio con HTML estático escrito a mano.

2001-2003: la revolución open source. Tres lanzamientos cambiaron la economía del sector:

Drupal se publicó como software open source en 2001 por Dries Buytaert, entonces estudiante en la Universidad de Lovaina (KU Leuven, Bélgica). Drupal era inicialmente un sistema de tablones de mensajes que evolucionó a CMS general. Su modularidad y extensibilidad lo convirtieron en estándar para sitios complejos y proyectos gubernamentales (la Casa Blanca lo usó durante años, así como ministerios europeos).

Movable Type, también de 2001, fue durante años el blogging engine dominante. Perdió terreno significativo en 2004 cuando Six Apart cambió su modelo de pricing y muchos usuarios migraron a alternativas open source.

WordPress se lanzó como versión 0.7 el 27 de mayo de 2003, fundado por Matt Mullenweg (entonces 19 años, en Houston) y Mike Little (en Reino Unido). Era un fork del proyecto b2/cafelog, creado por Michel Valdrighi y abandonado tras ser absorbido por dificultades personales. Mullenweg y Little tomaron el código, lo continuaron, y construyeron lo que en pocos años se convertiría en la plataforma de blogging más usada del mundo.

Joomla apareció en 2005 como fork de Mambo (proyecto de 2000) tras desacuerdos sobre gobernanza.

Los tres —Drupal, WordPress, Joomla— constituyeron durante una década el "Big Three" del CMS open source. La economía del sector cambió radicalmente: software gratuito, instalación accesible, ecosistema de plugins/temas/módulos creciente.

2003-2010: la era de los CMS verticales especializados. Aparecieron CMSs especializados por verticales:

Shopify lanzó en 2006 (fundado por Tobi Lütke en Ottawa, originalmente para vender una tienda de snowboards). Se convirtió en el CMS dominante para ecommerce.

Squarespace fue fundada por Anthony Casalena en su dormitorio universitario de la University of Maryland en 2003. Apuntó al mercado del usuario no técnico que quería un sitio bonito sin programar.

Tumblr (2007) y Ghost (2013) se especializaron en blogging puro y publicación digital.

2010s: Webflow y los visual builders. Webflow se fundó en 2013 por Vlad Magdalin y Sergie Magdalin. Combinaba diseño visual con código limpio generado, captando un nicho entre desarrolladores y diseñadores. Otras plataformas similares (Wix, que existía desde 2006, evolucionó significativamente; Editor X de Wix; Framer) consolidaron la categoría.

2013-presente: la era headless. El concepto de headless CMS —separar la gestión de contenido de la presentación, exponiendo el contenido vía API— emergió como respuesta a las limitaciones de los CMS monolíticos para webs modernas, apps móviles y experiencias multi-canal. Hitos:

Contentful, fundada en 2013 en Berlín por Sascha Konietzka y Paolo Negri, fue el primer headless CMS comercial significativo.

Strapi, open source, se lanzó en 2015.

Sanity se lanzó en 2017 con un enfoque más estructurado en datos.

Mathias Biilmann, CEO de Netlify, popularizó alrededor de 2015-2016 el término Jamstack (JavaScript, APIs, Markup) para describir arquitecturas web modernas que combinan frontend pre-renderizado, APIs y CMS headless.

A finales de los 2010 y entrando los 2020, la adopción de headless CMS creció significativamente, especialmente en empresas con sitios complejos, equipos técnicos sofisticados, y necesidades multi-canal (web + móvil + smartwatch + signage + voz, etc.).

2026: el panorama actual. Coexisten varias categorías:

  • WordPress sigue siendo dominante en volumen: aproximadamente 43% de todos los sitios web del mundo según datos de W3Techs, una cifra que se ha mantenido relativamente estable durante los últimos años.
  • Shopify domina el ecommerce, con cifras que rondan el 10-15% de los sitios de e-commerce a nivel global.
  • Webflow ha crecido en mercado mid-market y agencias de diseño.
  • Wix y Squarespace mantienen posiciones fuertes en pequeñas empresas y portfolios.
  • Headless CMS (Contentful, Strapi, Sanity, Storyblok, Payload, Hygraph) capturan el mercado enterprise y proyectos técnicos sofisticados — alrededor del 30% de los sitios enterprise según estudios recientes.
  • CMS especializados: Ghost para publicación seria, Notion como alternativa light para sitios sencillos, Framer para sitios con foco en diseño.

Los tres modelos arquitectónicos: tradicional, headless, hybrid

La distinción operativa más importante para tomar decisiones de CMS hoy no es WordPress vs. Drupal, sino la arquitectura subyacente:

CMS tradicional (monolítico)

El backend (donde se gestiona contenido) y el frontend (donde se muestra al usuario) están acoplados. WordPress en su forma habitual, Drupal tradicional, Shopify Liquid son ejemplos. El CMS recibe la petición del usuario, consulta su base de datos, renderiza HTML y lo entrega.

Cuándo encaja: sitios web de complejidad moderada, blogs, sitios corporativos, ecommerce estándar. Equipos no técnicos que valoran simplicidad operativa.

Limitaciones: acoplamiento limita flexibilidad multi-canal (la misma data en web, app, voz, IoT), rendimiento dependiente del servidor, escalado más caro.

CMS headless (decoupled)

Solo backend de gestión de contenido. El frontend se construye separadamente (con cualquier framework: React, Next.js, Vue, Astro, etc.) y consume el contenido vía API. Contentful, Strapi, Sanity, Storyblok son ejemplos.

Cuándo encaja: sitios complejos con múltiples canales (web + app + IoT), equipos con capacidad técnica frontend dedicada, requisitos de rendimiento alto, necesidad de migrar tecnología frontend sin tocar el contenido.

Limitaciones: complejidad técnica significativamente mayor, requiere desarrollo frontend independiente, coste inicial mayor, curva de aprendizaje empinada para editores no técnicos.

CMS hybrid (decoupled pero con presets)

Categorías intermedias: WordPress puede usarse en modo headless con su REST API o WPGraphQL, Drupal con JSON:API. También plataformas como Storyblok que ofrecen visual editing en headless.

Cuándo encaja: transición desde tradicional sin perder herramientas conocidas, necesidad de algunas ventajas headless sin la complejidad completa.

Limitaciones: suele ser compromiso que no captura completamente las ventajas de cada extremo.

Cómo elegir CMS sin equivocarse

Las decisiones de CMS tienen consecuencias largas (la migración cuesta entre semanas y meses, según complejidad del sitio). Conviene preguntarse honestamente:

¿Quién va a publicar y con qué frecuencia? Si tienes equipo editorial publicando varias veces por semana, la usabilidad para editores no técnicos es prioritaria. Si solo se actualiza una vez al mes, otras consideraciones pesan más.

¿Qué tipo de contenido? Blog y páginas estáticas funcionan en cualquier CMS. Ecommerce serio necesita algo especializado (Shopify, WooCommerce, Magento, BigCommerce). Multimedia pesado (vídeo, podcast) tiene CMSs específicos. Documentación técnica funciona mejor en CMSs estructurados (GitBook, Docusaurus).

¿Qué capacidad técnica tiene tu equipo? Sin desarrolladores, headless es un riesgo enorme. Con equipo técnico fuerte, headless puede ser ventaja competitiva.

¿Qué presupuesto sostenido? Más allá del coste inicial, hay coste de hosting, mantenimiento, seguridad, plugins/extensiones, formación. WordPress puede ser "gratis" pero un sitio profesional WordPress cuesta miles de euros anuales en mantenimiento serio.

¿Multi-idioma, multi-region, multi-marca? Algunos CMSs lo manejan bien out-of-the-box (Drupal multilingüe está muy refinado), otros requieren plugins complejos (WordPress con WPML, Polylang).

¿Integraciones críticas? CRM, marketing automation, analytics, e-commerce, herramientas internas. Verificar disponibilidad y calidad de integraciones antes de comprometer plataforma.

¿Compromiso temporal? El CMS de hoy debería seguir sirviéndote en 5 años. Empresas que cambian CMS cada 2 años pierden mucho tiempo en migraciones.

¿Riesgo de lock-in? ¿Qué pasaría si quisieras migrar? CMS open source tienen migración más sencilla; CMS proprietary muy específicos pueden ser difíciles de abandonar.

Errores comunes en decisiones de CMS

Elegir por moda. "Todos están en headless" no es razón para que tu marca pequeña con un blog pase a headless. La complejidad técnica añadida solo se justifica con uso real de las capacidades.

Subestimar el coste total de propiedad. WordPress aparenta ser gratis. Un sitio WordPress profesional con seguridad, performance, plugins premium, mantenimiento puede costar miles de euros al año. La economía real incluye todos esos elementos.

Instalar demasiados plugins. En WordPress especialmente, cada plugin es superficie de ataque, posible conflicto con otros plugins, posible problema de rendimiento. Un sitio WordPress con 40+ plugins suele estar en problemas.

No considerar SEO técnico. Algunos CMSs (especialmente Webflow, Shopify) generan código limpio por defecto. Otros (algunas instalaciones malas de WordPress) producen código pesado, lento o mal estructurado.

Olvidar permisos y roles. Sin permisos bien configurados, cualquier editor puede romper páginas críticas. Definir roles desde el inicio evita incidentes.

No mantener backups. Un sitio sin backups es lotería esperando. Backups automatizados, en ubicación distinta del hosting, probados periódicamente.

Migración sin planificación. Cambiar de CMS sin plan de migración para URLs, redirecciones 301, contenido, imágenes, SEO, suele costar tráfico durante meses.

Subestimar la curva de aprendizaje. Headless CMS pueden ser técnicamente superiores y operativamente mucho más complejos para el equipo. La calidad del CMS depende de cuán bien lo usen las personas que publican.

La realidad de WordPress en 2026

Como WordPress sigue siendo el CMS más usado, vale la pena nombrar honestamente sus puntos fuertes y débiles en 2026:

Fortalezas:

  • Ecosistema enorme: temas, plugins, desarrolladores disponibles, comunidad activa.
  • Curva de aprendizaje suave para editores.
  • Costes iniciales bajos (especialmente con hosting compartido).
  • Documentación extensiva.
  • Casos de éxito demostrados a todas las escalas.

Debilidades:

  • Seguridad: ser dominante atrae ataques. WordPress es uno de los CMSs más atacados del mundo.
  • Performance: sin optimización seria, sitios WordPress pueden ser lentos.
  • Plugin hell: dependencia excesiva de plugins crea fragilidad.
  • Gutenberg/Block Editor (introducido en 2018): controversia continua, muchos usuarios prefieren editores clásicos como Classic Editor o page builders (Elementor, Bricks, Oxygen).
  • Cuesta escalar a sitios muy complejos sin ingeniería seria.

El futuro: WordPress.com (hosted) ha crecido. WordPress.org (auto-alojado) sigue siendo dominante en volumen. Ha aparecido inversión significativa en hacer WordPress más moderno y headless-friendly. Plataformas managed-WordPress como WP Engine, Kinsta, Pressable simplifican la operación a cambio de coste mayor.

CMS y operaciones creativas

Para una marca o agencia que produce contenido a escala, el CMS es la última milla del trabajo creativo: donde el contenido producido se publica al público. Si esa última milla es lenta, frágil o caótica, la calidad del trabajo previo se compromete. Inversamente, un buen CMS puede multiplicar el rendimiento de un buen equipo creativo.

Por eso esta decisión, aunque parezca técnica, conecta con operaciones creativas: el calendario editorial coordina qué se publica cuándo y a través de qué CMS, los flujos de aprobación idealmente integran con el CMS para que aprobación y publicación sean un solo flujo, y la producción de contenidos genera el material que el CMS distribuye.

Polimake no es un CMS — es una plataforma de operaciones creativas que coordina trabajo antes de que llegue al CMS. Studio coordina la planificación, Studio la producción, Media los activos. Cuando una pieza está lista, se publica al CMS correspondiente (WordPress, Shopify, Webflow, headless, etc.). Las dos categorías de software son complementarias, no competidoras.


Si lideras marketing, tecnología o producto y has llegado aquí buscando una respuesta sobre CMS, lo más útil que puedes llevarte de este artículo es probablemente la primera pregunta antes de la elección: ¿qué arquitectura necesita tu proyecto: tradicional, headless o hybrid?. Esa decisión filtra el universo de opciones de manera más útil que comparar features individuales. Una vez clara la arquitectura, las opciones razonables dentro de cada categoría son pocas y la elección se vuelve manejable.

Para complementar, hosting cubre la capa de infraestructura sobre la que el CMS opera, dominio cubre la capa de identidad web, y SEO cubre la disciplina cuyo rendimiento depende parcialmente del CMS elegido.

Referencias rápidas