Qué es un layout y por qué

La duplicación que nadie quiere mantener

Imagina un sitio de tres páginas: un inicio, un blog y una página de contacto. Sin layouts, cada .astro debe abrir su propio <html>, declarar un <head> con la codificación, el viewport y las hojas de estilo, pintar una cabecera de navegación, envolver el contenido y cerrar con un pie. Tres páginas, tres copias idénticas de ese andamiaje. El día que cambies un enlace del menú tendrás que tocar los tres ficheros y confiar en no olvidar ninguno.

Cuando miras de cerca qué se repite, aparece siempre la misma lista, y es larga:

• La declaración del documento: el <!doctype html> y el <html> con su atributo de idioma.
• El <head> entero: codificación, viewport, favicon y enlaces a las hojas de estilo.
• La cabecera de navegación, con su logotipo y su menú de enlaces.
• El pie, con los avisos legales, los enlaces secundarios y el año en curso.
• Los estilos globales y las fuentes que carga por igual toda la página.

Esa duplicación no es un defecto estético, sino estructural. Viola el principio de una sola fuente de verdad: cuando un mismo hecho —la estructura del menú, las metaetiquetas base, el año del pie— vive copiado en muchos sitios, cada copia es una oportunidad de divergencia. Los proyectos reales no tienen tres páginas, tienen cientos, y la deuda escala con ellas hasta volverse ingobernable.

---// src/pages/contacto.astro — sin layout, todo repetido---<html lang="es">  <head>    <meta charset="utf-8" />    <meta name="viewport" content="width=device-width, initial-scale=1" />    <title>Contacto</title>  </head>  <body>    <header><nav><a href="/">Inicio</a></nav></header>    <main>      <h1>Contacto</h1>    </main>    <footer>© 2026 Mi sitio</footer>  </body></html>

Multiplica ese bloque por cada ruta del sitio y verás el problema entero: casi todo el fichero es idéntico al de al lado, y solo el interior del <main> cambia. El armazón ahoga al contenido.

Un layout es solo un componente

Aquí está la desmitificación clave: Astro no tiene un tipo especial llamado “layout”. Un layout es un componente .astro corriente que, por convención, guardas en src/layouts. Lo único que lo distingue es su intención —envolver— y una pieza que verás en la próxima lección, el <slot />, el hueco donde se inserta el contenido de quien lo use.

La carpeta src/layouts no significa nada para el compilador: podrías colocar tus layouts en src/components y funcionarían igual. La convención existe para las personas, no para la máquina. Separa las piezas que son marco de las piezas que son contenido, de modo que quien abra tu proyecto entienda el reparto de un vistazo, sin leer una línea de código.

Que un layout sea “solo un componente” no es un detalle menor: es lo que le da todo su poder. Recibe props como cualquier componente, admite <slot /> como cualquier componente, y puede importar y usar otros componentes —incluidos otros layouts—. No tienes que aprender un sistema aparte; reutilizas lo que ya sabes de componentes y lo apuntas con una intención distinta. Todo lo que descubras más adelante sobre props, slots o composición se aplica a los layouts sin excepción, porque un layout no es una cosa nueva, es un uso nuevo de algo conocido.

La anatomía compartida: html, head, body

Un documento HTML válido tiene una forma fija: un <html> raíz con su atributo de idioma, un <head> con metadatos que el usuario no ve pero el navegador y los buscadores sí, y un <body> con lo visible. El layout es el lugar natural para esa anatomía, porque es la parte más estable de todo el sitio y la que menos tiene que ver con una ruta concreta.

La división de responsabilidades es limpia y merece grabarse:

• En el layout vive lo estructural: el <html>, el <head> entero, la cabecera de navegación, el pie y los estilos globales.
• En la página vive lo particular: solo su contenido único —el <h1>, los párrafos, las secciones—, que el layout recibe y coloca en su hueco.

El <head> merece una mención aparte, porque es el caso más claro de por qué esto importa. Nada de lo que hay en él se ve en la pantalla, pero de él dependen el título de la pestaña, la codificación, el comportamiento en móvil y cómo te leen los buscadores. Es precisamente la clase de código que nadie quiere copiar a mano en cada página y que un solo error —un viewport olvidado, una codificación distinta— vuelve inconsistente. Centralizarlo en el layout es la primera victoria concreta del patrón.

Esta separación tiene nombre propio en el diseño de software: distinguir lo estructural de lo particular. El layout responde a la pregunta “¿cómo es todo documento de este sitio?”; la página responde a “¿qué dice esta ruta en concreto?”. Mezclar ambas preguntas en un mismo fichero es lo que produce la duplicación; separarlas en dos capas es lo que la disuelve.

Layout o componente: la frontera

Si un layout y un componente son técnicamente lo mismo, ¿cuándo es una pieza un layout y cuándo un componente cualquiera? La respuesta está en la vocación de la pieza, no en su sintaxis.

La frontera no siempre es nítida, y no pasa nada: como en el fondo son la misma cosa, mover una pieza de src/components a src/layouts es trivial y no rompe nada salvo un import. Lo que importa es la intención con la que la usas. Un componente que empieza siendo una simple cabecera puede crecer hasta envolver toda la página y convertirse, de hecho, en un layout. Astro no te lo impedirá ni te lo exigirá: la decisión es de diseño, no de compilador.

Un heurístico práctico ayuda a decidir sin agonizar: si la pieza tiene un <slot /> y quien la usa “vive dentro” de ella, es un layout; si la pieza se coloca “dentro” de otra cosa y no envuelve a nadie, es un componente. Envolver frente a ser colocado: esa es la prueba. Y como el coste de equivocarse es un import, conviene decidir rápido y seguir, en lugar de teorizar sobre una carpeta.