Astro: valida el frontmatter antes de que te rompa una página
Tip práctico para validar el frontmatter de contenidos en Astro con Zod y evitar que una entrada mal escrita rompa el build o el SEO.

Cuando una web crece a base de artículos, proyectos, productos o fichas de servicios, el problema no suele ser escribir Markdown. El problema aparece cuando un campo cambia sin querer: una fecha mal puesta, una categoría inventada, una descripción demasiado corta o una imagen con el nombre equivocado.
En Astro esto se puede controlar bastante bien con Content Collections y un esquema de Zod. La idea es sencilla: en vez de confiar en que cada archivo esté perfecto, defines qué campos debe tener cada contenido y de qué tipo son. Si algo no cuadra, el build falla con un error claro antes de subirlo a producción.
Un ejemplo para una colección de tips podría ser:
import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';
const tips = defineCollection({
loader: glob({ base: './src/content/tips', pattern: '**/*.{md,mdx}' }),
schema: z.object({
title: z.string(),
description: z.string().min(120).max(170),
date: z.coerce.date(),
category: z.enum(['SEO', 'WordPress', 'PrestaShop', 'Astro', 'IA']),
image: z.string(),
imageAlt: z.string(),
imageSource: z.string().url().optional(),
}),
});
export const collections = { tips };Esto parece un detalle técnico, pero para una web real tiene impacto directo. La metadescripción mantiene una longitud razonable, la categoría no se convierte en un cajón desastre, las fechas se pueden ordenar bien y las plantillas reciben datos previsibles. Menos sorpresas en el listado, en la ficha y en las etiquetas Open Graph.
Mi recomendación práctica: si tu web en Astro tiene más de diez contenidos manuales, no esperes a que falle algo. Crea o revisa src/content.config.ts y convierte tus normas editoriales en validaciones. No hace falta empezar con un esquema enorme; empieza por los campos que más daño hacen si se rompen: título, descripción, fecha, categoría e imagen.
También merece la pena añadir límites. No basta con decir que description es un texto. Si esa descripción se usa para SEO, ponle un mínimo y un máximo. Si category solo puede tener ciertos valores, usa z.enum(). Si un campo es opcional, déjalo claro con .optional() para no mezclar ausencias intencionadas con descuidos.
El beneficio no es “tener TypeScript bonito”. El beneficio es publicar con menos miedo. Astro te avisa en local, el despliegue se para si algo viene mal y el contenido deja de depender de acordarte de todas las reglas cada vez que escribes una entrada.
Fuentes