Los archivos de la capeta /src/content

Cuando se crea un blog o una web con muchas publicaciones, no se escribe cada artículo en un archivo .astro independiente. En su lugar, se separa el contenido (los artículos) de la estructura (el diseño visual).

Para esto se utilizan archivos Markdown (.md) o MDX (.mdx), los cuales se organizan en subcarpetas dentro del directorio src/content/ (una subcarpeta por colección).

Colecciones de Contenido (Content Collections)

En Astro, las subcarpetas dentro de src/content/ se conocen como Colecciones.
Cada subcarpeta representa un grupo de contenidos del mismo tipo.


  src/content/
  ├── blog/                   ← Colección: "blog"
  │   ├── mi-primer-post.md
  │   ├── guia-astro.md
  │   └── decoracion-fiesta.md
  └── autores/                ← Colección: "autores"
      ├── gemini.md
      └── maria.md

La carpeta src/content/ es reservada en Astro.
Todo lo que allí se guarde, será procesado automáticamente mediante la API nativa de colecciones: getCollection().

Archivos en src/content/ y Frontmatter. ¿Por qué es tan vital?

El Frontmatter es el bloque de metadatos en formato YAML que se coloca al inicio absoluto de un archivo Markdown, delimitado por tres guiones medios (---) arriba y abajo.

No se muestra directamente como texto en un artículo, sino que sirve para pasarle datos estructurados a Astro sobre esa publicación.

Ejemplo de archivo .md con su Frontmatter

Extracto del archivo

¿Para qué sirven los campos del Frontmatter?

El Frontmatter es la ficha técnica del artículo. Astro lo lee y te permite usar esos datos para:

  • Indexar y listar: Usar el campo pubDate para ordenar los posts del más reciente al más antiguo.
  • SEO y Redes Sociales: Usar los campos title, description e image para generar las etiquetas meta e imágenes de previsualización (Open Graph).
  • Filtros y Paginación: Usar los campos tags o category para agrupar entradas por temas.
  • Estados: Usar un campo booleano como draft: true, para no publicar borradores en la web.

Validar el Frontmatter: src/content/config.ts y Zod

Para evitar que la web falle porque el Frontmatter de un archivo .md no sigue un estándar previamente establecido (se olvidó algún campo clave como pubDate o title o hay errores de ortografía en su escritura), Astro valida el Frontmatter creando un archivo de configuración de esquemas con su librería Zod. (ref. Content Collections y content.config.ts)

Con qué propósito realiza Astro esta validación

Cero errores silenciosos Si se crea un post en Markdown y hay un error al poner la fecha o falta un campo obligatorio, Astro avisará de inmediato en la terminal durante el desarrollo.

La conexión con DecapCMS

La conexión entre las colecciones de Astro y DecapCMS (que es un administrador de contenido desacoplado), no se hace mediante código explícito de importación, sino por sincronización de nombres de campos. El archivo de configuración de DecapCMS public/admin/config.yml actúa como la plantilla del formulario que rellena el Frontmatter de un post, y el archivo src/content/config.ts actúa como el inspector que valida que ese Frontmatter sea correcto.

Los 3 errores más comunes que rompen la conexión

  1. Diferencia de nombres (Mayúsculas/Minúsculas o Spanglish): Si en el config.yml de Decap se escribe name: "fecha" y en el src/content/config.ts se espera pubDate: z.date(), Astro dirá que falta el campo obligatorio pubDate.
  2. Formatos de fecha inseparables: Astro espera un objeto fecha válido (z.date()), por lo tanto, en Decap CMS, widget datetime, se debe formatear la fecha correctamente (habitualmente YYYY-MM-DD).
  3. Campos marcados como requeridos en Astro pero ausentes en Decap (o viceversa): Si se agrega un nuevo campo en Decap CMS, deberá agregarse con el mismo nombre en src/content/config.ts. Si el campo es opcional en DecapCMS, hay que asegurarse de marcarlo como z.string().optional() en Astro.

El mapa de conexión (para que lo tengamos presente) es el siguiente:


    El Formulario de Decap CMS
                │ 
                │ (Lee la estructura desde)
                ▼
     📁 public/admin/config.yml, quien define qué campos llena el usuario
                │  
                │ (Se genera el archivo .md con su Frontmatter)
                ▼
     📁 src/content/blog/post.md
                │ 
                │ (Se validan los campos del Frontmatter)
                ▼                        
     📁 src/content/config.ts comprueba los tipos con Zod.