Astro Content Collections for Website Templates

Astro content collections organise groups of entries, such as articles, products or case studies, so a template can query them consistently. A collection can validate metadata before publication and feed both individual pages and listings. It does not automatically create public routes or provide a visual editing dashboard.

The example here uses the Astro 5 Content Layer pattern with a glob loader and src/content.config.ts. Check the version in your template before adapting it, especially if its existing collection setup follows an older convention.

Start with the content model

Decide what each entry must contain before adding a large batch of files. For an article library, a useful small model might include a title, short description and publication date. Other fields should serve a real display or editorial purpose.

Use a date for a publication date and a boolean for a featured flag. Storing everything as a string makes validation less useful and can lead to inconsistent filtering later.

Also decide which values belong in the body. A long article should not become one enormous frontmatter field just because the listing needs a short summary. Keep the summary and article body distinct.

Define a collection

For this example, create src/content.config.ts:

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const articles = defineCollection({
  loader: glob({
    pattern: '**/*.md',
    base: './src/content/articles',
  }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    publishedDate: z.coerce.date(),
  }),
});

export const collections = { articles };

If the template already has collections, add to its existing configuration instead of replacing the file and losing the others. The Astro 5 collection guide documents this loader and schema arrangement.

The schema catches missing or incorrectly typed fields. It cannot establish whether a statement is accurate, an image is licensed or an article answers its intended question. Editorial checking remains a separate responsibility.

Add a representative entry

Create src/content/articles/planning-a-service-page.md:

---
title: "Planning a service page"
description: "The information a customer needs before enquiring."
publishedDate: 2026-10-19
---

Explain the service in a short opening paragraph.

## Who the service is for

Describe the relevant customer and situation.

Use this small entry to establish the pipeline before importing dozens of articles. Test punctuation, dates and multiline text that resemble your real content. Copying a valid frontmatter structure is safer than fixing the same syntax mistake across a large batch later.

Choose filenames intentionally. In a simple flat collection, the filename contributes to the entry identifier. Do not assume an arbitrary slug field changes the public URL unless your route code explicitly uses that field.

Generate article pages

For a static site, src/pages/articles/[id].astro could contain:

---
import { getCollection, render } from 'astro:content';

export async function getStaticPaths() {
  const entries = await getCollection('articles');
  return entries.map((entry) => ({
    params: { id: entry.id },
    props: { entry },
  }));
}

const { entry } = Astro.props;
const { Content } = await render(entry);
---
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>{entry.data.title}</title>
  </head>
  <body>
    <main>
      <h1>{entry.data.title}</h1>
      <Content />
    </main>
  </body>
</html>

This intentionally minimal page assumes flat identifiers without slash segments. Use an appropriate rest route and routing strategy for nested entries. In an existing template, keep the real article layout, metadata and styles instead of substituting this demonstration document.

Build a listing deliberately

A collection page should define its sorting and visibility rules. An editorial library might sort newest first, exclude draft entries and paginate longer lists. Each behaviour needs explicit implementation; a folder of Markdown files does not supply it automatically.

Think through ties and missing values. If two articles share a date, a secondary title sort can make the listing predictable. If a draft flag is added, apply it consistently to both listings and generated routes.

The page creation guide explains why publishing a content file and making it discoverable are separate tasks. A valid page can still be difficult to find if nothing links to it.

Decide whether related entries are selected manually, by category or through another clear rule. Manual relationships provide editorial control but need validation when files are renamed. Category relationships are easier to automate but can produce weak recommendations if categories are too broad.

Check public URLs rather than linking to source filenames. A link to /articles/planning-a-service-page/ should resolve to the route your project actually generates.

Maintain the collection as the site grows

Record field meanings, required values and the route convention in a short editorial note. A new maintainer should know whether a date represents publication or revision and whether a category label affects navigation.

After changing the schema, run a production build against the complete content library. Existing entries may need migration. Preview a long article, a listing and an entry with optional fields omitted before calling the change complete.

For buying decisions, inspect a real package’s content arrangement rather than assuming all Astro products use collections. The Astro website templates guide connects that source structure with long-term maintenance.