フロントマター

ページが受け付けるすべてのフロントマターフィールド（いずれも任意）について、title、description、sidebar、SEO、search などがそれぞれ何を制御するかを説明します。

すべてのページは次のフロントマターを受け付けます。すべてのフィールドは任意です。

サイドバー

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

hidden はページをサイドバーと前へ/次へのページネーションから除外します。フォルダーの index ページでは、そのページ自身の行だけが除外されます。グループの行は引き続きそのページにリンクし、前へ/次へのリンクもそのページを経由します。

display はページが属するフォルダーグループの表示モードを設定します（グループごとのオーバーライド）。これが意味を持つのは、自動生成されたサイドバー配下にあるフォルダーの index ページだけです。それ以外の場所（index 以外のページ、コンテンツルート自体の index ページ、明示的な navigation.sidebar 配下のページ）には設定対象のグループがないため、Blume は BLUME_SIDEBAR_DISPLAY_IGNORED という警告を出します。

SEO

seo:
  title: Install Blume
  description: Install Blume and scaffold your first project.
  image: /og/install.png
  canonical: https://acme.com/install
  noindex: false
  x:
    creator: "@jane"

noindex は robots の noindex を出力し、ページをサイトマップから除外し、構造化データも出力しません。x.creator はページを X アカウント（twitter:creator）の作成として示します。たとえばゲスト投稿の著者を示すときに使います。すべてのフィールドについては メタデータ を参照してください。

検索

search:
  exclude: false
  tags: [api]

AI

ai:
  exclude: true

ai.exclude はページを llms.txt と llms-full.txt から除外します。ページは引き続きレンダリングされ、検索対象にも残り、サイトマップにも掲載されたままです。

変更履歴

変更履歴のエントリー（type: changelog）では、任意の changelog オブジェクトを使って、フィードや表示に使うメタデータを追加できます。

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

date はここにもトップレベルにも記述できます。どちらに書いても 変更履歴の RSS フィード に反映されます。自動生成されるタイムラインページとフィードについては 変更履歴 を参照してください。

カスタムキー

このリファレンスにないキーがあるとビルドが失敗するため、タイプミスを早い段階で見つけられます。独自のメタデータを持つプロジェクトでは、blume.config.ts の frontmatter.extend でキーを追加できます。追加したキーは、それぞれプロジェクト側で用意したスキーマで検証されます。

import { defineConfig } from "blume";
import { z } from "zod";

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

---
title: Install
owner: "@sam"
reviewedAt: 2026-06-20
---

スキーマは Standard Schema インターフェースで受け付けるため、Zod（プロジェクトにインストールされているバージョンを問いません）、Valibot、ArkType のいずれも使用できます。宣言したキーは、そのキーがないページも含めてすべてのページで検証されます。そのため、必須のスキーマにするとサイト全体でそのキーが必須になります。キーがある場合だけ検証するには .optional() を付けてください。それ以外のキーはこれまでどおり厳密に検証され、組み込みフィールドを宣言し直すことはできません。

タイプごとのキー

RFC の status やインシデントレポートの severity のように、特定のコンテンツタイプでだけキーを必須にしたい場合は、代わりに content.types の下で宣言します。その際は、対象となるフロントマターの type をキーにします。

import { defineConfig } from "blume";
import { z } from "zod";

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

---
title: OpenAPI request schemas
type: rfc
domain: architecture
status: enforced
---

タイプごとのキーは extend と同じルールで検証されますが、対象は最終的に決まった type が一致するページに限られます。content.defaultType に対する宣言の場合は、type を設定していないページも対象になります。1 つのキーは、サイト全体の宣言とタイプごとの宣言のどちらか一方にしか書けません。また、ほかのタイプにだけ宣言したキーは、それ以外のページでは未知のキーとして扱われます。そのため、通常のドキュメントページに誤って status を書くと、これまでどおりビルドが失敗します。

検証に失敗したページがあると blume build が失敗し、ファイル名とキーを示す診断メッセージが表示されます。--no-strict を指定するとビルドは成功しますが、失敗したページは出力から除外されます。除外されたページ数はビルドサマリーに表示されます。

スキーマは、エディターや移行ツールで使えるように blume/schema からエクスポートされています。