El problema del rediseño accidental
Un cliente abre su panel de WordPress para actualizar una página. Quiere cambiar un párrafo. Mientras está dentro, ve un botón para cambiar el tamaño de la fuente. Lo hace más grande. Luego ve un selector de color. El encabezado ahora es color verde azulado. Añade una nueva sección usando un bloque de maquetador de páginas que no ha usado antes. Se sube una imagen desde un móvil: tiene 6.000 píxeles de ancho y 8 MB. La maquetación se rompe en móvil. Nada de esto fue intencionado.
Esto no es una hipótesis. Variaciones de ello ocurren en casi todos los sitios de WordPress con más de un editor. La filosofía de diseño de la plataforma es que más flexibilidad es mejor. La suposición es que los clientes tienen tanto la habilidad como la moderación para usar esa flexibilidad dentro de los límites del diseño original. Esa suposición suele ser errónea, no porque los clientes sean descuidados, sino porque la interfaz presenta cada opción como igual de válida.
Cuando un selector de tamaño de encabezado muestra opciones de 10px a 100px, nada en la interfaz indica qué valores son apropiados para el diseño. Cuando un selector de color muestra el espectro completo, no hay forma de saber qué valores forman parte de la paleta de marca. El CMS no distingue entre "decisiones de diseño tomadas por la persona que construyó este sitio" y "ajustes que probablemente deberías dejar en paz".
Cómo lo empeoran los maquetadores de páginas
Los maquetadores de páginas de WordPress - Elementor, Divi, WPBakery y sus competidores - amplían el problema de forma significativa. Dan a los editores la capacidad de añadir, eliminar y reordenar secciones de página, cambiar maquetaciones de columnas y modificar la estructura visual de componentes individuales.
El resultado es que el diseño de una página deja de ser algo fijo y se convierte en una variable. Cada vez que un editor abre una página, la maquetación está disponible para modificarse. Con el tiempo, las páginas se alejan del diseño original. Diferentes páginas usan diferentes espaciados, diferentes tamaños de fuente, diferentes combinaciones de color. El sitio empieza a parecer que lo construyeron varias personas distintas con preferencias estéticas incompatibles - porque en efecto, así fue.
Los maquetadores de páginas también generan HTML inestable. La salida de código de Elementor o Divi está muy anidada, depende de JavaScript y a menudo cambia entre versiones de plugin. Un sitio que se veía bien tras la última actualización podría tener problemas de maquetación tras la siguiente, sin un desencadenante predecible.
La solución parcial del CMS headless
Plataformas como Contentful, Sanity y Storyblok responden a estos problemas separando el contenido de la presentación. El CMS almacena contenido en bruto - texto, imágenes, relaciones entre tipos de contenido - y una capa frontend separada decide cómo mostrarlo.
Esto es una mejora arquitectónica significativa. Los editores ya no pueden modificar directamente la maquetación, porque la maquetación vive en el código, no en el CMS. El diseño es estable independientemente de lo que haga el editor.
La limitación es que la mayoría de las plataformas headless siguen permitiendo campos de texto enriquecido con opciones de formato, y esas opciones de formato se usan mal con frecuencia. Un campo de texto largo con negrita, cursiva, niveles de encabezado e inserción de enlaces le da a un editor muchas formas de producir una salida que se ve mal en el frontend. El contenido pegado desde Word trae su propio formato. Los estilos en línea que funcionan en un contexto se rompen en otro.
El otro problema es la complejidad. Las plataformas CMS headless están diseñadas principalmente para desarrolladores. La interfaz editorial para usuarios no técnicos varía significativamente en calidad, y configurar una plataforma headless de forma que sea genuinamente usable para un equipo sin desarrolladores requiere una inversión considerable en configuración y formación que la mayoría de los proyectos no presupuestan.
Qué resuelven realmente los campos estructurados
La alternativa es un CMS que no le da a los editores control de la maquetación en primer lugar - no porque se haya bloqueado, sino porque los campos que expone no corresponden a propiedades de maquetación. El contenido estructurado significa que el CMS sabe qué es cada pieza de contenido, no solo dónde debe aparecer en la página.
En lugar de un área de texto donde un editor escribe la sección principal, hay campos separados: un campo de titular, un campo de subtítulo, un campo de texto del cuerpo y un campo de botón CTA. Cada uno tiene restricciones específicas. El titular tiene un límite de caracteres. El campo CTA tiene un destino de enlace y una etiqueta de botón, pero ningún selector de color. El editor no puede hacer accidentalmente que la sección principal se vea diferente porque las decisiones de diseño están integradas en la estructura del campo, no son accesibles a través de la interfaz.
Un campo de subida de imagen puede imponer dimensiones, límites de tamaño de archivo y requisitos de relación de aspecto. Un campo de miembro del equipo puede tener un nombre, un cargo y una foto - pero no una biografía formateada como una maquetación de tres columnas con una cita destacada. El tipo de contenido define la estructura; el editor rellena los valores.
Así funciona Kernset. Cada tipo de contenido se define como un conjunto de campos tipados con restricciones explícitas. Los editores ven una interfaz clara y sencilla para el contenido del que son responsables. El diseño permanece coherente en cada actualización porque lo controla el código, no la interfaz del CMS. Los campos de subida y de texto pueden imponer límites sensatos antes de que el contenido llegue al sitio en vivo.
El argumento práctico a favor del contenido estructurado
El caso de negocio del contenido estructurado no depende de un compromiso filosófico con la separación de responsabilidades. Va directamente sobre los costes de soporte y la estabilidad del diseño.
Cuando un CMS da a los editores control total de la maquetación, el coste continuo de mantener la coherencia del diseño es alto. Alguien tiene que revisar las actualizaciones de contenido en busca de problemas de maquetación. Alguien tiene que reconstruir las páginas que los editores han modificado de formas que rompieron el diseño. Alguien tiene que responder a los mensajes de "el sitio parece roto" que resultan ser el resultado de una actualización de contenido bienintencionada pero mal ejecutada.
El contenido estructurado elimina la mayoría de estos costes. No porque a los editores se les impida hacer nada, sino porque el propio CMS impone las restricciones que de otro modo requerirían una revisión manual. Los editores tienen una libertad genuina dentro de los límites de lo que deberían controlar realmente. Los desarrolladores dedican tiempo a construir funciones, no a arreglar rediseños accidentales.
El resultado es un sitio que se ve igual en el tercer año que en el primero - no porque nadie lo haya tocado, sino porque cada actualización ocurrió a través de un sistema que mantuvo la estructura de la que depende el diseño.
¿Quieres un CMS que tu equipo pueda usar sin estropear nada?
Kernset da a los editores exactamente el control que necesitan - campos estructurados, restricciones claras, sin caos de maquetación.
Solicitar una demo gratuita →