Metadata (YAML front-matter)

While you’re editing SuperOfficeDocs, you’ll see some lines at the very top of the document with things such as uid, title, and description. These items are referred to as metadata and use YAML key-value front-matter syntax. They help the system properly create cross-referenced hyperlinks, related content links, and they help with language filtering and sorting.

The section begins and ends with 3 dashes.

---
#Insert front matter here
---

Example

Content under contribute/ (like this page) documents the contribution process itself, not a product feature, so it only uses this reduced property set:

---
uid: contribute-review-checklist
title: Review checklist
description: What reviewers check before merging a contribution to SuperOfficeDocs.
keywords: ['review', 'checklist', 'pull request']
author: digitaldiina
date: 07.09.2026
content_type: concept
language: en
---

Property reference

Product content pages (everything outside contribute/) use a larger property set than the example above. Write properties in this order. Omit any that don’t apply, and never leave one empty:

#	Property	Required	Notes
1	`uid`	Always	Unique identifier, hyphenated lowercase
2	`title`	Always	The page’s only title: rendered in the page header. No H1 in the body (see Markdown guide)
3	`description`	Always	Plain sentence, no quotes
4	`keywords`	Always	YAML array of single-quoted search-term strings, for example `['term one', 'term two']`: Mintlify’s internal-search format
5	`author`	Always	GitHub alias: default `digitaldiina`
6	`date`	Always	Last modified, format `MM.DD.YYYY`
7	`so_version`	Handcrafted docs	Product version: see defaults below; omit in generated files. Named `so_version`, not `version`: Mintlify’s search back end treats `version` as a reserved filter field and 400s on non-string values (see issue #254)
8	`content_type`	Always	`concept`, `howto`, `reference`, or `release-note`: omit in generated files
9	`functional_right`	If present	Required functional right
10	`license`	If present	Required license
11	`tier`	If present	`starter`, `core`, `growth`, `plus`, or `super`: never translated
12	`category`	If present	Content category
13	`topic`	If present	Specific topic
14	`platform`	If present	Target platform
15	`deployment`	If present	Deployment type
16	`pilot`	If present	Pilot status
17	`audience`	If present	Target audience
18	`audience_tooltip`	If present	Audience tooltip
19	`redirect_from`	If present	Old URL(s) that should redirect here
20	`hidden`	If present	`true` to remove the page from sidebar navigation (still reachable by URL, not search-indexed). Used when consolidating several pages into one: pair with `redirect_from` and a `docs.json` redirect. Never set to `false`.
21	`userflow_index`	If present	`true` if the page is outside a learn folder and should be included in the per-language userhelp sitemap Userflow’s in-app Resource Center reads (see SEO and social previews)
22	`related`	If present	Curated related-topics list, only where Mintlify’s own automatic suggestions risk a bad match (for example a short, reused action verb repeated across many entities, or a broad hub topic). A YAML block sequence of items, each either a bare internal path (Mintlify infers the label from that page’s own `title`) or a `Custom label: /path` mapping when the curated wording should differ from the target’s title; external URLs always need the `Custom label:` form, since there’s no page to infer from. Omit the property entirely to let automatic suggestions run, or set it to `false` to suppress the widget outright (generated-reference trees, release-notes, navigation hub pages)
23	`noindex`	If present	`true` to exclude the page from search indexing. Used on old-version release notes and on category/subcategory navigation hub pages (link lists, not real content)
24	`language`	Always	Language code: always last

contribute/ pages (like this one) only use uid/title/description/keywords/author/date/content_type/language: the rest describe product features and don’t apply here.

A subcategory map page (mode: "custom", <div id="subcategory"> in the body — the per-topic “map” page listing a Guides category’s own sub-pages, for example en/company/index.mdx) uses its own smaller property set instead of the table above: mode, title, sidebarTitle, description, icon, iconType, author, date, language. icon is always "map" and iconType is always "regular" (Font Awesome, not Phosphor), positioned after description and before author. Translate sidebarTitle on non-English subcategory pages same as title/description. See the subcategory-landing-page blueprint template.

index.mdx (the site homepage, mode: "custom") carries one extra, homepage-only property: recent_pages, a YAML list of {path, pinned?, since?, title?} entries driving the “What’s new” list. pinned: true exempts an entry from the 120-day age-out but it still counts against the 7-entry cap. title is an optional override, shown instead of the target page’s own title when that reads oddly out of context. Don’t hand-edit the resolved <RecentPages items={[...]} /> call in the page body — tools/ci/sync-recent-pages.py regenerates it and will overwrite manual edits. See Automated tests.

Default so_version by section

so_version is required in handcrafted docs, omitted in generated ones (the reference/ and table/ folders).

Section	Default version
User guide (learn)	`12.3`
Developer portal	`2.15`
Mobile CRM	`11.1.13`
Integrations	Ask: uses its own versioning

If you’re writing release-notes content, or don’t know which version or date applies, ask the technical writer rather than guessing.

What to do

If you’re creating a new document, fill in as much of the metadata as you can. If you’re editing an existing document, update date to the day you made the change, and update author if you’re not the original author (list multiple contributors comma-separated). If your edit changes which product version the content applies to, update so_version too. Don’t leave these stale.

To get a prompt for what metadata to add, we recommend Blueprint templates for VS Code.

Before any updates get merged in the repo, the reviewers will check this section to make sure everything is good to go. One reason for reviewing this section is because the uid (unique identifier) must be, well… unique!

​Example

​Property reference

​Default so_version by section

​What to do

Example

Property reference

Default so_version by section

What to do