Astro no obliga a elegir entre mantener todos los textos en el repositorio o volver a WordPress. Hay un tercer camino útil cuando el frontend necesita control y quien publica contenido necesita un panel: Astro para la web y Sanity como CMS desacoplado.
No lo elegiría para cualquier proyecto. Añade una plataforma, un modelo de datos, consultas y un flujo de publicación que alguien tiene que entender. A cambio, evita entregar a una persona no técnica una web rápida que solo puede actualizar llamando al desarrollador.
Este portfolio no necesita Sanity
El contenido de este sitio vive en MDX y Content Collections. Me encaja porque escribo los artículos, controlo el repositorio y una publicación forma parte de mi proceso de desarrollo. Los textos bilingües, las rutas y los metadatos se revisan junto al código.
Esa elección no sirve para todos los casos. La página de servicios deja claro que las webs que entrego ahora no incluyen un panel de edición. Si un negocio necesita cambiar servicios, publicar noticias o revisar textos cada semana sin tocar un repositorio, ese flujo deja de ser cómodo muy rápido.
Ahí valoraría Sanity. No para hacer que Astro parezca más completo, sino porque hay una necesidad editorial concreta.
Qué cambia Sanity
Un CMS es un sistema para gestionar contenido desde un panel. Cuando se dice que es headless, significa que ese panel no incluye la web pública que ve una visita. Guarda y organiza textos, imágenes y otros datos, pero deja que otra aplicación decida cómo mostrarlos. En este caso, Sanity sería el lugar donde se edita y Astro el que construye las páginas que recibe el navegador.
Sanity es un CMS headless. El contenido se edita en su Studio y Astro consulta los datos para renderizar la web. El panel y la presentación pública no comparten tema ni plantillas como ocurre habitualmente en WordPress.
La separación permite definir qué puede editar una persona. Un artículo puede tener título, resumen, slug, fecha, imagen, cuerpo y campos SEO. Una página de servicio puede tener las secciones y llamadas a la acción que necesita sin convertirse en un documento de texto libre donde cabe cualquier cosa.
Eso es lo que me interesa de este enfoque. Un CMS no solo ofrece un lugar donde escribir. Obliga a decidir qué información existe y cómo se relaciona. Si el modelo está bien planteado, el editor no necesita saber HTML ni tocar componentes para publicar. Si está mal planteado, se acaba creando un panel lleno de campos que nadie entiende.
Sanity ofrece una integración oficial para Astro y usa GROQ para consultar los documentos. GROQ es el lenguaje de consultas de Sanity. Sirve para pedir exactamente los documentos y campos que necesita una página, como los tres últimos artículos con su título, fecha y URL. Se parece más a describir los datos que quieres recibir que a recorrer documentos uno por uno desde el frontend.
Astro conserva el control sobre HTML, rutas, componentes, CSS y JavaScript. Astro describe Sanity como un CMS centrado en contenido estructurado, y esa es la diferencia relevante frente a resolver cualquier página con un constructor visual.
Cuándo lo elegiría antes que WordPress
WordPress sigue siendo una decisión buena cuando el proyecto necesita su ecosistema. WooCommerce, reservas, membresías, plugins concretos o un equipo que ya trabaja en WordPress son razones suficientes para no cambiar de herramienta por moda.
Elegiría Astro y Sanity cuando el problema principal fuera gestionar contenido estructurado con un frontend a medida. Por ejemplo, una empresa que publica casos de estudio y artículos, una web de servicios que cambia con frecuencia o una marca con varias páginas que comparten autores, categorías, imágenes y bloques reutilizables.
No elegiría Sanity por ser “más moderno”. Es otra distribución de responsabilidades:
- WordPress reúne CMS, frontend y extensiones en una misma aplicación.
- Sanity guarda y organiza el contenido. Astro decide cómo se convierte en una web pública.
La segunda opción da más libertad al desarrollador, pero también le deja más decisiones. Formularios, redirecciones, analítica, caché o una funcionalidad comercial no aparecen por instalar Sanity. Hay que diseñarlos, integrarlos y mantenerlos.
Lo que ganas y lo que añades
Quien edita trabaja desde un panel, mientras que el frontend puede seguir siendo una web estática ligera. Los datos se pueden reutilizar en varias páginas sin copiar el mismo texto en distintos archivos. También se pueden preparar borradores, permisos y un Studio adaptado al vocabulario del proyecto.
La contrapartida no es pequeña:
- Hay que diseñar y mantener los esquemas de contenido.
- Hay que aprender GROQ y comprobar qué datos recibe cada componente.
- Hay otra cuenta, permisos y un servicio externo del que depende el proyecto.
- Una publicación estática necesita un nuevo build para verse en la web.
- Las previsualizaciones y la edición visual añaden complejidad y requieren renderizado en servidor en Astro.
Sanity documenta que una web Astro estática consulta los datos al construir y necesita un webhook que lance el despliegue después de publicar. Las páginas con renderizado en servidor reciben cambios al cargar, pero pasan a depender de la API en cada petición. La elección depende de cuánto cambia el contenido y de quién lo publica, no de la herramienta que tenga mejor marketing.
Cómo plantearía la integración
Antes de instalar nada, empezaría por preguntas que no tienen que ver con código. Quién va a editar, qué tipo de contenido va a crear, qué partes nunca deben cambiarse desde el panel y con qué rapidez debe aparecer una publicación en la web.
Con esas respuestas, el primer modelo de Sanity puede ser tan pequeño como un tipo para artículos:
export default defineType({
name: 'post',
title: 'Artículo',
type: 'document',
fields: [
defineField({ name: 'title', title: 'Título', type: 'string' }),
defineField({ name: 'slug', title: 'URL', type: 'slug', options: { source: 'title' } }),
defineField({ name: 'publishedAt', title: 'Fecha', type: 'datetime' }),
defineField({ name: 'body', title: 'Contenido', type: 'array', of: [{ type: 'block' }] }),
],
})Después añadiría la integración oficial. Para una web estática, Sanity recomienda usar useCdn: false durante el build para consultar el contenido publicado más reciente:
import { defineConfig } from 'astro/config'
import sanity from '@sanity/astro'
export default defineConfig({
integrations: [sanity({
projectId: 'tu-project-id',
dataset: 'production',
apiVersion: '2026-03-01',
useCdn: false,
})],
})La integración expone un cliente para las páginas de Astro. En un listado pediría solo los campos que necesita la tarjeta, no documentos completos por costumbre:
---
import { sanityClient } from 'sanity:client'
const posts = await sanityClient.fetch(`
*[_type == "post" && defined(slug.current)] | order(publishedAt desc){
title, "slug": slug.current, publishedAt
}
`)
---Para rutas estáticas, getStaticPaths() consulta los documentos y genera una página por slug durante el build. Si una consulta recibe un slug u otro dato variable, usaría parámetros de GROQ en lugar de interpolar cadenas. El cliente los sanea y evita construir consultas con datos sin controlar.
El último paso no es opcional. Configuraría un webhook de Sanity hacia el build hook del hosting y probaría el recorrido entero: publicar, recibir el webhook, generar la web y comprobar la URL final. Sin esa prueba, el panel puede decir que algo está publicado mientras la web sigue mostrando la versión anterior.
La decisión sigue siendo de mantenimiento
Para una landing que cambia dos veces al año, Sanity probablemente es más sistema del necesario. Para este portfolio, MDX sigue siendo más directo. Para un negocio con publicación frecuente y personas no técnicas editando, Sanity puede evitar una dependencia diaria del desarrollador sin obligar a usar WordPress como frontend.
No usaría esta combinación solo porque “Astro CMS” sea una keyword. La usaría si el proyecto necesita un panel de contenidos y, al mismo tiempo, una interfaz a medida que pueda mantenerse con criterios claros de rendimiento, accesibilidad y SEO.
Si estás valorando una web con Astro y necesitas decidir cómo se editará después de publicarla, puedes ver cómo planteo los proyectos web. El CMS, los responsables del contenido y el mantenimiento deben entrar en la propuesta antes de empezar a desarrollar.