Page Type Reference

A page type is the record that decides what a page of that kind has, where it lives and how it renders. This page is the field list. Page Types is the concept, and Configuring a Page Type is the walkthrough in screen order.

The reference is separate for three reasons that the walkthrough cannot carry: several of these fields have no UI at all on some kinds, several are read only by the site build and change nothing until you publish, and a handful are derived by the server and cannot be set at any price.

How to read the tables

Applies to names which of the three kinds — Posts, Documentation, API — show the field.

Default is what a newly created page type gets. For several fields that differs per kind, and the row says so.

Read by names the actual consumer: the CMS, the site build through the page type’s own {slug}.11tydata.json, or the site build through the shared _data/pageTypeList.json. A field that only the build reads will not change anything until you publish; a field only the CMS reads will never appear in your repository no matter how many times you publish.

A blank value usually means inherit. The grayed text in an empty box is the company default rendered as placeholder text, not a stored value.

Three fields are not settable at all. They are listed rather than omitted, because a developer reading the API or an MCP response will see them and wonder.

Identity and URL

Two facts a reader otherwise learns the hard way. The slug is the URL root for every page of the type, so changing it moves the whole section — and once any of its pages has been scheduled or published, the CMS locks the field to protect those URLs. And how the rest of a page’s path is composed below that root is URL Paths and Slugs, which for a menu-bound documentation set is decided by the folder tree rather than by the page.

Kind and layout

Content rules

A missing required field is a 400 with a list, not a warning you can dismiss: publishing or scheduling returns {"error":"Missing required fields","missingFields":["summary"]} naming every field that is empty. The exact shape is on Common Error Messages.

Required fields by kind

Editor formatting options

Nine flags, and codeBlock is the only one that defaults on — which is why a brand-new Posts page type has a short toolbar. Every one of them applies to Posts page types only.

{
  "codeBlock": true,
  "diagrams": false,
  "mathBlock": false,
  "alert": false,
  "icons": false,
  "tabGroup": false,
  "iframe": false,
  "collapsibleBlock": false,
  "table": false
}

The second fact, which no other page states and this reference must: the flags are inert on documentation and api page types on all three surfaces, and there is no UI to set them there. The content API returns early unless the type is posts, the toolbar’s resolver returns nothing for a non-Posts type so every control shows, and Settings renders the toggle block for Posts types only. A documentation author looking for the switch that hid their tab button will not find one, because it does not exist for their page type.

Site behavior

Autopost New Pages defaults to on, which surprises people because the behavior behind it is a Growth feature. The setting is configurable on every plan and activates on your published site once your plan includes automatic social posting — it is not “off by default”, it is armed and waiting.

Shared settings

The same nine values that live at the bottom of Settings → General appear on every page type as Configuration Overrides. Leave one blank and the page type inherits the company value; fill it in and the page type wins for its own pages.

Which of these actually reach the site when you override them on a page type is the question the Read by column answers per row, and Default Content Configuration works through it end to end. It is worth reading before you override Page Size and wonder why the built listing did not change.

Locks

Either lock may be set or cleared only by an Administrator or a Content Publisher, and the guard is shared by the create and the update route so they cannot drift. Each refusal has an exact message, cataloged on Common Error Messages — This page type is Content Locked; existing pages are read-only. on a write, This page type is locked; no new pages can be added. on a create, and Only an Administrator or Content Publisher can lock or unlock a page type. when you lack the role.

Note the reach of Content Locked: it makes existing pages read-only, not merely the section closed to new ones. If you want a section frozen against new pages but still editable, that is not what this flag does.

Documentation and API fields

documentationConfiguration is one object on the page type, and every key in it is defined in full on Documentation Configuration Reference. It appears here as a pointer table with the four cells that no other page will state.

Three of those keys carry a plan condition rather than a plan gate: colorTheme, codeTheme and font accept any of the built-in names on every plan, and need Starter only when you introduce a name of your own. The gate fires on change, so re-saving a stored custom value, clearing it, or swapping one built-in for another passes on any plan — Themes, Fonts and Code Themes has the built-in list.

Fields you cannot set

What reaches your repository

Three destinations, and knowing which one a field takes is the answer to “I changed it and my template still can’t see it”.

src/{slug}/{lastSegment}.11tydata.json — the page type’s own Eleventy directory data file, written on publish. It carries exactly three things: dateFormat, ogCard and documentationConfiguration. The file is named after the last segment of the slug, because an Eleventy directory data file must be named for the directory it sits in — so a page type at docs/api/1.2.0 writes src/docs/api/1.2.0/1.2.0.11tydata.json.

{
  "dateFormat": "MMM D, YYYY h:mma z",
  "ogCard": {
    "title": "Leed Documentation",
    "description": "Everything you can do with Leed."
  },
  "documentationConfiguration": {
    "layoutName": "charlie",
    "colorTheme": "color-theme-leed",
    "codeTheme": "code-theme-leed",
    "menus": { "left": "leeddocs" },
    "startingPage": "/docs/start-here/what-is-leed/"
  }
}

src/_data/pageTypeList.json — one shared file, keyed by page type id, holding the list-level fields: slug, name, layout, description, labels, aliases, redirectIndex, noRender, includeInFeeds, autolink, autopostNewPages, allowRecommendations, sitemapPriority, labelSiteMapPriority and navMenuId. This is what a template reads when it needs to know something about a different section than the one it is rendering — Global Site Data.

Everything else stays in the CMS. type, requiredFields, editorFormattingOptions, both locks, paging, readingWpm and aiTheme are never written to your repository, so no template and no build plugin can read them. If you overrode Page Size on a page type and the built listing did not change, this paragraph is why.

What lands in a page’s front matter — as opposed to its page type’s — is a separate contract, enumerated at Front Matter Reference.