---
title: Frontmatter
description: >-
  Todos os campos de frontmatter que uma página aceita, todos opcionais — título, descrição, barra lateral, SEO, pesquisa e os demais, com o que cada um controla.
---

Todas as páginas aceitam o frontmatter a seguir. Todos os campos são opcionais.

| Prop | Type | Default | Description |
| - | - | - | - |
| `title?` | `string` | - | Título da página. |
| `description?` | `string` | - | Resumo da página. |
| `type?` | `string` | `doc` | Tipo de conteúdo. blog/changelog alimentam os feeds. |
| `date?` | `string` | - | Data de publicação para os feeds de blog/changelog (ISO ou data YAML). |
| `authors?` | `string \| string[] \| object[]` | - | Autor(es) do post para conteúdo de blog/changelog — um nome, ou objetos com um nome mais avatar/url opcionais e quaisquer campos extras. Preservado como está. |
| `slug?` | `string` | - | Substitui o slug gerado. |
| `draft?` | `boolean` | `false` | Exclui das builds de produção. |
| `lastModified?` | `string` | - | Fixa a data de "última atualização" da página (ISO ou data YAML); substitui a data derivada do git. |

## Barra lateral [#sidebar]

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

`hidden` remove a página da barra lateral e da paginação anterior/próxima. Na página `index` de uma pasta, ele remove apenas a linha da própria página: a linha do grupo continua apontando para a página, e os links anterior/próximo continuam passando por ela.

`display` define o modo de renderização do grupo de pasta da página ([sobrescritas por grupo](/docs/content/navigation#per-group-overrides)) e só faz sentido na página `index` de uma pasta sob a barra lateral gerada — em qualquer outro lugar (uma página que não seja index, a própria página `index` da raiz de conteúdo ou qualquer página sob uma `navigation.sidebar` explícita) não há grupo para configurar, e o Blume avisa com `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
```

## Pesquisa [#search]

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

## Changelog

As entradas de changelog (`type: changelog`) aceitam um objeto `changelog` opcional para metadados mais ricos de feed e exibição:

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

`date` pode ficar aqui ou no nível superior — ambos alimentam o [feed RSS do changelog](/docs/content#feeds). Consulte [Changelog](/docs/advanced/changelog) para a página de linha do tempo gerada e o feed.

## Chaves personalizadas [#custom-keys]

Qualquer chave fora desta referência faz a build falhar, então erros de digitação são detectados cedo. Projetos que carregam seus próprios metadados podem incluir chaves extras via [`frontmatter.extend`](/docs/configuration#frontmatter) em `blume.config.ts`, cada uma validada por um schema fornecido pelo projeto:

```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
---
```

Os schemas são aceitos pela interface [Standard Schema](https://standardschema.dev), então Zod (qualquer que seja a versão instalada pelo seu projeto), Valibot e ArkType funcionam. Toda chave declarada é validada em cada página — inclusive as ausentes — de modo que um schema obrigatório impõe a chave em todo o site; marque-a como `.optional()` para validar apenas onde estiver presente. Todas as demais chaves permanecem estritamente validadas, e os campos integrados não podem ser redeclarados.

### Chaves por tipo [#per-type-keys]

Para exigir chaves apenas em um tipo de conteúdo — o `status` de uma RFC, a `severity` de um relatório de incidente — declare-as em [`content.types`](/docs/configuration#content), organizadas pelo `type` do frontmatter ao qual se aplicam:

```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
---
```

As chaves por tipo seguem as mesmas regras de validação de `extend`, restritas às páginas cujo `type` resolvido corresponda — incluindo páginas que não definem nenhum `type`, quando a declaração é para [`content.defaultType`](/docs/configuration#content). Uma chave pertence a uma única declaração, no site inteiro ou por tipo, nunca às duas. E uma chave declarada apenas para outro tipo continua desconhecida nos demais, então um `status` perdido numa página de doc comum ainda faz a build falhar.

Uma página que falha na validação faz `blume build` falhar com um diagnóstico nomeando o arquivo e a chave. Com [`--no-strict`](/docs/reference/cli#common-flags), a build é bem-sucedida mesmo assim e as páginas com falha são removidas da saída — o resumo da build informa quantas.

Os schemas são exportados de `blume/schema` para ferramentas de edição e migração.