Integración de CMS headless

Una integración de CMS headless se tuerce siempre en los mismos tres sitios, y ninguno es el CMS. El contenido no está tipado, así que renombrar un campo se convierte en un error de ejecución en producción. La caché está mal, así que los editores publican y esperan. Y la vista previa o no funciona o funciona volviendo dinámica cada ruta.

Qué construimos

Contenido tipado de punta a punta. El esquema del CMS genera tipos de TypeScript, y la capa de fetch parsea lo que llega en vez de afirmarlo. Un campo renombrado falla entonces en el build o en el borde con un mensaje que lo nombra, no tres componentes después como undefined is not a function.

Caché acorde a cómo trabajan los editores. El contenido se etiqueta, no se revalida por tiempo. Un webhook del CMS limpia la etiqueta de lo que cambió, y la página se actualiza en segundos sin volver dinámica la ruta. La alternativa -revalidate: 60 en todas partes- significa que los editores esperan un minuto y tu origen recibe tráfico que no necesitaba.

Preview que no te cuesta la caché. Draft mode solo en la ruta de vista previa, acotado a la sesión del editor, para que la ruta publicada siga estática para todos los demás. Los editores ven lo no publicado; los visitantes reciben el CDN.

Un modelo de bloques que aguanta. Casi todos los proyectos modelan el contenido como páginas con campos fijos, y entonces marketing pide una maquetación que el modelo no puede expresar. Nosotros modelamos bloques componibles desde el principio, con el renderizador tipado contra la unión de bloques, de modo que un bloque no contemplado es un error de compilación y no un hueco en blanco.

Qué CMS

No estamos atados a ninguno, y te diremos si el que elegiste no encaja con lo que quieres hacer, pero rara vez es la pregunta interesante. La integración es la mayor parte del trabajo y tiene prácticamente la misma forma elijas el que elijas.

Si estás migrando fuera de WordPress y lo mantienes como superficie de edición, funciona: WordPress como fuente headless con Next.js renderizando es una arquitectura legítima y a menudo el camino más barato, porque los editores conservan la herramienta que conocen.

Qué necesitamos de ti

Acceso al CMS y alguien que pueda responder "¿para qué es este campo?". Lo segundo importa más que lo primero: un modelo de contenido que refleja una plantilla vieja en lugar del contenido real es lo que encarece la reconstrucción, y merece una hora de conversación antes de escribir código.

Cómo se acota

Dénos acceso de lectura al CMS y media hora con quien pueda decir para qué sirve cada campo. Esa conversación dimensiona el proyecto con más precisión que el número de páginas.

El alcance vuelve con el modelo de contenido, confirmado o redibujado, más la lista de plantillas, el enfoque de vista previa y revalidación, y un precio. Se firma antes de empezar a construir. Cuando el modelo hay que rehacerlo, eso es una fase propia con su propia cifra, porque es la parte que duplica un proyecto en silencio si se deja implícita.

Después el desarrollo, desplegado por fases, con los editores usando la vista previa antes de que el front esté terminado.

Qué recibes

El front, la capa de contenido tipada entre él y el CMS, la vista previa funcionando para los editores, y la revalidación conectada a los webhooks del CMS para que una publicación aparezca sin que nadie vuelva a desplegar.

Lo que se subestima es el modelo de contenido. Donde hubo que rehacerlo recibe el nuevo documentado, con la migración que llevó las entradas existentes a él, porque un modelo que nadie escribió vuelve a la deriva en un año.

Cuándo se obtiene el contenido y cuánto se retiene decide si la integración resulta rápida o frágil, y es tanto una decisión sobre el modelo de contenido como sobre la caché. Un sitio movido por un CMS además genera sus propias URL, así que los canonical y el sitemap hay que producirlos, no mantenerlos. Donde el sitio ya posiciona y no puede moverse, el SEO técnico va en paralelo.