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 and a small set of landing pages. Creating one is cheap; changing its kind afterwards is impossible, so it is worth two minutes of thought first.

The Page Types screen in Settings, listing a posts type, a documentation type and an API type as collapsed panels

The three 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.

Kind	Use for	Layout	Navigation	What is distinctive
Posts	Blogs, articles, landing pages, release notes — anything that reads as a stream	A Handlebars layout file in your repository, named by you	None built in; a template places a site menu wherever you want it	The full company-default override set, feeds, autoposting, recommendations, and the Editor Formatting Options row
Documentation	Product docs, guides, knowledge bases	Fixed to `leed-documentation.hbs`, which Leed deliberately does not create in your repository	Leed creates a left-navigation menu named after the type and binds it for you	A documentation configuration block replaces the posts overrides; a page’s folder position in that left menu sets its URL
API Documentation	Reference pages generated from an OpenAPI specification	Fixed to `leed-documentation.hbs`	The same auto-created, auto-bound left menu	Content Locked is forced on and cannot be turned off; the panel carries a control that deletes the whole set

Posts

A posts type is the general-purpose kind and has the largest settings panel. You name a Layout file that lives in your site repository, so the markup is entirely yours. 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.
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, the two locks 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, the committed OpenAPI spec files, and its navigation menu.

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 → General, not per API page type.

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:

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, API Documentation or Posts.

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 Create Page Type dialog with Name set to Documentation, Path auto-filled to documentation, and the Type of Page select open

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:

If the kind is Documentation or API, a left-navigation menu is created first. 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.
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.
Files are committed to your site repository. Every kind gets a section index page (src/{slug}-index.hbs) and a data file (src/{slug}/{slug}.11tydata.json). A posts type additionally gets a scaffolded layout at src/_layouts/{slug}.hbs; documentation and API types deliberately get no layout file, because theirs is a system layout.
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:

Kind	Feature Image Required	Summary Required	Keywords Required	Form Attachment
Posts	on	on	on	Not Allowed
Documentation	off	on	off	Not Allowed
API Documentation	off	off	off	Not Allowed

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, Content Locked off and Navigation Menu 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.

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 and API 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.
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.