Sanity CMS: cómo funciona y cuándo lo usamos

Buena parte de las webs que construimos estos últimos años llevan Sanity detrás. Así que esta guía es de parte: lo conocemos bien, lo usamos y sabemos dónde aprieta. Precisamente por eso también te vamos a contar cuándo no lo montaríamos.

Sanity es una plataforma de contenido estructurado que combina un almacén de documentos, APIs y un entorno de edición configurable. No entrega una web terminada. Entrega la capa editorial que un frontend consulta.

¿Cuándo compensa? Cuando el contenido tiene relaciones, varios formatos o una experiencia pública que no debe depender de una plantilla. Hay proyectos donde sería matar moscas a cañonazos. Sí, una agencia que usa Sanity puede decir eso sin que se apague el servidor.

Qué piezas forman Sanity

Tres: Content Lake, Sanity Studio y las APIs de consulta. Cada una con su responsabilidad.

Content Lake almacena documentos JSON estructurados y relacionados, como explica la documentación oficial de Content Lake. Studio es la aplicación de edición donde se definen esquemas, validaciones y flujos. GROQ permite consultar y transformar los documentos para entregar al frontend solo los datos necesarios.

El frontend puede estar hecho con Astro, Next.js o lo que el proyecto pida. Sanity no te casa con ningún framework visual.

Cómo se modela el contenido

Aquí está la decisión que importa de verdad, mucho más que el aspecto del panel. El modelado representa entidades del negocio y sus relaciones, no páginas cerradas. Un servicio puede relacionarse con ubicaciones, sectores, personas, preguntas y casos.

¿Y si todo se modela como un bloque de texto genérico? La plataforma seguirá funcionando, pero habrás pagado un CMS estructurado para usarlo como un Word con API.

Nuestras preguntas de arranque: qué información se repite, qué cambia por mercado, quién la mantiene y dónde debe aparecer. Después llegan los tipos, los campos, las referencias y las validaciones.

Cómo funciona la publicación

Sanity separa documentos publicados, borradores y versiones mediante identificadores y perspectivas de consulta. Producción puede pedir solo contenido publicado y una previsualización puede resolver los borradores como si ya estuvieran activos, tal y como recogen las perspectives y previsualización en Sanity.

La previsualización no aparece por arte de magia: hay que conectarla al frontend, resolver referencias y proteger el acceso a contenido no publicado.

También conviene decidir quién publica, quién revisa y qué pasa cuando varios documentos relacionados cambian a la vez.

Qué ventajas aporta en un proyecto real

Las que nacen del modelo y de la implementación, no del logo:

• Un dato se mantiene en un documento y se reutiliza en varios destinos.
• Las referencias conectan contenidos sin copiar campos.
• Las validaciones evitan combinaciones incompletas antes de publicar.
• El Studio puede ordenar vistas y acciones según el flujo editorial.
• GROQ entrega proyecciones distintas para web, app o herramientas internas.
• El frontend evoluciona sin trasladar el contenido a otra plantilla.

La comparación con un CMS tradicional está en qué es un CMS headless.

Qué límites añade

Los honestos: desarrollo, integración y mantenimiento entre el CMS y el frontend. Un equipo sin soporte técnico no obtiene una web completa instalando un tema.

Hay que construir componentes, consultas, previsualización, caché, manejo de errores y despliegue. Y revisar cuotas, roles y precios según el uso real, porque los planes cambian.

¿El contenido es portable? Como datos, sí. Pero migrarlo a otro sistema exige transformar modelos, referencias y activos. «API first» no significa «coste de salida cero».

Sanity frente a WordPress

No son una escala de moderno a antiguo. Sanity encaja cuando contenido y presentación necesitan evolucionar por separado. WordPress encaja cuando el proyecto aprovecha su sistema integrado y su ecosistema.

La elección completa, con sus matices, está en WordPress o web a medida.

Por qué lo combinamos con Astro

Porque separan edición y presentación con responsabilidades claras. Sanity mantiene contenido y relaciones. Astro renderiza páginas y añade JavaScript solo donde la interacción lo necesita.

Esta combinación nos deja controlar el HTML, las imágenes, el rendimiento y el sistema visual. ¿Garantiza una web rápida? No. Un frontend mal construido desperdicia cualquier ventaja. La otra mitad del stack la contamos en cómo funciona Astro.

Cuándo no elegiría Sanity

Si el contenido es mínimo, el diseño sigue un patrón estándar y no hay nadie que mantenga la integración, no lo montaríamos. Tampoco si una plataforma especializada ya resuelve mejor el proceso principal.

Nuestra prueba favorita antes de decidir: una tarea editorial real. Crear un servicio, relacionarlo con un caso, previsualizarlo y publicarlo. La demo debe enseñar el trabajo cotidiano, no el formulario más bonito.

En nuestros proyectos web a medida Sanity entra cuando su estructura resuelve un problema concreto. La tecnología llega después del modelo de contenido. Nunca antes.