Now with AI-powered page building via MCP Server

Managing pages

Pages form a tree. How slugs derive from parents, what a page type controls, and the draft-publish cycle.

Pages are a tree, not a list. Each page has a parent, and that single fact decides its URL, its layout and where it appears in navigation.

Slugs come from the tree

You do not type a full path. You give a page a leaf segment, and the full slug is composed from its ancestors:

/docs                 leaf: docs
  /docs/blocks        leaf: blocks
    /docs/blocks/fields   leaf: fields

Which means moving a page moves its URL - and every URL beneath it. Reparenting /docs/blocks under a different section recomputes the slug of every child, grandchild and so on, in one operation.

That is exactly what you want during a restructure and exactly what bites when you did not expect it. Before reparenting a branch, know what links to it: nothing inside cmssy will stop you, because the operation is correct - it is the outside world that has the old URLs.

Layout is inherited

A page either owns its header and footer or inherits them from its parent. Set them once at the root and the whole tree has them.

Override only where a section genuinely differs. Every override is a place that stops receiving future changes to the shared layout, so a site with overrides everywhere is a site where updating the header means visiting twelve pages.

Page types

A page type is a template with rules. Which types exist is per workspace; a common starting pair looks like this:

  • Page - allowChildren: true. The general-purpose type; can have children, so it can act as a section.
  • Post - allowChildren: false. A leaf. Blog entries do not nest, and the type enforces that rather than relying on discipline.

Two more properties matter:

  • urlPrefix - prepends a fixed segment to every page of that type, so a type can live under /blog without each page carrying it.
  • Custom fields - structured values that belong to the page rather than to any one block: a publish date, an author reference, a reading time. Blocks render content; custom fields describe the page itself.

Draft and publish

Every edit lands in a draft. The public API only returns published content, so an unfinished page is invisible until you say otherwise.

  • Publish - promotes the draft to live, content and layout together.
  • Unpublish - takes the page off the public site. It still exists and is still editable.
  • Revert to published - throws away the current draft and restores it to the live version. This is the undo for "I edited the wrong page."

Revert discards draft work permanently. If the draft holds anything you might want, copy it out first - there is no second copy behind it.

What breaks quietly

An unpublished parent does not hide its children. Publishing state is per page. A published child under an unpublished parent stays reachable at its full URL, and the URL still contains the parent segment. If you meant to take a section offline, take the whole subtree offline.

Next steps