WordPress mueve hoy más del 41% de todos los sitios web del planeta. Con esa responsabilidad encima, el editor por defecto no puede ser algo que nueve millones de instalaciones desactiven en cuanto pueden. Este artículo no es un desahogo: es un repaso de la documentación disponible —toda ella pública, casi toda escrita por los propios protagonistas— sobre cómo Gutenberg llegó donde llegó y por qué creo que rectificar sigue siendo posible.
Llevo más de diez años trabajando con WordPress a diario. He maquetado con WPBakery, con Avada, con Divi y con Elementor. Tengo criterio formado sobre cada uno y sé distinguir entre «esto no me gusta» y «esto está mal diseñado». Lo que sigue pertenece a la segunda categoría, y no lo digo yo solo.
El malentendido de origen: Gutenberg no competía contra Elementor
La primera cosa que hay que entender —y que explica casi todo lo demás— es que Gutenberg nunca se diseñó para ganarle a los maquetadores visuales de WordPress. Se diseñó pensando en Wix, en Squarespace y en Medium.
La crónica de LWN sobre el fork ClassicPress lo resume con precisión: en 2017 Matt Mullenweg anunció que el foco del año sería crear una nueva experiencia de creación de páginas y entradas, con el objetivo de que construir sitios en WordPress no exigiera recurrir a HTML a medida, shortcodes ni «mystery meat» —funcionalidades que los desarrolladores conocían pero que el usuario que solo quería escribir jamás encontraba. TinyMCE servía para maquetaciones simples, pero WordPress estaba viendo cómo Wix y Squarespace ofrecían otra cosa.
Aquí aparece la fractura que la comunidad detectó de inmediato. Un comentario que se repitió mucho en 2018, y que sigue siendo válido en 2026, lo formuló así: Squarespace y Wix son competidores de WordPress.com, no de WordPress.org. Es decir, se rediseñó el corazón del software libre que usa media web para resolver un problema de posicionamiento comercial de una plataforma concreta.
No es una teoría conspirativa. Es una lectura razonable de los objetivos declarados por el propio proyecto.
El documento fundacional: Gutenberg, or the Ship of Theseus
Si alguien quiere entender Gutenberg de verdad, tiene que leer el texto que Matías Ventura publicó en 2017. Ventura es el arquitecto técnico del proyecto y hoy Head of Architecture en Automattic. Ese post es la fuente primaria.
Su diagnóstico es sólido y comparto buena parte: mucha gente se pelea con WordPress a la hora de expresarse, de componer entradas con medios ricos, de conseguir que su sitio se parezca a la demo del tema que compró. Existe una desconexión real entre lo que editas en un campo perdido del administrador y lo que acaba viéndose en el sitio.
Pero hay una frase en ese texto que, releída en 2026, lo explica todo. Ventura describe el objetivo de Gutenberg como dar a los desarrolladores una forma de definir y proteger el marcado estructural mientras el usuario edita la información de manera intuitiva.
Léase despacio: el bloque es, ante todo, una estructura de datos. La interfaz vino después. Elementor hace exactamente lo contrario: primero resuelve la experiencia de quien maqueta, y los datos que salgan como puedan.
Ahí está la diferencia de filosofía. Y ahí está también el motivo por el que WordPress no quiso «copiar a Elementor»: no era su problema. Su problema era la portabilidad del contenido.
La confesión que casi nadie ha leído
En WordCamp Europe 2018, Ventura concedió una entrevista a WP Tavern en la que reconoció algo notable. Dijo que deberían haber puesto más esfuerzo en aclarar qué entendían por «el editor»: cuando Mullenweg anunció que se centrarían en el editor, la comunidad de WordPress entendió que hablaban de TinyMCE, cuando la intención desde el primer día era rediseñar toda la interfaz de edición.
Es una admisión enorme. El lead técnico del proyecto reconociendo, con el trabajo ya casi terminado y a meses de entrar en el core, que durante dos años la comunidad entendió mal el alcance de lo que se estaba construyendo. Y que la culpa de ese malentendido fue del proyecto, no de la comunidad.
Cuando un equipo comunica mal durante dos años, la retroalimentación que recibe también está mal calibrada durante dos años. Los que protestaban protestaban por lo que creían que era, y los que respondían respondían por lo que sabían que iba a ser. Un diálogo de sordos con calendario de release encima.
La prueba de fondo: el muro de React
Aquí llegamos al documento más duro de todos, y el que sostiene la parte central de mi argumento.
El 9 de octubre de 2018, dos meses antes de que Gutenberg entrara en el core con WordPress 5.0, Rian Rietveld dimitió como responsable del equipo de accesibilidad de WordPress y publicó por qué. Es un texto sereno, sin acritud, y demoledor.
Los puntos que importan:
- El código de Gutenberg resultaba difícil para todo el equipo de accesibilidad, porque nadie en ese equipo era desarrollador de React. Solo podían testear, documentar lo que fallaba y esperar que algún desarrollador lo recogiera.
- No había en la comunidad ningún desarrollador de React con experiencia en accesibilidad, y ningún experto externo dispuesto a trabajar gratis en ello.
- Funcionalidades ya testeadas, corregidas y aprobadas volvían a romperse en fases posteriores del desarrollo.
- Funcionalidad nueva —cita el selector de fechas— se implementaba sin pasar antes por pruebas de teclado.
Esto es lo que yo sospechaba desde fuera, dicho desde dentro y por escrito: la elección de stack levantó un muro que dejó fuera del proyecto a la comunidad que podía haber corregido el rumbo. WordPress es un ecosistema PHP con veinte años de conocimiento acumulado. Gutenberg es una SPA de React. Los contribuidores veteranos, que eran precisamente los que habían aprendido a base de golpes qué necesita un usuario real, se quedaron mirando desde la acera.
Yo he sido programador. He visto gente brillantísima construir sistemas impecables por dentro que solo entiende quien los escribió. No es mala fe: es un sesgo profesional muy común. Cuando además blindas técnicamente el proyecto de forma que solo un perfil concreto puede tocarlo, el sesgo deja de tener corrector.
La auditoría que tuvo que pagar la comunidad
La consecuencia directa de aquella dimisión fue que WPCampus —una comunidad de profesionales de WordPress en el ámbito universitario— encargó por su cuenta una auditoría de accesibilidad independiente de Gutenberg, adjudicada finalmente a la consultora Tenon y publicada en 2019. El motivo era muy concreto: el riesgo legal que asumían las instituciones sujetas a la Section 508 estadounidense si actualizaban a WordPress 5.0.
Detengámonos un segundo en lo que eso significa. Una comunidad de usuarios tuvo que pagar de su bolsillo una auditoría externa del editor por defecto de su propio CMS porque no se fiaba, y porque su exposición legal era real. No conozco muchos precedentes de esto en software libre de primera línea.
El fork y el voto silencioso
La fricción acabó produciendo un fork: ClassicPress, nacido en 2018 con la promesa de mantener la experiencia de publicación previa a WordPress 5.0. Sigue vivo, con gobernanza propia y una fundación sin ánimo de lucro detrás. Y con un presupuesto anual, según recoge LWN, inferior a 2.000 dólares. Sin empresa detrás y sin desarrolladores pagados.
Ese dato es interesante porque mide el descontento organizado, que es minúsculo. Pero el descontento real se mide en otro sitio, y ahí las cifras son otras.
El plugin Classic Editor, cuya única función es desactivar Gutenberg, supera los nueve millones de instalaciones activas según datos de marzo de 2026. Su soporte oficial se ha prorrogado varias veces y hoy alcanza como mínimo el final de 2026, previsiblemente mientras siga haciendo falta.
Ocho años después del lanzamiento. Nueve millones de sitios. Creciendo, no decreciendo. Eso no es nostalgia de cuatro veteranos: es un referéndum permanente que el proyecto lleva casi una década perdiendo y prefiere no leer.
Añado el contraplano: Elementor está presente hoy en torno al 13% de todos los sitios web del mundo —no de los WordPress, del total de la web. Un plugin de terceros que resuelve el problema que el core decidió no resolver, con esa penetración, es un veredicto de mercado bastante inequívoco.
Lo que Gutenberg sí hace bien (y hay que reconocerlo)
Si este artículo se quedara aquí sería un panfleto, y los panfletos no convencen a nadie que no estuviera ya convencido. Hay tres argumentos a favor de los bloques que son buenos y que un maquetador visual clásico no puede rebatir:
1. Portabilidad del contenido
Elementor guarda el layout serializado en postmeta. Desactívalo y te quedas con una entrada vacía o con residuo ilegible. Divi y WPBakery, con sus shortcodes, más de lo mismo. Gutenberg guarda HTML plano con comentarios delimitadores dentro de post_content: desactívalo y sigues teniendo HTML válido y legible.
Y esto no fue casualidad, fue requisito de diseño explícito. Ventura lo formula en el texto de 2017: poder empezar a usar Gutenberg sin perder acceso al contenido —poder abrirlo en otros editores— y sin cambiar cómo se renderiza el documento. Le doy toda la razón. El lock-in de los maquetadores es un problema serio del que casi nadie habla hasta que le toca migrar un sitio ajeno.
2. Peso del marcado
Los maquetadores visuales generan anidamientos de div considerables. Los bloques nativos, no. En Core Web Vitals eso se nota.
3. El argumento de 2026: la IA
Este es el que menos se ha discutido y el que más va a pesar. El propio Ventura lo señala al hablar del constructor con IA de WordPress.com: los bloques y los patrones estructuran el contenido de forma que tanto los usuarios como la IA pueden manipularlo con facilidad.
Es rigurosamente cierto. Un post_content de Elementor es opaco para un modelo de lenguaje. Uno de bloques es parseable, direccionable y modificable con precisión quirúrgica. Quien trabaje con generación y edición automatizada de contenido —yo lo hago a diario— sabe que esa diferencia no es menor. Es enorme.
Dicho de otro modo: la apuesta estructural de Gutenberg era la correcta. El problema nunca fue el bloque. El problema es la caja donde te obligan a manipularlo.
El diagnóstico, en una línea
WordPress optimizó la estructura de datos y dio por hecho que la experiencia de edición llegaría sola.
Ocho años después la estructura de datos es buena —realmente buena, y cada vez más pertinente— y la experiencia de edición sigue siendo el motivo por el que nueve millones de sitios instalan un plugin para apagarla.
Porque a nivel de uso diario, los reproches son concretos y no se han resuelto:
- Reordenar bloques arrastrando en el lienzo es frustrante e impreciso. Funciona razonablemente en la Vista de Lista, que está escondida y que la mayoría de usuarios no descubre nunca.
- El modo pantalla completa activado por defecto secuestra el administrador y desorienta a quien lleva quince años trabajando en él.
- Los ajustes están repartidos entre la barra superior, la barra flotante del bloque, la barra lateral de documento y la de bloque, con jerarquías que cambian según el contexto. Encontrar un ajuste concreto es una búsqueda, no un gesto.
- Las metaboxes clásicas quedaron degradadas a ciudadanos de segunda, arrinconadas debajo de todo.
Nada de esto es irresoluble. Todo esto es diseño de interacción, no arquitectura.
La propuesta: Gutenberg 2.0, o un editor nuevo
Y aquí es donde quiero llegar. Rectificar es de sabios, y WordPress está en una posición inmejorable para hacerlo, porque la parte difícil ya está construida y funciona.
No hace falta volver al editor clásico. Yo no lo pido y sería absurdo pedirlo: el mundo se ha movido y el modelo de bloques es superior como cimiento. Lo que hace falta es una segunda capa, y hay dos caminos:
Camino A — Gutenberg 2.0. Mismo formato de datos, misma arquitectura de bloques, interfaz rehecha desde cero con investigación de usuarios real y con criterios de diseño de interacción, no de ingeniería. Ajustes agrupados por lógica de tarea, no por origen técnico. Reordenación fiable por defecto. Sin secuestro de la interfaz del administrador. Con pruebas de accesibilidad antes de implementar, no después. Y con una vía de contribución que no exija dominar React para poder opinar sobre usabilidad.
Camino B — un editor visual nuevo sobre el mismo formato. Aquí está la belleza de la decisión estructural que WordPress tomó bien: como el contenido es HTML con delimitadores en post_content, se puede construir otra interfaz encima sin romper nada. Nada impide que exista un editor visual alternativo, oficial o no, que lea y escriba bloques nativos con una experiencia tipo Elementor. El formato lo permite. Lo único que falta es la decisión de hacerlo.
Personalmente me inclino por el camino B, porque no exige que nadie admita públicamente que se equivocó —que es siempre el mayor obstáculo político en estos casos— y porque la competencia entre interfaces sobre un formato común es exactamente lo que hizo grande a WordPress en su día. Además usando la IA como herramienta el desarrollo será muchísimo más rápido que con la programación tradicional.
Por qué esto es obligatorio, no opcional
Y termino con el argumento que para mí lo justifica todo.
Cuando arrancó Gutenberg, WordPress movía en torno al 25% de la web y ya se discutía si era legítimo tomar una decisión de ese calado sin consultar a los usuarios. Alguien lo escribió entonces con toda la razón: antes de tomar una decisión que afecta a la cuarta parte de las webs de internet, lo mínimo habría sido un estudio de mercado con los usuarios existentes. Nadie preguntó a nadie si el editor le parecía usable.
Hoy la cifra ronda el 41-42% de todos los sitios web del mundo, según W3Techs. Cerca del 60% de todo lo que usa un CMS. El competidor más cercano, Shopify, anda por el 5%.
Con esa cuota, el editor por defecto de WordPress no es un producto: es infraestructura pública de facto. Y una infraestructura que casi la mitad de la web utiliza no puede permitirse que su interfaz principal sea motivo de nueve millones de desactivaciones, de un fork, de una dimisión pública en el equipo de accesibilidad y de una auditoría externa financiada por los propios usuarios.
Añado un dato que debería encender alguna alarma: esa cuota ha empezado a erosionarse lentamente —del 43,2% en diciembre de 2025 al 41,5% en julio de 2026, según W3Techs—, y lo que crece no es un CMS rival, sino la categoría «ninguno»: sitios estáticos, frameworks de frontend y webs generadas por IA que no dejan huella de WordPress. La comodidad de crear ha dejado de ser un terreno donde WordPress gane por defecto.
WordPress se lo ganó todo siendo la herramienta que cualquiera podía usar sin pedir permiso a un programador. Esa promesa sigue siendo la mejor que tiene. Solo hay que volver a cumplirla.
Rectificar es de sabios. Y ocho años es tiempo de sobra para haber escuchado.
Fuentes
- Matías Ventura, Gutenberg, or the Ship of Theseus (2017) — documento fundacional del proyecto.
- WP Tavern, entrevista a Matías Ventura (WordCamp Europe, 2018).
- Rian Rietveld, I have resigned as the WordPress accessibility team lead. Here is why. (octubre 2018).
- WP Tavern, cobertura de la dimisión y de la auditoría de WPCampus.
- WPCampus, auditoría de accesibilidad de Gutenberg realizada por Tenon (2019).
- LWN.net, ClassicPress: WordPress without the block editor.
- WP Tavern, ClassicPress: Gutenberg Not Included (2018).
- WordPress.org, plugin Classic Editor — datos de instalaciones activas y estado del soporte.
- SiliCodeValley, Gutenberg: Estado del Arte (2018) — análisis crítico contemporáneo en español.
- W3Techs — datos de cuota de mercado de CMS, 2026.
