Page Types

Every page in Leed belongs to exactly one page type, and the page type decides four things at once: the URL prefix for the whole section, the layout that renders it, which formatting the editor offers an author, and how the section behaves on your published site — feeds, autoposting, recommendations, autolinking. You manage them in Settings → Page Types.

Most workspaces need three or four. A blog. A docs set. Perhaps an API reference, a small set of landing pages and, on Growth and up, an internal handbook that never reaches the site. A new workspace starts with only one, Root Pages, a posts type for pages at the top level of your site; you add the rest. Creating one is cheap; changing its kind afterwards is impossible, so it is worth two minutes of thought first. In Claude Code with the Leed plugin, /leed:create blog and /leed:create documentation add a whole blog or documentation set in one step — the page type, its menus, its search index and starter templates — which is the quicker route when you want the section to render well from its first page.

The four kinds

When you create a page type you choose its Type of Page, and that choice determines which settings the type has for the rest of its life.

Posts

A posts type is the general-purpose kind and has the largest settings panel. Its Layout is a file that lives in your site repository, so the markup is entirely yours. Left unset it is empty.hbs, which renders the page content with no site header or footer around it. That is deliberate: there is no starter design to strip out, so the site looks like whatever layout you write. A layout of your own must be in src/_layouts/ on your staging branch before the page type can name it. You get the section-behavior checkboxes — Enable Recommendations, Enable Autolinking, Show In Feeds, Autopost New Pages, Do Not Render — and the full set of company-default overrides: pagination, sitemap priority, label sitemap priority, social title and description, reading speed, date format and the AI image theme guide.

It is also the only kind that carries the Editor Formatting Options row: nine toggles deciding which advanced blocks — code, diagrams, math, alerts, icons, tab groups, iframes, collapsibles and tables — an author can insert on pages of this type.

Documentation

A documentation type is a documentation set, which is a page type plus a left-navigation menu, not a page type on its own. Three consequences follow, and two of them surprise people:

• Its Layout is fixed to leed-documentation.hbs and there is no Layout field on the panel. Leed does not create that file in your repository, on purpose — it is a system layout resolved inside the site builder, not a template you author.
• The moment you create the type, Leed creates a menu named after it and binds it as the set’s Left menu. It appears in the Design workspace’s Documentation section straight away, empty and ready to fill. A type created over the API, MCP or the CLI can instead name an existing menu in documentationConfiguration.menus.left, and that menu is bound in place of a new one.
• Its required-field defaults are summary-only, because a documentation page rarely wants a feature image or keywords.

The settings panel is much shorter than a posts panel: Name, Slug, Enable Autolinking, Content Locked and the four required-field controls, with a Documentation Configuration Overrides block beside them covering the reader-facing docs site — theme, font, code theme, layout, logos, header button, starting page, search index and the three menu slots.

API Documentation

An API type behaves like a documentation type on your published site, but its settings panel is shorter still: Name, Slug, the two locks, an API Documentation Configuration Overrides block, and a danger zone that permanently deletes the set — every page in it and the committed OpenAPI spec files. Its navigation menu survives the delete: the set’s pages are pruned from it and it is renamed … (unbound).

Content Locked is forced on for an API type and the checkbox is disabled. The panel explains why: “API content is generated from its spec and is always read-only — this cannot be turned off for API documentation sets.” Pages of an API type are regenerated from the specification, so hand-editing them would be overwritten.

The code-snippet languages shown on generated API pages are configured once for the workspace in Settings → Content, not per API page type.

Internal

An internal type is organized like a documentation set — a page type plus a same-named left menu — but nothing in it is ever published. Its pages never reach your site repository, your published site, the Docs MCP, reader search or the site AI agent; instead of publishing, an author locks a revision and revises it to edit again. Creating one needs the Growth plan or above.

Its slug lives under a reserved root: you type one segment, such as handbook, and Leed stores it as internal/handbook. Its settings are fixed at creation — every editor formatting option on, no required fields, layout empty.hbs, and autolinking, recommendations, feeds and autoposting off — so its panel shows only Name and Slug, with the bound Navigation Menu read-only and the note Internal pages are never published. Their other settings are fixed. Because an internal page is never published, the slug never locks. Internal Content covers the whole feature: creating a set, locking and revising, search and deletion.

Creating a page type

The create button on Settings → Page Types opens the Create Page Type dialog, which asks for three things and nothing else. Its description points to /leed:create in Claude for a blog or documentation set that comes with starter templates; the dialog itself creates the bare page type:

• Name — placeholder e.g. Documentation. This is the display name in the CMS and the name your templates see.
• Path — placeholder e.g. documentation. This is the section’s URL prefix. It auto-fills from the name, slugified, and stops auto-filling the moment you edit it yourself.
• Type of Page — Documentation, Posts or Internal. The dialog does not offer API Documentation: an API set is only complete when it is built from a specification, so the OpenAPI import is how one is created. Choosing Internal shows where its pages will live, /internal/<path>; below the Growth plan it shows an upgrade prompt instead and the Create button stays disabled.

A page-type slug is validated against this pattern, with a 150-character limit, and may also be empty for a section that sits at your site root:

^([a-z0-9]+([-.][a-z0-9]+)*)(\/[a-z0-9]+([-.][a-z0-9]+)*)*$

blog              ✓  a single segment
release-notes     ✓  dashes are allowed inside a segment
docs/api/1.2.0    ✓  nested roots and dots are allowed (used for versioned API sets)
Blog              ✗  uppercase
my_section        ✗  underscores
/blog             ✗  no leading slash

Nested paths such as docs/api/1.2.0 are legal in the data model and are what a versioned API set uses, but the Path field in the Create Page Type dialog slugifies whatever you type — so docs/api/1.2.0 becomes docs-api-1-2-0 there. A nested root is set through the API or by the OpenAPI importer, not through this dialog.

The internal root is reserved for internal page types. Any other kind is refused a slug of internal, or one beginning internal/ or internal., with The internal/ path is reserved for internal page types, so a published section can never collide with internal content. An internal type’s slug works the other way: you type one segment, such as handbook, and Leed stores it as internal/handbook. It cannot contain / and cannot be empty.

Outside the dialog, leed settings pagetype create --type <kind> --name <name> --slug <slug> creates any kind from the CLI, --type internal included, and the create_page_type MCP tool creates a posts, documentation or internal type but never an API type. An internal type created either way follows the same rules as in the dialog: the slug is one segment stored as internal/<slug>, a same-named menu is created and bound, and below the Growth plan the request is refused with a 402. The older leed site create-page-type command has been removed.

What happens when you create one

Creating a page type is not just a database row. Two of its side effects catch people out, so they are worth listing in order:

1. If the kind is Documentation, API or Internal, a left-navigation menu is created first — unless a documentation or API request named an existing one to bind; an internal type always gets a new menu of its own. It is named after the page type and bound to the type’s Left slot before the type itself is saved. That ordering is deliberate: if the menu name collides with an existing menu, the request fails cleanly and no orphaned page type is left behind.
2. The type is created and immediately marked as having unpublished changes. It shows the amber indicator on the Page Types list right away, because it exists in the CMS but not yet on your published site. A documentation or API type also gets its own search index, created and bound to the set. An internal type is the exception: it is never marked, gets no search index, and steps 3 and 4 do not happen for it, because nothing of it is ever written to your repository.
3. Files are committed to your site repository. Every kind gets a data file (src/{slug}/{slug}.11tydata.json) and a section index page (src/{slug}-index.hbs) — unless your repository already renders the section root itself, from src/{slug}/index.* or src/{slug}.*, in which case no index page is added. A posts type created without a layout of its own gets empty.hbs, written to src/_layouts/ when your repository does not already have it. A posts type created over the API, MCP or the CLI with a layout of its own gets neither that file nor the index page: the layout had to exist already, and its list page is yours to supply — the /leed:create recipes write both. Documentation and API types deliberately get no layout file, because theirs is a system layout. A workspace with no site repository skips this step, and if committing fails the new type is rolled back rather than left half-created.
4. Your repository’s staging branch is rebased so the new files are in place for the next build.

The scaffolded files are starting points, not fixed contracts — you are expected to edit them. Page-Type Scaffolding Templates describes each template and what it renders. A posts type names a layout file that lives in your repository, and Layouts and Page Types covers what that file has to contain.

Defaults each kind starts with

Required fields decide what an author must fill in before a page can be published or scheduled. Each kind starts with a different set, chosen to match what that kind of content actually needs:

Whatever the kind, a new type is stored with Enable Autolinking on, Show In Feeds on, Autopost New Pages on, Enable Recommendations on, Do Not Render off and Content Locked off — though only a posts panel surfaces controls for the feed, autopost, recommendation and render flags. An API type’s Content Locked is then forced on by the server regardless of what is stored, and Navigation Menu Locked exists on API types only. An internal type is the exception to all of this: autolinking, feeds, autoposting and recommendations are stored off, every editor formatting option is on, and none of it can be changed after creation. Because an internal page is never published, its required fields never apply.

Every one of these fields — plus the overrides, the two locks and the documentation configuration block — is enumerated field by field in Configuring a Page Type.

Page types and access

A page type is one of the resources you can grant a team member an elevated role on. Someone whose base role is Content Writer can be made a Content Publisher on your blog alone, and stay a writer everywhere else. The grant lives on the page type’s panel, below its settings, and it takes effect in the CMS immediately with no publish.

What you cannot do

Three honest limits, all of them structural rather than oversights:

• You cannot change a type’s kind. Posts, documentation, API and internal differ in what the site builder does with them, not just in which fields the panel shows. Move the content to a new type instead — though a page can never be moved across the internal line, into or out of an internal type.
• You cannot change a type’s slug once pages of the type have published. The field locks itself. If you must move a section, create the new type, move the pages, and put a section-wide alias on the old root so the old URLs keep resolving.
• A documentation or API type cannot use a custom layout file. Its layout name becomes a Handlebars partial path inside the site builder, not a path to a file you author — so pointing it at your own .hbs file does not do what it looks like it does. You customize a documentation set through its configuration block and your own CSS, which is covered in Configuring a Page Type.

A documentation or API type is also only half of a documentation set; the other half is the left menu Leed created for you, which you fill in as described in Creating a Documentation Set. The type’s slug is the first segment of every URL in the section — see URL Paths and Slugs for the rest of the composition.