A documentation set is not a second website. It is a section of the one site you already have, rooted at a URL prefix you choose — /docs/, /guides/, /help/ — rendered by a documentation shell instead of your own layouts. Everything else stays where it is: the same domain, the same deployments, the same asset library, the same team.
What makes that section a set rather than a pile of pages is that two records point at each other. A page type whose kind is Documentation or API Documentation, and a menu bound to it as the set’s left navigation. Neither half does the job alone, and most of the surprises people hit with documentation in Leed come from having built one half and expected the behavior of both. Page types, menus and folders are not documentation-specific inventions — each is defined once for the whole product in Core Concepts.
The two halves
The page type owns the set’s identity and its appearance: the URL root, the layout, the color theme, the code theme, the font, the logos, the starting page and the search index. All of that lives in one object on the page type called documentationConfiguration. It is the same object that decides every other kind of content on your site, documented in full at Page Types.
The menu owns the set’s shape: which pages exist in the navigation, what order they are in, which folders group them — and, because folder names become URL segments, where every page in the set actually lives. It is an ordinary menu, built with the same tree editor you use for a site header and described at Building and Editing a Menu. The binding itself is a single field, documentationConfiguration.menus.left, holding the menu’s id.
flowchart TD PT["Page type<br/>type: documentation or api"] M["Menu record"] F["Folders<br/>blank href, has children"] P["Page items<br/>href = pageid:PAGEID"] D1["src/SLUG/SEGMENT.11tydata.json"] D2["src/_data/menu.json<br/>keyed by menu name"] D3["src/SLUG/FOLDERS/PAGE.md"] OUT["The rendered documentation set"] PT -->|documentationConfiguration.menus.left| M M --> F F --> P PT -.->|page type publish| D1 M -.->|menu publish| D2 P -.->|page publish| D3 D1 --> OUT D2 --> OUT D3 --> OUT
Where each piece lives
Both halves are stored in Leed and both are copied into your site repository when you publish. The copy is what the site builder reads; the CMS record is what you edit.
| Piece | Stored in the CMS as | Published to the site repository as | Who writes it |
|---|---|---|---|
Page type, including documentationConfiguration | A page type record | src/{page type path}/{last path segment}.11tydata.json | You, on the page type’s own panel |
| Page type summary row | Part of the page type record | An entry in src/_data/pageTypeList.json | Leed, on every page type publish |
| Left-navigation menu | A menu record with its own id | An entry in src/_data/menu.json, keyed by the menu’s name | You, in the Design workspace’s Documentation section |
| Each page | A page record and its revisions | src/{page type path}/{folders}/{page slug}.md, with JSON frontmatter | You, in the editor; Leed composes the file location |
| The documentation layout | Nothing — it is a system file | Nothing; it lives inside the site builder | Leed |
Two consequences of that table are worth carrying with you.
The first is that a set is three artifacts and therefore three publishes: the page type, the menu, and the pages. They are independent, they can be published in the wrong order, and each one being stale produces a different and confusingly partial failure. Publishing a Documentation Set is the page that pays this off, and it is worth reading before your first launch rather than after it.
The second is that menu.json is keyed by the menu’s name, not its id, and publishing merges into that file without ever removing a key. Renaming a menu after its first publish leaves the old key behind forever, and the site keeps rendering from it. Name the menu once.
What a set gives you that a folder of pages does not
Documentation pages are rendered by a fixed system layout, leed-documentation.hbs. Leed deliberately does not create that file in your repository — it is resolved inside the site builder, not a template you author. What it assembles for every page in the set:
- A left sidebar built from the bound menu, with the current page highlighted, its ancestor folders expanded, and a filter box for finding a page by name.
- Breadcrumbs, made from the current page plus the folders above it. The “home” crumb appears only when the set’s Starting Page is set.
- Previous and next links, following a depth-first walk of every menu item that carries a link. Folders are skipped; their children are not.
- An on-page table of contents built from the page’s
##and###headings, with a copy-a-link control on each heading. - A search box over the set’s own content.
- A Docs MCP endpoint, served from
/mcpon your documentation site, so a reader’s AI client can browse and search your documentation the way a person browses the sidebar — described at Docs MCP: AI Access for Your Readers.
None of these is a template you write, and none of them can be assembled out of ordinary pages and a site menu. What your readers actually get from the assembled shell is described in What Your Visitors Get; the controls on the page itself are covered in Documentation Reading Experience.
Documentation sets and API sets
One predicate decides all of the above: the page type’s kind is either documentation or api. Both get the shell, the sidebar, the breadcrumbs, the previous/next chain, the table of contents and the MCP endpoint, from the same code. The difference is where the page bodies come from.
| Behavior | Documentation set | API set |
|---|---|---|
| Page bodies | Written by you in the editor | Generated from an OpenAPI specification |
| Content Locked | Optional, off by default | Forced on and not switchable — the panel says “API content is generated from its spec and is always read-only” |
| Layout | leed-documentation.hbs | leed-documentation.hbs |
| Left menu | Auto-created on the page type and bound for you | The same, with one item per endpoint |
| Spec sidecar | None | Each page ships a co-located .openapi.yaml beside its markdown, and a base spec for the set |
| Editor access | Full | Read-only; the set is regenerated by re-importing the spec |
| Required fields | summary is required | Nothing is required |
Because an API set is regenerated from a specification, its pages carry a fixed slug — but the menu still decides where they are filed, so an imported set can be reorganized into folders like any other. API Reference Pages covers the import and what the generated pages contain.
navMenuId is derived, never set
A page type also carries a field called navMenuId. It is a read-only projection: Leed recomputes it from documentationConfiguration.menus.left on every save of the page type, with no fallback to a company default. You never set it, nothing you set it to survives a save, and any tool offering it as an editable field is offering you nothing. If you want to change which menu drives a set, change the Left Menu field on the page type.
What is not part of a set
Three things sit next to a documentation set and are commonly mistaken for parts of it.
The CSS behind a theme name. Picking color-theme-teal on the page type puts that class on the page and nothing more; the built-in themes ship with the site builder, but a name you invent means nothing until you write the utility that defines it. That is a file in your own repository, and Custom Documentation Themes is where the CSS side is taught.
The header and footer templates. A set’s chrome can be replaced wholesale by adding two files to your repository, which is how a documentation set ends up wearing the same header as the rest of your marketing site. The files, the flags they take and the tier gate on them are covered in Customizing the Documentation Header and Footer; what you configure from the CMS is in Documentation Header, Footer and Logos.
The site’s own header and footer menus. A set has a Top Menu and a Bottom Menu slot as well as the left one, and those are ordinary site menus, placed by the documentation chrome rather than by your templates — see Menus and Navigation. Only the left menu is special, because only the left menu decides URLs.
Building the pair for the first time takes five explicit settings on the page type, and skipping any of them ships a set that renders an error page instead of your documentation. Creating a Documentation Set walks that flow in the order that works.