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. Publish-tracked means a change queues a Page Types entry on the Deploy screen; the rest take effect in the CMS the moment you save and never queue anything.

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.

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.

The page type is the only durable home for this block. A copy written at company level is read by the CMS editor, but the site build never reads it from there: the company record’s site-builder projection does not carry documentationConfiguration at all, and every writer of the site-wide data file re-serializes the whole file from that projection — so a hand-added block is deleted from your repository by the next settings save, batch publish or billing change. The page-type copy round-trips into src/{slug}/{slug}.11tydata.json on publish and survives.

Set the complete block on the page type, not a delta. That means layoutName, colorTheme, codeTheme, font, menus.left and menus.top and menus.bottom, header.button, logo.light and logo.dark, startingPage and tabGroups. The panel shows an inherited company value grayed as (company default), which reads as “this is set” and is not — it displays, it does not publish.

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

• menus.top and menus.bottom inherit your company defaults in the panel; menus.left never does. A documentation set’s left menu is always its own, which is why Leed creates one for you when the type is created.
• tabGroups has to exist in both places. The editor’s Tab Group menu reads the company copy, while the build reads whatever lands in the page’s merged data. A group defined only on the page type is invisible in the editor; a group defined only at company level is not carried into the docs data file. Define it in both.

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.

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 the setting that makes a published documentation set’s URLs immovable, which is 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.