---
title: Navbar, footer and reserved fields
description: navbar-links, footer, content, $schema, and the three reserved keys.
---

## `navbar-links`

<ParamField name="navbar-links[].label" type="string" required>
  Link text, 1–60 characters.
</ParamField>

<ParamField name="navbar-links[].url" type="string" required>
  Destination.
</ParamField>

<ParamField name="navbar-links[].style" type='"minimal" | "filled" | "outlined"' default="minimal">
  Visual treatment.
</ParamField>

<ParamField name="navbar-links[].external" type="boolean" default="false">
  Marks the link as leaving the site.
</ParamField>

## `footer`

<ParamField name="footer.socials[].platform" type='"twitter" | "github" | "discord" | "linkedin" | "youtube" | "website"' required>
  Which social icon to render.
</ParamField>

<ParamField name="footer.socials[].url" type="string" required>
  Absolute URL.
</ParamField>

<ParamField name="footer.columns[].label" type="string" required>
  Column heading, 1–60 characters.
</ParamField>

<ParamField name="footer.columns[].links" type="object[]" required>
  At least one `{ label, url }`.
</ParamField>

<ParamField name="footer.status" type="object">
  `{ label, url? }` — a minimal status region. No indicator enum, no polling.
</ParamField>

`footer.columns[].links[].url` and `footer.status.url` are **base-prefixed when
root-relative** — write `/quickstart`, not `/docs/quickstart`. This is the opposite of
links in page prose, which must carry the prefix themselves. `footer.socials[].url` is
always taken verbatim.

## `content`

<ParamField name="content.dialect" type='"reed" | "fern" | "mintlify"' default="reed">
  How to interpret component props in your MDX.
</ParamField>

See [Content dialect](/docs/authoring/dialect) — this is the field migrated projects
almost always need.

## `$schema`

<ParamField name="$schema" type="string">
  Editor-only JSON Schema hint. Accepted and otherwise completely ignored by Reed.
</ParamField>

It has no effect on any other field's validation, so adding, removing or hand-editing it
is always safe.

## Reserved: `versions`, `products`, `languages`

These three keys are accepted and **ignored**. They are placeholders for future
functionality, and their contents are not validated.

**Do not infer support from their presence.** Multi-version, multi-product and
multi-language documentation are architectural features, not a few extra fields, and none
of them is implemented. Writing a `versions` block today produces exactly one version of
your site, silently, because nothing reads it.

They exist in the schema so that a config carrying them does not fail the strict
unknown-key check — not as a preview of behaviour.