Search Documentation

Search for pages and headings in the documentation

Multiple Collections Use Cases

Multiple collections solve different organizational and business problems. Here are practical scenarios where they shine.

Use Case 1: Product + API Documentation

Problem: Product docs and API docs have completely different audiences, structures, and update cycles.

Solution: Separate collections with distinct configurations.

docs collection (/docs)
├── Getting Started (simple, user-focused)
├── How-To Guides (task-based)
└── FAQ (friendly)

api collection (/api)
├── v1 Legacy (deprecated)
├── v2 Current (production)
└── v3 Beta (upcoming)

Benefits:

  • Product team owns /docs, updates when features ship
  • API team owns /api, maintains versions independently
  • Different navigation structures match different mental models
  • Users see what’s relevant to them

Use Case 2: Multi-Product Platform

Problem: Your company offers 3 products. One docs site per product, all under same domain.

Solution: Three collections, three separate navigation systems.

/product-a/  ->  Standalone docs site
/product-b/  ->  Standalone docs site
/product-c/  ->  Standalone docs site

Each product team:

  • Controls their own navigation
  • Updates their own documentation
  • Uses their own structure
  • No cross-contamination

Use Case 3: Audience-Specific Documentation

Problem: Same product, different docs for different users.

Solution: Collections organized by audience.

/beginners/
  ├── Getting Started
  ├── Basic Concepts
  └── Common Tasks

/advanced/
  ├── Architecture
  ├── Performance Tuning
  └── Internals

/api-reference/
  ├── Endpoints
  ├── Webhooks
  └── SDK Guide

Benefits:

  • Each collection tailored to its audience
  • Beginners don’t see advanced topics
  • API users find endpoints immediately
  • Clear mental separation

Use Case 4: Multi-Language Deployment

Problem: Documentation in 5 languages, each needs own structure.

Solution: Collections per language + region.

/en/    (English)
/es/    (Spanish)
/fr/    (French)
/de/    (German)
/ja/    (Japanese)

Each collection:

  • Uses language-appropriate navigation
  • Can have culture-specific groupings
  • Updates independently
  • No translation bottlenecks

Use Case 5: Enterprise Multi-Workspace

Problem: Enterprise client with 10 internal teams, each needs documentation.

Solution: Shared platform, independent collections.

/sales-team/     (Sales docs)
/engineering/    (Tech docs)
/operations/     (Ops playbooks)
/compliance/     (Policy docs)
/finance/        (Budget guides)

Benefits:

  • Centralized hosting
  • Decentralized ownership
  • Each team controls their structure
  • Shared infrastructure costs
  • No turf wars over navigation

Use Case 6: Documentation Versions

Problem: Major version updates break docs. Need to support multiple versions.

Solution: Collections per version.

/v3/ (Current)    Auto-generated, full features
/v2/ (LTS)        Manual maintenance
/v1/ (Legacy)     Frozen docs
/experimental/    Beta features only

Each collection maintains independently:

  • Users access correct version
  • Old versions stay as-is
  • New features in experimental
  • Clear versioning strategy

Use Case 7: Monorepo Polyglot Packages

Problem: Monorepo with 8 packages in different languages/frameworks. Each needs docs.

Solution: Collection per package.

/react/           React components
/vue/             Vue components
/angular/         Angular components
/svelte/          Svelte components
/typescript/      TypeScript utils
/cli/             CLI tools
/devops/          DevOps guides
/testing/         Testing utilities

Benefits:

  • Each package owns its docs
  • Different structures match different paradigms
  • Teams update their own package docs
  • Monorepo stays organized

Use Case 8: SaaS Feature Documentation + Knowledge Base

Problem: “How to use the feature” docs ≠ “How we built it” knowledge base.

Solution: Separate collections.

/docs/            (Feature documentation)
├── Features
├── How-To Guides
├── Tutorials
└── Troubleshooting

/knowledge-base/  (Internal/public knowledge base)
├── Architecture Decisions
├── Performance Notes
├── Security Considerations
├── Maintenance Guides
└── Research

Each serves different purposes, different audiences, maintained by different teams.

Implementation Pattern

For any use case, the pattern is similar:

Step 1: Define Collections

// data/config.ts
export const CONTENT = {
    systems: [
        { id: "docs", dir: "content/docs", route: "/docs" },
        { id: "api", dir: "content/api", route: "/api" },
        { id: "guides", dir: "content/guides", route: "/guides" },
    ],
};

Step 2: Configure Each Navigation

export const SIDEBAR_NAVIGATION = {
    docs: {
        /* docs-specific navigation */
    },
    api: {
        /* api-specific navigation */
    },
    guides: {
        /* guides-specific navigation */
    },
};

Step 3: Create Content Folders

mkdir -p content/docs
mkdir -p content/api
mkdir -p content/guides

Step 4: Add Content Files

Each collection has its own folder, files, structure.

When NOT to Use Multiple Collections

Stick with one collection if:

  • All documentation serves the same audience
  • Navigation structure is consistent
  • Content isn’t maintained by separate teams
  • You’re just starting out

Multiple collections shine when:

  • Audiences are fundamentally different
  • Teams are independent
  • Update cycles are separate
  • Navigation structures don’t align

Next Steps