Je hebt Javascript nodig om deze website te kunnen gebruiken. Pas je browserinstellingen in om verder te gaan!
Guides

Content

Organise documentation pages and make them easy to discover.

Good documentation gives every page one clear job. Start with a short explanation, show the smallest useful example, and link to the next step. This guide explains the content conventions used by the Docus Plus starter.

Create a page

Add a Markdown file below content/docs/:

content/docs/03.guides/01.installation.md
---
title: Installation
description: Install the Example SDK and configure your first project.
navigation:
  icon: lucide:download
---

Install the package with your project's package manager.

The title and description fields are used for the page heading, SEO metadata, and generated OG image. Keep the description short enough to work well in search results and social previews.

For more guidelines, check the official Nuxt Content documentation.

Keep pages easy to scan

Use headings to divide a page into tasks. Prefer direct language and put important constraints in a callout:

Start with the smallest useful example. Add depth when readers have a real question to answer, not just to make the navigation look complete.

Organise navigation

Frontmatter controls the page title and description. The filename controls ordering inside a section.

For larger projects, group related pages under a directory and add .navigation.yml to define the section label and icon:

content/docs/03.guides/.navigation.yml
title: Guides
icon: lucide:book-open

Numbered names control ordering without changing the public URL. For example, 03.guides/01.installation.md becomes /guides/installation.

Build a landing page

Use content/index.yml for the site homepage instead of a Markdown page. Its seo block controls the title, description, and optional custom image:

seo:
  title: Example documentation
  description: Documentation for the Example project.
  ogImage: https://example.com/og-image.png

The rest of the landing-page structure defines the hero, feature cards, and call to action. The schema in content.config.ts validates this structure during preparation and build.

Publish a changelog

Add a Markdown file below content/changelog/ for every release. These files are data entries, not documentation pages, so they do not create individual URLs. The layer renders all entries together at /changelog and shows the newest entry first:

content/changelog/v1.2.0.md
---
name: Version 1.2.0
tag: v1.2.0
publishedAt: 2026-07-15
---

## Added

- Added a new integration guide.

## Fixed

- Clarified an installation step.

Use a unique tag for each entry and an ISO 8601 date for publishedAt. Once there is an entry, the layer automatically adds a Changelog link to the footer. It hides the link and returns a 404 for /changelog when there are no entries.

Keep content in the consumer

The layer defines the collection shape, but the consuming project owns the actual pages. This keeps the reusable layer product-agnostic and lets each site add its own guides without changing shared runtime code.

Keep in touch with the latest

Sign up for our monthly deep dives - straight to your inbox.