फ़्रंटमैटर

हर पेज द्वारा स्वीकार किया जाने वाला प्रत्येक फ़्रंटमैटर फ़ील्ड, सभी वैकल्पिक — title, description, sidebar, SEO, search और बाकी सभी, साथ ही यह भी कि प्रत्येक फ़ील्ड क्या नियंत्रित करता है।

हर पेज निम्नलिखित फ़्रंटमैटर स्वीकार करता है। सभी फ़ील्ड वैकल्पिक हैं।

फ़्रंटमैटर YAML होता है। इसलिए जिस मान में कोलन के बाद स्पेस हो, उसे उद्धरण चिह्नों में रखें, जैसे description: "Setup: the easy way"। उद्धरण चिह्नों के बिना YAML दूसरे कोलन को एक नेस्टेड कुंजी की शुरुआत मानता है, और Blume उस फ़ाइल और पंक्ति की रिपोर्ट BLUME_FRONTMATTER_INVALID के रूप में करता है।

लेआउट

mode यह तय करता है कि कोई पेज अपने कंटेंट के आसपास क्या दिखाता है:

wide चौड़ी तालिकाओं या डायग्राम वाले पेज के लिए उपयुक्त है, और center रिलीज़ नोट्स या ऊपर से नीचे तक पढ़ी जाने वाली किसी घोषणा के लिए। custom केवल हेडर रखता है, जो MDX में लिखे गए लैंडिंग पेज के लिए है, और frame साइडबार भी रखता है, जो ऐसे टूल या डैशबोर्ड के लिए है जो डॉक्स के नेविगेशन के भीतर रहता है। इन दोनों में से कोई भी पेज का शीर्षक या विवरण रेंडर नहीं करता, इसलिए आप अपनी स्वयं की हेडिंग लिखें। हर मोड में पेज खोज में बना रहता है और उसकी Markdown कॉपी भी बनी रहती है।

title: Welcome
mode: custom

ये मान Mintlify के मानों से मेल खाते हैं; उसके assistant मोड का, जो पूरे पेज पर चलने वाला चैट है, यहाँ कोई समकक्ष नहीं है।

संबंधित पेज

related उन पेजों की सूची देता है जिन्हें इस पेज के नीचे सुझाया जाना है। ये संबंधित पेज हेडिंग के अंतर्गत कार्ड के रूप में दिखाए जाते हैं:

related:
  - /guides/deployment
  - Search setup: /configuration/search
  - https://astro.build

रूट-सापेक्ष पथ किसी दूसरे पेज की ओर संकेत करता है, जिसे कार्ड उस पेज के शीर्षक और विवरण के साथ दिखाता है; किसी अनुवादित पेज पर, अनुवाद उपलब्ध होने पर यह उस अनुवाद से लिंक करता है। Title: link प्रविष्टि कार्ड का शीर्षक स्वयं सेट करती है, और कोई एब्सोल्यूट URL साइट से बाहर लिंक करता है, जिसके कार्ड पर उसका होस्ट नाम दिखाया जाता है। पथों की जाँच पेज के किसी भी अन्य लिंक की तरह की जाती है, इसलिए यदि कोई पथ किसी भी पेज से मेल नहीं खाता, तो blume validate उसकी रिपोर्ट करता है। यह कुंजी Mintlify की कुंजी से मेल खाती है, इसलिए माइग्रेट किए गए पेजों में यह जैसी लिखी है वैसी ही बनी रहती है।

साइडबार

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

hidden पेज को साइडबार से और पिछले/अगले पेजिनेशन से हटा देता है, और इसी कारण साइटमैप, खोज और llms.txt से भी (छिपे हुए पेज देखें)। किसी फ़ोल्डर के index पेज पर यह केवल उस पेज की अपनी पंक्ति हटाता है: समूह की पंक्ति फिर भी उस पेज से लिंक करती रहती है, इसलिए पिछले/अगले लिंक अब भी उससे होकर गुज़रते हैं और पेज साइटमैप, खोज और llms.txt में बना रहता है। होम पेज, यानी रूट index पेज, पर भी यह केवल उसकी पंक्ति हटाता है: पेज साइटमैप, खोज और llms.txt में बना रहता है।

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 जोड़ता है, पेज को साइटमैप से हटा देता है, और उसका स्ट्रक्चर्ड डेटा नहीं बनाता। जो canonical किसी दूसरे URL की ओर संकेत करता है, वह भी पेज को साइटमैप से हटा देता है, क्योंकि साइटमैप में केवल कैनॉनिकल URL ही सूचीबद्ध होते हैं। x.creator पेज का श्रेय किसी X खाते (twitter:creator) को देता है, जैसे किसी गेस्ट पोस्ट के लेखक को। सभी फ़ील्ड के लिए मेटाडेटा देखें।

खोज

search:
  exclude: false
  tags: [api]
  keywords: [install, setup]
  boost: 3

exclude पेज को खोज से बाहर रखता है। tags पेज के रिकॉर्ड को लेबल करता है, ताकि कोई होस्टेड खोज एडैप्टर उन लेबल के आधार पर फ़िल्टर कर सके (टैग देखें)। keywords ऐसे अतिरिक्त शब्द हैं जिनसे पेज, अपने स्वयं के टेक्स्ट के अलावा, खोजा जा सकता है। boost पेज की प्रासंगिकता को गुणा करता है: 1 से अधिक मान उसे ऊँची रैंक देता है, और 1 से कम मान नीची। रैंकिंग देखें।

AI

ai:
  exclude: true

ai.exclude पेज को llms.txt और llms-full.txt से बाहर रखता है। यह पेज को आपकी साइट की स्किल के पेज मैप से भी बाहर रखता है। पेज फिर भी रेंडर होता है। वह खोज, MCP सर्वर और JSON API में बना रहता है, और साइटमैप में भी उसका स्थान बना रहता है।

चेंजलॉग

चेंजलॉग प्रविष्टियाँ (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 सेट नहीं करते। एक कुंजी केवल एक घोषणा में हो सकती है: या तो पूरी साइट वाली या प्रति-प्रकार वाली, दोनों में नहीं। जो कुंजी केवल किसी दूसरे प्रकार के लिए घोषित है, वह बाकी जगहों पर अज्ञात मानी जाती है। इसलिए किसी सामान्य डॉक पेज पर गलती से जोड़ा गया status अब भी बिल्ड को विफल कर देता है।

यदि कोई पेज सत्यापन में विफल होता है, तो blume build विफल हो जाता है और एक डायग्नोस्टिक संदेश फ़ाइल और कुंजी का नाम बताता है। --no-strict के साथ बिल्ड फिर भी सफल होता है, और विफल पेज आउटपुट से हटा दिए जाते हैं। बिल्ड सारांश बताता है कि ऐसे कितने पेज हटाए गए।

स्कीमा blume/schema से एक्सपोर्ट किए जाते हैं, ताकि आप उन्हें एडिटर और माइग्रेशन टूलिंग में इस्तेमाल कर सकें।