Qué es un layout y por qué · Astro 7

Cada página de un sitio comparte un esqueleto invisible: el mismo <html>, el mismo <head>, la misma cabecera y el mismo pie. Repetir ese armazón archivo a archivo es una deuda que crece con cada ruta nueva y que se cobra en el peor momento: cuando algo del marco cambia y hay que perseguirlo por todo el proyecto. Un layout es la respuesta de Astro: un componente cuya única vocación es ser marco, el lugar donde vive todo lo que no cambia para que cada página escriba solo lo que sí cambia.

🎯 Al terminar esta lección sabrás

Reconocer la duplicación estructural que vuelve inevitables los layouts.
Entender un layout como un componente envolvente, no como una categoría mágica del framework.
Situar el layout en la frontera entre la página y el documento HTML completo.
Discernir cuándo una pieza merece ser layout y cuándo basta con un componente normal.

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 patrón viejo, por fin bien resuelto

La idea de no repetir el armazón de cada página es casi tan antigua como la web. Antes se resolvía con inclusiones del lado del servidor —incrustar un fichero de cabecera y otro de pie en cada página— o con la herencia de plantillas de los motores clásicos, que definían un esqueleto y dejaban bloques para rellenar. Astro no inventa ni el problema ni la intención: lo que aporta es resolverlos con su propio modelo de componentes, sin un lenguaje de plantillas aparte ni directivas especiales. El layout es ese patrón de siempre, expresado con las mismas piezas que ya usas para todo lo demás.

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.

flowchart TD
P1[pagina inicio] --> L[Layout]
P2[pagina blog] --> L
P3[pagina contacto] --> L
L --> DOC[documento html completo]
DOC --> H[head compartido]
DOC --> B[body con cabecera y pie]
style L fill:#89b4fa,color:#11111b
style DOC fill:#a6e3a1,color:#11111b

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.

🖼️

Es layout

Envuelve el contenido con un <slot />, define la estructura de una página completa —o de una gran región de ella— y lo usan muchas páginas para compartir marco.

🧩

Es componente

Es una pieza acotada —un botón, una tarjeta, un buscador— que una página o un layout insertan en un punto concreto. No aspira a envolver la página entera.

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.

⚡

El layout es el principio DRY hecho estructura

Detrás de la comodidad del layout hay una idea que atraviesa toda la ingeniería del software: no repetir el conocimiento. El armazón de un documento —su <html>, su <head>, su cabecera— es conocimiento sobre cómo es tu sitio, y ese conocimiento debe vivir en un solo lugar para que cambiarlo sea cambiar un fichero, no cazar cien copias. El layout no inventa una capacidad nueva del framework; toma algo que Astro ya te daba —el componente— y lo aplica a la escala del documento entero. Ahí está la elegancia: la solución al problema más grande, la duplicación de toda una página, no es un mecanismo especial sino el mismo componente que ya usabas para un botón, apuntado hacia arriba. Un framework que hubiera respondido a los layouts con un sistema aparte —una sintaxis, unas reglas, un ciclo de vida propio— te habría obligado a aprender dos modelos y a razonar sobre su interacción. Astro responde con uno solo: todo es componente, y un layout es un componente que decidiste que fuera marco. Interiorizar esto cambia cómo lees un proyecto entero. Dejas de ver “páginas” y “layouts” y “componentes” como tres especies distintas, y empiezas a ver una sola —piezas que se envuelven unas a otras— que tú organizas por intención. Esa economía conceptual, un mecanismo que resuelve muchos problemas de escalas distintas, es la marca de un buen diseño, y es lo que hace que dominar el componente sea, sin más, dominar también el layout.

⚔️ Detecta y extrae tu marco

Abre dos páginas cualesquiera de un proyecto Astro y marca con un lápiz mental todo lo que es idéntico en ambas: verás emerger el armazón que pide ser un layout.
Crea src/layouts/Base.astro y mueve a él ese armazón común —<html>, <head>, cabecera y pie— dejando un hueco donde antes iba el contenido.
Razona por qué la carpeta src/layouts es convención y no magia: comprueba mentalmente que el layout seguiría funcionando desde src/components.
Toma un componente de tu proyecto y decide, solo por su vocación, si es marco o pieza; aplica la prueba de “envolver frente a ser colocado” y justifica en qué carpeta lo pondrías.