Pages

A page is the main unit of documentation in Doxbrix. It has its own title, body, status, revision history, and place in navigation. Spaces and groups help readers find pages, but pages are the content itself.

Because of that, page quality matters at two levels:

• the page must be useful on its own
• the page must fit clearly into the broader site structure

Create pages with the right starting shape

Creating a page is intentionally simple, but the starting template still matters because it influences the structure and expectations of the content that follows.

Page templates

Use templates when you want a consistent editorial shape across a section. For example, if every onboarding page should follow the same procedural pattern, using Guide keeps the structure predictable for both authors and readers.

Organize pages intentionally

In the content tree you can:

• Reorder a page by dragging it up or down
• Nest a page inside a group
• Rename a page inline or through Rename
• Move a page with Move to…
• Change icon / emoji when you want a clearer visual marker in navigation

These actions are small, but they are how documentation teams keep a site coherent over time. A site rarely becomes difficult to navigate in one major change. It usually gets there through many small, unreviewed additions.

Understand page status before you publish

Each page shows its status in the content tree and in the page header:

These states allow the documentation workflow to separate writing from publishing. That separation is especially important when several authors are working at once or when a project has approval requirements.

Use page actions for maintenance work

The page menu in the content tree includes the actions authors use most often for page-level maintenance:

• Rename
• Copy link
• Duplicate
• Move to…
• Change icon / emoji
• Set as home page
• Hide from nav or Show in nav
• Delete

These actions are useful for more than cleanup. For example:

• Duplicate is helpful when you want to reuse the structure of a strong existing page
• Move to… is useful during larger restructures
• Hide from nav lets you preserve content without surfacing it prominently in the reader experience
• Set as home page helps define the main landing page of a space

Use API pages when the content is reference-driven

A page can also represent an API operation. In that case, Doxbrix shows it with an HTTP-method badge and renders it with API-specific blocks.

There are two common ways to create API pages:

• start from the API reference page template
• use Add API reference to import an OpenAPI specification and generate a page per operation

This is useful when part of your documentation site is conceptual and part is reference-driven.

Read the page header as an editorial control area

When a page is open, Doxbrix surfaces the key editorial controls near the page content:

• Quality shows a live score and opens Document insights
• Improve with AI helps revise the page against flagged quality issues
• the top bar gives access to Preview, History, Comments, and Publish or Submit for review

Treat this area as the place where authoring and publishing decisions meet. It tells you whether the content is only saved, ready for review, or ready for readers.

Saving and publishing are different operations

Edits save automatically. The save indicator moves between Autosaving… and Autosaved, but the page remains a draft until you deliberately move it through review or publication.

This distinction is central to how Doxbrix works:

• saving preserves author work
• publishing changes the reader experience

That separation lets teams edit confidently without exposing unfinished work.

Pages remain portable as MDX

Under the hood, each page is MDX with YAML frontmatter that sets its title and description:

---
title: Quickstart
description: Get a project running in a few minutes.
---

# Quickstart

The description supports search and SEO. Use exactly one # H1 per page, usually matching the title.

This is one of the reasons Doxbrix supports both in-app authoring and docs-as-code. The content remains structured enough to move between environments without losing meaning.

Next steps