How Content Is Organized

Four things decide the shape of a Leed site, and everything else in this category hangs off them. A page type is a section — your blog, your docs, your API reference — and it sets the URL prefix, the layout and what the editor offers an author. A label is a tag that can turn into a topic index, a reading order, or an access boundary for your team. A menu is the navigation a reader clicks. A path is the URL a page lives at, together with every URL it used to live at.

You set them in four places: Settings → Page Types, Settings → Labels, the Menus section of the Design workspace (and Documentation, for a documentation set’s left menu), and — for paths, which you never type directly — Settings → URL paths & redirects, which is a read-only inventory of what Leed has composed for you.

The rest of this category is one page per lever. This page is the map.

This page uses page type, menu, label and path as technical terms with precise meanings; each is defined once in Core Concepts.

The four levers

flowchart LR
  P(["A page"])

  P -- "one per page" --> PT["Page type"]
  P -- "many per page" --> L["Label"]
  P -- "one entry per page" --> M["Menu"]
  P -- "one live URL per page" --> PA["Path"]

  PT --> PT1["The section it belongs to"]
  PT --> PT2["The layout that renders it"]
  PT --> PT3["What the editor offers the author"]

  L --> L1["Topic index pages it appears on"]
  L --> L2["The series it reads as part of"]
  L --> L3["Who on your team can edit it"]

  M --> M1["The navigation entry a reader clicks"]

  PA --> PA1["The one live URL"]
  PA --> PA2["Every earlier URL, kept as a redirect"]

The asymmetry in that picture is the whole point: a page has exactly one page type and appears at most once in one navigation menu, but it can carry as many labels as you like.

Each section of your site is one page type, and the page type decides both the URL prefix and what the editor offers — see Page Types for the three kinds and Configuring a Page Type for the field-by-field reference. Tag pages across sections with labels to build topic indexes and linked series in Labels and Series. Menus are what a reader clicks, and for a documentation set they are also what decides the URL — Menus and Navigation. And every URL Leed has ever assigned a page is kept, which is what makes renaming safe: URL Paths and Slugs.

How a URL gets composed

An ordinary page’s URL is its page type’s slug followed by its own slug: a page called Pricing FAQ in a page type whose slug is blog lands at /blog/pricing-faq/. Every Leed URL composes with a trailing slash.

A documentation page is the exception, and it is the one that surprises people. Its URL is the page type’s slug, then one segment for each folder it sits inside in the left navigation menu, then its own slug — so a page filed under a folder named Getting Started in a docs page type lands at /docs/getting-started/installing/. The segments come from each folder item’s name, slugified one segment at a time. They do not come from the folder’s title, which is only the hover tooltip, and they do not come from any field on the page.

A page’s stored path value holds only the folder portion of its URL — never the page-type slug and never its own slug. For every non-documentation page type it is empty, because those sections are flat by design.

Slugification, the de-duplication suffix Leed appends when two pages would compose to the same URL, and the composed result are all drawn once, on How a URL is composed.

What a label does that a page type cannot

A page belongs to exactly one page type. It can carry as many labels as you want. That single difference is why both exist: the page type answers what kind of thing is this and where does it live, and labels answer what else is it related to.

A label does three unrelated jobs, and you switch each on independently:

• A reader-facing topic index. Give the label a slug and it becomes something your templates can build an index page from.
• A series. Group a label’s pages into a reading order — an ordered multi-part series, or a running stream of announcements.
• An access scope. Grant a teammate an elevated role on everything carrying the label, without touching their base role.

All three are detailed on Labels and Series.

What changes immediately and what waits for a publish

This is the most useful orientation fact in the category, and it is not obvious from the screens. Some structural settings are rules the CMS enforces while you work — they bite the moment you save. Others are data your published site reads, so they sit as a pending change until you deploy.

Nothing in the right-hand column is live until you deploy it. The Deploy section of the rail collects every pending structural change into one list you can publish selectively — see Publishing Changes.

Two consequences are worth internalizing now. A page type marked with the amber unpublished indicator is not broken; it is waiting. And an access override you grant to a colleague works the second you grant it, so you never have to deploy to unblock someone.

Where the rest of the model lives

If your site is primarily a documentation set, the four levers assemble in a specific order — page type first, then its left menu, then folders, then pages — and that build order is the subject of What a Documentation Set Is. It is worth reading before you create anything, because a documentation set’s URLs come out of its menu.

Your templates read this same model as data. Page types, labels and menus each publish into your site repository as JSON that Handlebars can iterate — which is how a topic index page or a section listing gets built at all. How Templates Work covers the rendering pipeline those files feed.

The per-page fields — title, slug, summary, feature image, labels, authors — are set in the editor rather than here, and are covered in Page Settings.

Two smaller levers shape content without being part of the core four. Autolinks are a list of terms that the site build turns into links to pages you nominate, applied across whichever page types have autolinking enabled — see Autolinks. Journey stages are the funnel labels your workspace uses to describe where a piece of content sits in a buyer’s path — see Journey Stages. Neither changes a URL or a layout, which is why they sit outside the table above.