Cómo modelar el contenido para que sobreviva al próximo rediseño
Un modelo de contenido sobrevive a un rediseño cuando sus campos describen significado y no posición. Nombres con sentido, referencias para lo reutilizable, rich text estructurado y locales decididos pronto.
Contenido
- Puntos clave
- Qué es un modelo de contenido y qué no lo es
- Por qué los campos presentacionales son los que se rompen
- Referencia o incrustación: una regla de decisión
- El rich text es una estructura de datos, no una cadena de texto
- La localización es una decisión de modelado, no un plugin
- Migrar un modelo sin reescribirlo
- Qué cambió en esta actualización
- Preguntas frecuentes
Actualizado el 30 de septiembre de 2025 — las herramientas de edición visual ya cubren el problema de previsualización que justificaba los campos presentacionales.
Un modelo de contenido sobrevive a un rediseño cuando sus campos describen qué es el contenido y no dónde aparece en pantalla. Conviene nombrar los campos por significado, guardar el rich text como dato estructurado, usar referencias para todo lo reutilizable y decidir los locales antes de que llegue el segundo idioma.
Puntos clave
- Rachel Lovinger defendió en A List Apart el 24 de abril de 2012 que cada elemento que se muestra de forma distinta merece su propio campo. Su ejemplo era el subtítulo en negrita dentro del cuerpo.
- WordPress serializa los bloques dentro de
post_contentcomo HTML con delimitadores en comentarios desde la versión 5.0, del 6 de diciembre de 2018. El contenido viaja con el marcado del editor que lo produjo. - La Jamstack Community Survey 2022 reunió cerca de 7.000 respuestas. WordPress aparecía en algunos o muchos proyectos para el 37 % de los encuestados, WordPress headless en el 22 % y Contentful en el 19 %.
- La RFC 5646, publicada por el IETF en septiembre de 2009, convierte
es,es-ESyes-419en tres etiquetas de idioma distintas y no en tres formas de escribir la misma. - Carrie Hane y Mike Atherton colocan la arquitectura de contenido antes del diseño visual en Designing Connected Content (New Riders, diciembre de 2017), que es el mismo orden que defiende este artículo.
Qué es un modelo de contenido y qué no lo es
Un modelo de contenido es el conjunto de tipos de contenido de un sistema, los campos de cada tipo y las relaciones entre ellos. Es un esquema escrito en el vocabulario del negocio y no en el de la página. Por eso empieza en las preguntas que debería hacer un brief y no en un mapa del sitio.
La prueba dura diez segundos. Léele el nombre de un campo a alguien que nunca ha visto el sitio. Si puede decir qué va dentro sin ver el diseño, el campo describe contenido; si necesita el diseño, describe una maqueta. Y la maqueta es justo lo que cambia.
Por eso la discusión sobre el CMS pesa menos de lo que parece. Un modelo limpio se mueve entre WordPress, Sanity y Contentful con un script de migración, mientras que un modelo hecho de huecos de maqueta muere en los tres. Elegir plataforma por restricciones resuelve menos de lo que se espera.
Por qué los campos presentacionales son los que se rompen
Un campo presentacional guarda una decisión que pertenece al front end. heroImageLeft, bannerVariantThree, introTextGreen: cada nombre señala una posición, una variante o un color. Los rediseños existen precisamente para cambiar posiciones, variantes y colores.
Rachel Lovinger escribió en A List Apart el 24 de abril de 2012 que “cada elemento que necesita mostrarse de forma distinta debería estar en su propio campo”. Y preguntó cómo se comportaría en un feed RSS un subtítulo en negrita dentro del cuerpo. (Content Modelling: A Master Skill)
El coste nunca aparece el día del lanzamiento. Aparece dos años después, cuando miles de entradas contienen un campo cuyo significado solo entendía la plantilla ya retirada. Migrarlo obliga a leerlo, deducir la intención y reescribirlo entrada por entrada.
Karen McGrane planteó el mismo problema en una charla que A List Apart publicó el 14 de enero de 2013. Preguntaba por qué los autores siguen pensando en qué lugar de la página vivirá su contenido. Diez años después, esa pregunta sigue separando un modelo de un maquetador.
Referencia o incrustación: una regla de decisión
Dos preguntas resuelven casi todos los casos. ¿Esto existe fuera de la página donde aparece? ¿Necesita algo más apuntar hacia ello? Un autor, un producto, una ubicación y un documento legal responden que sí, así que cada uno merece su propio tipo de documento.
La misma conclusión se alcanza por el otro lado. Conviene un tipo de documento propio siempre que el cliente vaya a añadir más elementos después, y conviene un objeto incrustado cuando los campos solo tienen sentido juntos en ese sitio concreto.
Incrustar por defecto es el fallo habitual. Si el nombre y la foto del autor se copian dentro de cada artículo, el autor deja de ser corregible. Una foto nueva obliga a una edición masiva y una errata se queda en las entradas que nadie vuelve a abrir.
Referenciarlo todo es el fallo opuesto. Cuando una llamada a la acción que aparece en una sola página se convierte en documento propio, el equipo editorial recorre cuatro pantallas para cambiar una frase.
El rich text es una estructura de datos, no una cadena de texto
El campo del cuerpo es donde los modelos mueren en silencio. Si guarda HTML, guarda también las decisiones de marcado del editor que lo generó, y todos los canales posteriores las heredan.
WordPress 5.0 publicó el editor de bloques el 6 de diciembre de 2018. El Block Editor Handbook documenta que los bloques se serializan enpost_contentcomo HTML con delimitadores del tipo<!-- wp:image -->y atributos en JSON dentro del comentario. (WordPress Developer Resources)
Ese formato es una respuesta razonable al problema de la compatibilidad hacia atrás y una respuesta pobre al problema de la reutilización. El marcado y el contenido viajan juntos, así que el segundo canal recibe las decisiones del primero.
El rich text estructurado guarda ese mismo cuerpo como un árbol: bloques, fragmentos de texto, marcas separadas del texto que anotan y elementos tipados que referencian documentos reales en lugar de marcado pegado. Renderizar a una página, a un email o a una respuesta de voz vuelve a ser una decisión de renderizado. El front end deja además de servir marcado que nadie pidió, una de las cosas que de verdad mueven el LCP.
La regla que funciona es un conjunto cerrado. Se permite una lista documentada de tipos de bloque dentro del rich text y cada uno tiene su esquema. Un bloque de “HTML libre” es una salida de emergencia, y las salidas de emergencia terminan albergando un tercio del sitio. Es el mismo argumento que convierte a los design tokens en el contrato entre diseño y código, una capa más abajo.
La localización es una decisión de modelado, no un plugin
Hay dos formas y la elección es estructural. La localización a nivel de campo mantiene un documento por pieza de contenido y guarda un valor por locale en cada campo. La localización a nivel de entrada mantiene un documento por locale y enlaza las versiones entre sí.
El nivel de campo deja la traducción junto al original y hace triviales los fallbacks, pero cada persona del equipo editorial ve todos los idiomas. El nivel de entrada permite que un equipo de mercado sea dueño de su documento y se separe del original. A cambio, responder a “¿esto ya está traducido?” pasa a ser una consulta y no un vistazo.
La RFC 5646, publicada por el IETF el 4 de septiembre de 2009 dentro de BCP 47, define las etiquetas de idioma como combinación de subetiquetas de idioma, escritura y región. Por esoes,es-ESyes-419son tres valores distintos. (RFC Editor)
La granularidad se fija antes de que exista el segundo idioma. Separar es en es-ES y es-419 más tarde obliga a decidir, entrada por entrada, a qué mercado pertenecía cada valor ya escrito.
Migrar un modelo sin reescribirlo
Un cambio de esquema es código, así que recibe el trato del código. El cambio se escribe como script de migración, se ejecuta contra una copia del dataset y se compara el resultado antes de tocar producción. Una migración que se puede repetir es una migración que alguien puede revisar.
Tres hábitos abaratan los cambios siguientes. Versionar el esquema y registrar bajo qué versión se escribió cada documento. Mantener estable el significado de un campo aunque cambie su widget. No reutilizar nunca un campo: se marca obsoleto, se añade el sustituto, se migra y se elimina.
La Jamstack Community Survey 2022, publicada por Netlify, reunió cerca de 7.000 respuestas. WordPress aparecía en algunos o muchos proyectos para el 37 % de los encuestados, WordPress headless en el 22 %, Contentful en el 19 % y Sanity en el 16 %. (Jamstack.org)
La mayoría de las organizaciones conviven con más de un sistema, así que migrar es rutina y no crisis. Es un argumento para tratar la arquitectura de contenido como un problema de operaciones con responsable y no como un entregable de proyecto.
Qué cambió en esta actualización
Contentful anunció Contentful Studio el 28 de marzo de 2024, que permite componer páginas visualmente sobre los tipos de contenido existentes. La herramienta Presentation de Sanity hace algo comparable al codificar referencias de origen en el front end. Ambas atacan la razón por la que los campos presentacionales reaparecían: el equipo editorial no veía lo que estaba escribiendo. El consejo de modelado no cambia. Se vuelve más fácil de seguir, porque la capa de composición por fin vive en una herramienta y no dentro del tipo de contenido.
Preguntas frecuentes
¿Qué es un modelo de contenido?
Un modelo de contenido es la lista de tipos de contenido de un sistema, los campos que contiene cada tipo y las relaciones entre ellos. Describe significado y no maqueta: un artículo tiene una referencia a su autor y una fecha de publicación, no una posición de hero ni una variante de banner.
¿Cómo se sabe si un campo es presentacional?
Basta con leer el nombre del campo a alguien que no ha visto el diseño. Si puede explicar qué va dentro sin la maqueta, el campo describe contenido. Si el nombre menciona una posición, un color, una columna o un número de variante, esa decisión pertenece al front end.
¿Conviene una referencia o un objeto incrustado?
Una referencia cuando el elemento existe fuera de la página y algo más puede apuntar hacia él: autores, productos, ubicaciones, documentos. Un objeto incrustado cuando los campos solo tienen sentido juntos en ese lugar concreto, como la cantidad asociada a un producto seleccionado.
¿Es mejor localizar por campo o por entrada?
Por campo se mantienen todos los idiomas en un documento y los fallbacks son simples, lo que encaja con traducción sincronizada. Por entrada cada mercado tiene su documento y margen para separarse, lo que encaja con equipos regionales autónomos. Primero se decide la granularidad de la etiqueta de idioma, porque separarla después es la parte cara.
¿Un CMS headless garantiza un modelo limpio?
No. Headless saca la plantilla de la capa de almacenamiento, pero nada impide recrear huecos de maqueta como campos. Los fallos descritos aquí aparecen en cualquier plataforma. La disciplina vive en la revisión del esquema, no en la elección de producto.
Primero los sustantivos, después las relaciones, después el esquema del rich text, y la maqueta se queda en el front end. Las etiquetas de idioma se deciden antes del segundo idioma y no después de la primera petición de traducción. Dentro de seis meses la medida honesta será contar cuántos campos obligó a migrar el siguiente rediseño. Menos de cinco significa que el modelo describía contenido; más de veinte, que describía una página.
