Astro Components and Layouts Explained

An Astro component is a reusable .astro file that produces part of a page or a complete page. A layout is a component used to wrap page content with a shared structure, such as the document head, navigation and footer. Understanding that relationship helps you change a template without copying the same markup across many pages.

Components are most useful where the website repeats a meaningful pattern. They should make a change easier to understand, rather than splitting every sentence into a separate file.

Start with one repeated element

Imagine a consultancy template that repeats a short contact panel at the end of every service page. Instead of pasting the panel into each page, keep one component in src/components/ContactPanel.astro:

---
interface Props {
  title: string;
  href: string;
}
const { title, href } = Astro.props;
---
<aside>
  <h2>{title}</h2>
  <a href={href}>Discuss your project</a>
</aside>

The values passed into a component are called props. This component requires a title and destination. A page can reuse its structure while choosing text appropriate to that service.

Astro’s component documentation describes props and the component script. The example above is an editing pattern, not a requirement that every template use those filenames or fields.

Import and use the component

A page can import the component and supply its values:

---
import ContactPanel from '../components/ContactPanel.astro';
---
<section>
  <h1>Process improvement consulting</h1>
  <p>Explain the service and who it helps.</p>
</section>
<ContactPanel
  title="Need help planning the work?"
  href="/contact/"
/>

This example assumes the importing page sits directly inside src/pages. A more deeply nested page needs a different relative import path. The public link, /contact/, is a website URL; the import path refers to a source file. Confusing those two kinds of path is a frequent editing mistake.

The example page has its own main heading because it is a standalone illustration. When editing an existing template, check whether its layout already supplies the page heading before adding another.

Use a layout for the page shell

A layout can wrap whatever differs between pages. For example, create src/layouts/BaseLayout.astro:

---
interface Props {
  title: string;
}
const { title } = Astro.props;
---
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <title>{title}</title>
  </head>
  <body>
    <header><a href="/">Example Studio</a></header>
    <main><slot /></main>
    <footer><a href="/contact/">Contact</a></footer>
  </body>
</html>

The slot marks where the child page’s content appears. Real production layouts usually need more metadata, navigation, styles and accessibility details. This minimal example isolates the relationship between a wrapper and its content.

Astro’s layout guide explains this composition pattern. A layout is not a separate runtime system; it is a component with a broad responsibility.

Wrap a page with the layout

A page at src/pages/about.astro can use that wrapper:

---
import BaseLayout from '../layouts/BaseLayout.astro';
---
<BaseLayout title="About Example Studio">
  <h1>About the studio</h1>
  <p>Introduce the real people and their work.</p>
</BaseLayout>

Changing the footer in BaseLayout updates the pages that use it when the site is rebuilt. A separate landing page could intentionally use another layout, so do not assume every route inherits every shared change.

Before editing a header or footer, trace the imports from one representative page. This reveals which component actually controls the visible element and helps avoid changing an unused alternative design.

Choose between props and child content

Use props for compact values such as a title, destination or image reference. Use the child content passed through a slot when a page needs a richer block of markup, such as several paragraphs and a list.

Avoid designing a component with a large number of loosely related switches simply to accommodate every possible page. If one service needs a distinct case study layout, a separate component may be clearer than many conditional variations in a generic card.

Consistency is the goal, not maximum reuse. Two sections that currently look alike may serve different editorial purposes and evolve differently.

Know where browser behaviour belongs

The component script between the opening fences is used to prepare rendering. It is not the place to attach a click handler directly to a visitor’s current document. A mobile menu or interactive filter needs an appropriate browser script or client component.

Astro’s scripts and event handling guide explains that distinction. When modifying an existing menu, preserve its keyboard behaviour and expanded state rather than replacing it with a visual toggle alone.

Check a shared edit across routes

After changing a reused component, inspect a short page, a long page and a narrow viewport. Long titles, multiple paragraphs and missing optional media reveal assumptions that a single demo page can hide.

Build the project after structural edits. Then review how to add pages to an Astro template to use these building blocks without duplicating the document shell.

The Astro template overview explains how a well organised component system contributes to a maintainable purchase.