---
title: Frontmatter
description: >-
  Jedes Frontmatter-Feld, das eine Seite akzeptiert, alle optional — Titel, Beschreibung, Sidebar, SEO, Suche und alles Weitere, mit der jeweiligen Funktion.
---

Jede Seite akzeptiert das folgende Frontmatter. Alle Felder sind optional.

| Prop | Type | Default | Description |
| - | - | - | - |
| `title?` | `string` | - | Seitentitel. |
| `description?` | `string` | - | Seitenzusammenfassung. |
| `type?` | `string` | `doc` | Inhaltstyp. blog/changelog steuern Feeds. |
| `date?` | `string` | - | Veröffentlichungsdatum für Blog-/Changelog-Feeds (ISO- oder YAML-Datum). |
| `authors?` | `string \| string[] \| object[]` | - | Autor(en) des Beitrags für Blog- oder Changelog-Inhalte — ein Name oder Objekte mit einem Namen plus optionalem avatar/url und beliebigen zusätzlichen Feldern. Werden unverändert übernommen. |
| `slug?` | `string` | - | Überschreibt den generierten Slug. |
| `draft?` | `boolean` | `false` | Von Produktions-Builds ausschließen. |
| `lastModified?` | `string` | - | Legt das Datum der letzten Aktualisierung der Seite fest (ISO- oder YAML-Datum); überschreibt das aus Git abgeleitete Datum. |

## Sidebar

```yaml lineNumbers
sidebar:
  label: Install
  order: 2
  icon: download
  badge: New
  hidden: false
  display: page
```

`display` legt den Rendermodus der Ordnergruppe der Seite fest ([Overrides pro Gruppe](/docs/content/navigation#per-group-overrides)) und ist nur auf der `index`-Seite eines Ordners unter der generierten Sidebar sinnvoll — überall sonst (auf einer Nicht-Index-Seite, auf der `index`-Seite des Content-Roots selbst oder auf einer beliebigen Seite unter einer expliziten `navigation.sidebar`) gibt es keine Gruppe zu konfigurieren, und Blume warnt mit `BLUME_SIDEBAR_DISPLAY_IGNORED`.

## SEO

```yaml lineNumbers
seo:
  title: Install Blume
  description: Install Blume and scaffold your first project.
  image: /og/install.png
  canonical: https://acme.com/install
  noindex: false
```

## Suche [#search]

```yaml lineNumbers
search:
  exclude: false
  tags: [api]
```

## Changelog

Changelog-Einträge (`type: changelog`) akzeptieren ein optionales `changelog`-Objekt für umfangreichere Feed- und Anzeige-Metadaten:

```yaml lineNumbers
type: changelog
changelog:
  version: 1.2.0
  date: 2026-06-20
  category: Features
```

`date` kann hier oder auf der obersten Ebene stehen — beide speisen den [Changelog-RSS-Feed](/docs/content#feeds). Siehe [Changelog](/docs/advanced/changelog) für die generierte Timeline-Seite und den Feed.

## Eigene Schlüssel [#custom-keys]

Jeder Schlüssel außerhalb dieser Referenz lässt den Build fehlschlagen, sodass Tippfehler früh auffallen. Projekte mit eigenen Metadaten können zusätzliche Schlüssel über [`frontmatter.extend`](/docs/configuration#frontmatter) in `blume.config.ts` zulassen, jeweils validiert durch ein Schema, das das Projekt bereitstellt:

```ts blume.config.ts lineNumbers
import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  frontmatter: {
    extend: {
      owner: z.string(),
      reviewedAt: z.coerce.date().optional(),
    },
  },
});
```

```yaml page.mdx
---
title: Install
owner: "@sam"
reviewedAt: 2026-06-20
---
```

Schemas werden über die [Standard-Schema](https://standardschema.dev)-Schnittstelle akzeptiert, sodass Zod (in der Version, die Ihr Projekt installiert), Valibot und ArkType allesamt funktionieren. Jeder deklarierte Schlüssel wird auf jeder Seite validiert — auch fehlende —, sodass ein erforderliches Schema den Schlüssel site-weit erzwingt; markieren Sie ihn mit `.optional()`, um nur dort zu validieren, wo er vorhanden ist. Alle übrigen Schlüssel bleiben streng validiert, und eingebaute Felder können nicht neu deklariert werden.

### Schlüssel pro Typ [#per-type-keys]

Um Schlüssel nur für einen Inhaltstyp zu verlangen — den `status` eines RFC, die `severity` eines Incident-Reports — deklariere sie stattdessen unter [`content.types`](/docs/configuration#content), geschlüsselt nach dem Frontmatter-`type`, für den sie gelten:

```ts blume.config.ts lineNumbers
import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  content: {
    types: {
      rfc: {
        frontmatter: {
          domain: z.string(),
          status: z.enum(["draft", "review", "enforced"]),
        },
      },
    },
  },
});
```

```yaml rfcs/openapi-request-schemas.mdx
---
title: OpenAPI request schemas
type: rfc
domain: architecture
status: enforced
---
```

Schlüssel pro Typ folgen denselben Validierungsregeln wie `extend`, beschränkt auf Seiten, deren aufgelöster `type` passt — einschließlich Seiten ohne `type`, wenn die Deklaration für [`content.defaultType`](/docs/configuration#content) gilt. Ein Schlüssel gehört zu einer Deklaration, site-weit oder pro Typ, nicht zu beiden. Und ein Schlüssel, der nur für einen anderen Typ deklariert ist, bleibt anderswo unbekannt, sodass ein versehentliches `status` auf einer gewöhnlichen Doc-Seite den Build weiterhin fehlschlagen lässt.

Eine Seite, die die Validierung nicht besteht, lässt `blume build` mit einer Diagnose fehlschlagen, die Datei und Schlüssel benennt. Mit [`--no-strict`](/docs/reference/cli#common-flags) läuft der Build dennoch erfolgreich durch und die fehlerhaften Seiten werden aus der Ausgabe entfernt — die Build-Zusammenfassung meldet, wie viele.

Schemas werden aus `blume/schema` für Editor- und Migrations-Tooling exportiert.