Configuring a Page Type

Expanding a page type on Settings → Page Types opens its settings panel. This page is the field-by-field reference for that panel.

The panel is different for each kind. A posts type has roughly twenty controls; a documentation type has eight plus a configuration block; an API type has four plus a configuration block and a delete control. Every section below marks which kinds a field exists on, and the matrix at the end of this page collects that in one table. Edits autosave — there is no Save button — and each field’s row in the matrix also says whether the change needs a deploy to reach your site.

Fields by kind

API only means the field exists in the data model and reaches your published site, but has no control on this screen — you set it through the API or an MCP client (create_page_type and update_page_type). Publish-tracked means a change queues a Page type: … entry for that type on the Deploy screen, one per changed type; the rest take effect in the CMS the moment you save and never queue anything. The server applies the same rules whichever route a change takes, so the Settings screen, the API and MCP all refuse the same things — a page type’s kind, for one, can never be changed once it is created.

Identity

Name

The display name in the CMS, and the name your templates see in pageTypeList.json. Renaming is safe — it changes no URL — but it does mark the type as needing a publish, because the name is site-facing data.

Slug and the slug lock

The slug is the URL prefix for the entire section. A page type whose slug is blog puts every one of its pages under /blog/.

It is validated against ^([a-z0-9]+([-.][a-z0-9]+)*)(\/[a-z0-9]+([-.][a-z0-9]+)*)*$ with a 150-character cap, or may be empty for a section that sits at your site root. Segments are lowercase alphanumeric with dashes or dots inside them, and / is allowed between segments — which is how a versioned API set gets a nested root like docs/api/1.2.0.

Redirect Index

What a visitor should get when they hit the section root — /blog/ with nothing after it. Four forms are accepted:

Whatever you set becomes two rules in your site’s _redirects file — one for /{slug}/ and one for /{slug}/index.html — both issued as 302 (temporary), not 301. Leave it empty and the section root is served by whatever index template your repository has for it.

Documentation and API types have no Redirect Index field. Their section root redirects to the set’s own starting page instead, set in the documentation configuration block — see Aliases and Redirects.

Layout

The Handlebars layout file that renders pages of this type, relative to your repository’s _layouts directory. Posts types only.

Documentation and API types have no Layout field: they are pinned to leed-documentation.hbs, and Leed deliberately does not create that file in your repository. It is a system layout resolved inside the site builder. Pointing a documentation set at a file of your own does not work, because the name it stores becomes a Handlebars partial path rather than a path to a file you author. Layouts and Page Types covers what a posts layout has to contain.

Labels

Labels attached to the page type itself rather than to a page. They reach your templates and feeds for the whole section, which is useful for a section-level topic or a routing tag. Posts types only.

Required fields

Four controls decide what an author must supply before a page of this type can go out:

• Feature Image Required
• Summary Required
• Keywords Required
• Form Attachment — a listbox with Not Allowed, Optional and Required

They are enforced at publish and at schedule, not while editing. A page missing something comes back as a 400 naming exactly what is missing:

{ "error": "Missing required fields", "missingFields": ["summary"] }

The stored shape is small, and this is what the API sees:

{
  "featureImage": false,
  "form": "NotAllowed",
  "summary": true,
  "keywords": false
}

Documentation types default to summary-only, which is why a documentation page publishes without a feature image but refuses to publish without a summary.

Editor formatting options

Posts types carry a pill row of nine toggle buttons under the heading Editor Formatting Options, described in the panel as “Toggle which toolbar buttons are available for this page type.” Turning one off removes that block’s button from the editor toolbar for every page of the type.

The consequence that matters more than the toggles themselves: content written through the API or by an AI agent that uses a disabled feature is rejected, not silently stripped. The request comes back as a 400 reading “This page type does not allow: Table, Alert. Allowed formatting features: Code Block.” So the toggles are a real content contract, not a UI convenience — if you disable tables on your blog, nothing can put a table on a blog page.

This setting applies to posts types only

The pill row renders only on the posts panel, and that matches enforcement exactly: the server-side check returns early for any page type that is not posts. A documentation or API page can use every block regardless of what is stored on its type. If your documentation pages need alerts, tables, tab groups and diagrams — and they will — there is nothing to switch on.

Which toolbar buttons an author actually sees, and what happens when they reach for a disabled one, is the reader-facing half of the same setting: What Each Page Type Lets You Format.

Section behavior

Five checkboxes on posts types (one of which documentation types share):

Company-default overrides

The Configuration Overrides block on a posts type lets the section depart from your workspace defaults. Leave a field empty and it inherits; the placeholder shows the inherited value followed by (default).

The values a blank field falls back to are set once, workspace-wide, in Default Content Configuration.

Aliases on a page type

A page type can carry alias roots. Each one becomes a wildcard redirect for the whole section in your site’s _redirects file:

/{alias}/*    /{slug}/:splat    301

So an alias of articles on a page type whose slug is blog sends /articles/how-we-ship/ to /blog/how-we-ship/, permanently, without you listing a single page. That is the tool for renaming a section — quite different from a per-page redirect, which follows one page as its slug changes. Compare Aliases and Redirects.

There is no control for section aliases on the Page Types screen today; they are set through the API or an MCP client. Per-page aliases do have a control, in the editor’s Page settings tab.

Documentation configuration

Documentation and API types replace the posts overrides with a Documentation Configuration Overrides block: theme, code theme, font, layout, logos, the header button, the starting page, the search index and the three menu slots. Every field, its type and its default is listed in Documentation Configuration Reference — that page owns them. Three things belong here instead, because they are facts about the page type rather than about documentation.

Company defaults are inherited. Your company’s documentation defaults are published in src/src.11tydata.json, and each page type’s own block, in src/{slug}/{slug}.11tydata.json, is deep-merged over them. A field you leave unset on the page type therefore takes the company value on the published site. Three keys — openAPI, tabGroups and highlighter — are company-wide only and never stored on a page type.

Set on the page type only what should differ. The panel shows each inherited company value as a placeholder, or as a Company default (…) option at the top of a pick list, and that value does publish. Choosing it stores nothing on the page type, so a later change to the company default reaches the set too.

Two asymmetries are worth knowing before you fill the block in:

• menus.top and menus.bottom inherit your company defaults; menus.left never does. A documentation set’s left menu is always its own. Leed creates one for you when the type is created, unless the create request names an existing menu in documentationConfiguration.menus.left, which binds that menu instead — it must exist and must not already belong to another set. Creating the type also creates a search index for the set and binds it. Deleting a documentation or API type keeps its menu: the set’s pages are pruned from it and it is renamed … (unbound).
• tabGroups is company-wide only. Define tab groups in your company’s documentation defaults. The editor’s Tab Group menu and the build both read that copy, and a page type cannot carry its own.

Custom theme, code-theme and font names

Two facts belong next to that badge, because they produce a different error:

• The stored value is the full prefixed class — color-theme-leed, code-theme-leed, font-noto-sans — while the bare name after the prefix is validated against ^[a-z0-9]{1,32}$. Lowercase letters and digits only, no dashes. So color-theme-leed-ai is rejected with a 400 on every plan, not a 402: “Invalid colorTheme: a custom name must be lowercase letters and numbers only, at most 32 characters.” One dash too many looks like a billing problem and is not.
• layoutName accepts no custom value at all, by design, because the builder turns it into a Handlebars partial path.

The catalogs — and what happens when you type a name that is not in them — are in Themes, Fonts and Code Themes. A custom name only means anything once matching CSS exists in your repository, which is Custom Documentation Themes.

The two locks

Two independent checkboxes, each saving immediately with no publish, each restricted to Administrators and Content Publishers. Navigation Menu Locked exists on API types only: the panel shows it only for an API set, and the server refuses it on a posts or documentation type.

The panel spells both out. Content Locked reads “No new pages can be added to this page type, and existing pages become read-only.” Navigation Menu Locked reads “Pages in this set can’t be reordered, moved, or removed from its navigation, and folders can’t be renamed. Presentation settings (tooltip, icon, expanded) stay editable.”

Content Locked is forced on and disabled for API types. 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.”

Navigation Menu Locked is what keeps an API set’s URLs — which its OpenAPI import owns — immovable, the right state for a set other people link to. Left Navigation Menu shows what an editor sees while it is on.

Per-type access overrides

Below the settings, each page type carries a row of role-override pickers — Content Manager, Approver and Contributor — that elevate a chosen team member on this page type alone. Someone who is Read Only everywhere else can be a Contributor on your blog. The grant is live in the CMS immediately and never needs a deploy.

How overrides combine with a person’s base role — the stronger of the two always wins — is on Resource-Level Access Overrides.