Multi-domain Content Architecture with Docusaurus - Setup Part 2

January 15, 2026 · 7 min read

Software Engineer, Founder of Fluxainē Studios

From monolithic docs to structured knowledge domains

Most documentation systems start simple—and then quietly become a mess.

What begins as “just write some docs” turns into:

unrelated topics sharing a sidebar
navigation that feels accidental
folders that encode structure but not meaning
readers getting lost because everything is technically connected, but nothing is conceptually separated

This post documents how I rebuilt the documentation architecture for Fluxainē Studios using Docusaurus, moving from a single, monolithic docs setup to a multi-domain, sidebar-isolated knowledge system that scales cleanly.

No hacks. No plugins beyond what Docusaurus already provides. Just intentional structure.

The Problem with the Default Docs Setup

Out of the box, Docusaurus gives you:

one docs/ folder
one sidebar
one cognitive space

That’s fine for a tutorial or a product manual.

It breaks down when you want to host multiple independent domains of knowledge, such as:

somatic theory
anthropology
software architecture
trading systems
recipes

When everything shares one sidebar, you get navigation spillover: topics that should never coexist suddenly feel related simply because they sit next to each other.

The core issue is not content—it’s architecture.

The Design Goal

The goal was simple to state, but nontrivial to implement:

Each domain should feel like its own body of work
Each domain should have:
- its own URL namespace
- its own sidebar
- zero awareness of other domains
There should still be a single entry point that shows what exists

In other words:

one studio, many books.

Step 1: Disable the Monolithic Docs Preset

The key realization is that the Docusaurus “classic” preset creates one docs instance by default.

That’s the source of sidebar spillover.

So the first step was to explicitly disable it:

// docusaurus.config.ts

...
presets: [
  [
    'classic',
    {
      docs: false, // set this to false to turn off the default monolithic docs
      blog: { /* unchanged */ },
      ...
    },
  ],
],
...

This removes the implicit “everything lives in one docs universe” assumption.

From here on, every docs space is created intentionally.

Step 2: Create a `/docs` Landing Page (Without a Sidebar)

Instead of /docs being “the docs,” it becomes an index of domains.

A small, dedicated docs instance is created solely for this purpose:

// docusaurus.config.ts

...
plugins: [
    [
      "@docusaurus/plugin-content-docs",
      {
        id: "landing",
        path: "docs/landing",
        routeBasePath: "docs",
        sidebarPath: false,
      },
    ],
]
...

The result:

/docs exists
it has no sidebar
it cannot accidentally grow into a content dump

This page answers one question only:

What bodies of knowledge exist here?

In the docs/landing/ folder in the project repo, create a file called index.md. This is where docs leads to now.

<!-- docs/landing/index.md -->

---

id: index
title: Fluxainē Studios Corpora
slug: /
sidebar_position: 1

---

Welcome to the canonical knowledge base of Fluxainē Studios.

Each domain below is an independent body of research and practice.

---

## Domains

### 🧠 Somatic Theory

Embodiment, nervous systems, and lived practice.  
→ [/somatic-theory/](/somatic-theory/)

### 🧬 Anthropology

Field notes, theory, ethnography.  
→ [/anthropology/](/anthropology/)

### 🤖 Android

Architecture, systems, and case studies.  
→ [/android/](/android/)

### 📈 Rust Trading

Quant models, backtesting, market structure.  
→ [/rust-trading/](/rust-trading/)

### 🍳 Recipes

Techniques, experiments, and dishes.  
→ [/recipes/](/recipes/)

Step 3: Create the First Domain (The Reference Pattern)

Each domain is implemented as its own docs plugin instance.

For example, let's consider the domain Somatic Theory:

docs/somatic-theory/
└── intro.md

The root document defines the domain entry point, i.e. the landing page for Somatic Theory domain:

<!-- docs/somatic-theory/intro.md -->

---

title: Somatic Theory
slug: /

---

This maps cleanly to:

docs/somatic-theory

A dedicated sidebar is defined using autogenerated structure:

// docusaurus.config.ts

...

// manually added plugins
plugins: [
  [
    "@docusaurus/plugin-content-docs",
    {
      id: "landing",
      path: "docs/landing",
      routeBasePath: "docs",
      sidebarPath: false,
    },
  ],
  [
    "@docusaurus/plugin-content-docs",
    {
      id: "somatic-theory",
      path: "docs/somatic-theory",
      routeBasePath: "somatic-theory",
      sidebarPath: require.resolve("./sidebars/somatic-theory.ts"),
    },
  ],
]

...

Then, create the sidebar component.

// sidebars/somatic-theory.ts

import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";

const sidebars: SidebarsConfig = {
  somaticTheorySidebar: [
    {
      type: "autogenerated",
      dirName: ".",
    },
  ],
};

export default sidebars;

At this point, the pattern is established:

one domain
one sidebar
one URL space
no coupling

Step 4: Add Additional Domains (Mechanical, Repeatable)

Once the pattern exists, adding new domains is purely mechanical. For instance, add domains such as:

Anthropology
Android
Rust Trading
Recipes

Each one:

lives in its own folder
has its own docs plugin
has its own sidebar file
maps to its own route

This is where the architecture starts paying dividends:

adding domains does not increase complexity.

Step 5: Use Folders for Structure, `_category_.json` for Meaning

Inside each domain, folders define hierarchy, but _category_.json defines intent.

Example:

// docs/somatic-theory/seven-portal-systems/_category_.json
{
  "label": "Seven-Portal Systems",
  "collapsed": false,
  "position": 1
}

This small file controls:

sidebar labels
ordering
default expansion state

The important mental model is this:

Folders define structure.

_category_.json defines meaning.

The filesystem answers where.
The category file answers what.

The file system inside the domain looks something like this:

docs/somatic-theory/
├── intro.md
├── seven-portal-systems
│   ├── _category_.json
│   ├── diagnostic-patterns.md
│   ├── overview.md
│   └── seven-portals.md
├── shadow-mechanics
│   ├── _category_.json
│   ├── diagnostic-patterns.md
│   ├── overview.md
│   └── seven-portals.md
└── the-flow-of-now (sub-category)
    ├── _category_.json
    ├── diagnostic-patterns.md
    ├── overview.md
    └── seven-portals.md (leaf document)

At the ends of the hierarchy live leaf documents:

exercises
recipes
techniques
references

These carry no structural responsibility.

They only describe themselves via front matter.

A canonical leaf document looks like this:

---
title: Presence Exercises
description: Practical somatic exercises for cultivating present-moment awareness.
tags:
  - practice
  - somatic
draft: false
hide_table_of_contents: false
---

Leaf-document at the sub-category level

The leaf-document can sit at the level of the sub-category directly, but will compete with the sidebar positioning of the sub-categories in the domain.

For instance, sidebar_position: 2 in the front matter of the sub-category-level leaf-node will have to work with the _category_.json's "position": 4 field for the ordering to be set correctly.

Ordering of the leaf-documents

Within the sub-category, the leaf documents can be ordered as needed by using sidebar_position: 1 in the front matter of the leaf-document markdown.

---
title: Overview
sidebar_position: 1
---

Step 6: Clean Up Defaults

With the architecture in place, all tutorial artifacts were removed:

default tutorial folders
unused sidebars.ts
legacy docs assumptions

What remained was only what was explicitly referenced.

This matters more than it sounds:

ambiguity is technical debt.

Finally, the navbar was made explicit:

// docusaurus.config.ts

...

themeConfig: {
  ...
  navbar: {
    title: "Fluxainē Studios",
    logo: {
      alt: "Fluxainē Studios' Logo",
      src: "img/logo.png",
    },
    items: [
      {
        to: "/somatic-theory/",
        label: "Somatic Theory",
        position: "left",
      },
      {
        to: "/anthropology/",
        label: "Anthropology",
        position: "left",
      },
      {
        to: "/android/",
        label: "Android",
        position: "left",
      },
      {
        to: "/rust-trading/",
        label: "Rust Trading",
        position: "left",
      },
      {
        to: "/recipes/",
        label: "Recipes",
        position: "left",
      },
      { to: "/blog", label: "Blog", position: "right" },
      // { to: "/contact", label: "Contact", position: "right" },
    ],
  ...
  }
...

No dynamic logic was needed.

Because the URLs are honest, Docusaurus automatically highlights the active domain.

The system is domain-aware by construction.

In the docusaurus.config.ts file, make the following changes and modify when appropriate.

// docusaurus.config.ts

...
themeConfig: {
  ...
      footer: {
      style: "dark",
      links: [
        {
          title: "Publishing",
          items: [
            { label: "Substack", href: "https://substack.com" },
            { label: "Gumroad", href: "https://gumroad.com" },
          ],
        },
        {
          title: "Support",
          items: [
            { label: "Ko-fi", href: "#" },
            { label: "Buy Me a Coffee", href: "#" },
          ],
        },
        {
          title: "More",
          items: [
            {
              label: "Blog",
              to: "/blog",
            }
          ],
        },
      ],
      copyright: `Copyright © ${new Date().getFullYear()} Raghavendra Saralaya. Built with Docusaurus.`,
    },
  ...
}
...

The Final Result

The end state is a documentation system that:

treats domains as first-class entities
prevents sidebar spillover by design
scales horizontally without refactors
separates structure from content
supports both narrative and reference material
is ready for CMS integration if needed

Most importantly, it feels calm.

Readers are never asked to mentally reconcile unrelated topics just because they share navigation.

Closing Thought

The biggest shift wasn’t technical—it was conceptual:

Documentation isn’t a folder tree.

It’s a map of ideas.

Once the architecture reflects that, the tooling falls into place naturally.

Multi-domain Content Architecture with Docusaurus - Setup Part 2

The Problem with the Default Docs Setup

The Design Goal

Step 1: Disable the Monolithic Docs Preset

Step 2: Create a `/docs` Landing Page (Without a Sidebar)

Step 3: Create the First Domain (The Reference Pattern)

Step 4: Add Additional Domains (Mechanical, Repeatable)

Step 5: Use Folders for Structure, `_category_.json` for Meaning

Leaf-document at the sub-category level

Ordering of the leaf-documents

Step 6: Clean Up Defaults

Step 7: Make the Navbar Reflect Reality

Step 8: Adding the Footer

The Final Result

Closing Thought

The Problem with the Default Docs Setup​

The Design Goal​

Step 1: Disable the Monolithic Docs Preset​

Step 2: Create a /docs Landing Page (Without a Sidebar)​

Step 3: Create the First Domain (The Reference Pattern)​

Step 4: Add Additional Domains (Mechanical, Repeatable)​

Step 5: Use Folders for Structure, _category_.json for Meaning​

Leaf-document at the sub-category level​

Ordering of the leaf-documents​

Step 6: Clean Up Defaults​

Step 7: Make the Navbar Reflect Reality​

Step 8: Adding the Footer​

The Final Result​

Closing Thought​

The Problem with the Default Docs Setup

The Design Goal

Step 1: Disable the Monolithic Docs Preset

Step 2: Create a `/docs` Landing Page (Without a Sidebar)

Step 3: Create the First Domain (The Reference Pattern)

Step 4: Add Additional Domains (Mechanical, Repeatable)

Step 5: Use Folders for Structure, `_category_.json` for Meaning

Leaf-document at the sub-category level

Ordering of the leaf-documents

Step 6: Clean Up Defaults

Step 7: Make the Navbar Reflect Reality

Step 8: Adding the Footer

The Final Result

Closing Thought