Astro dejó de ser “el framework de blogs estáticos” para convertirse en una plataforma de **content sites de producción**. En 2026, con **Astro 6** estable y el ecosistema alineado a Cloudflare, el salto real no es cosmético: es **dónde y cuándo se resuelve el contenido**.

## De build-time a runtime selectivo

Las Content Collections clásicas (Markdown/MDX + schema Zod) siguen siendo la fuente de verdad para proyectos, artículos y páginas i18n. El **Content Layer** generalizó loaders: local `glob`, APIs, CMS headless — siempre con validación en build.

**Live Content Collections** cierran el hueco que dolía en e-commerce, feeds y datos que cambian entre deploys: se consultan en **request time**, con el mismo contrato de tipos y sin abandonar el modelo de collections.

- SSG / prerender donde el contenido es estable (portfolio, blog indexado). - Live / SSR donde la frescura importa (stock, news, dashboards). - Islands: JS solo donde hay interactividad real.

## Por qué importa en este stack

En un monorepo Astro + TypeScript + Cloudflare:

1. **Schema único** para `projects-es/en` y `articles-es/en` evita JSON sueltos y drift entre idiomas. 2. El adapter edge permite **prerender selectivo** + Workers donde hace falta. 3. View Transitions y Server Islands bajan el costo de navegación sin rehidratar la página entera.

## Checklist práctico

- Tipar frontmatter con Zod; fallar el build si el schema no cierra. - Separar “contenido editorial” (build) de “datos vivos” (live/runtime). - Medir LCP e INP: islands mal puestos reintroducen el peso de React/Vue. - Documentar loaders: un agent o un humano debe saber de dónde sale cada collection.

**En contexto del sitio:** islands, content multiidioma y deploys edge. Astro 6 no es moda: es la forma de mantener HTML rápido por defecto y contenido tipado a escala.