Page Hierarchy

A website becomes easier to navigate when its structure reflects how people look for information.

A handful of pages can live comfortably beside one another. As a website grows, that stops being enough. Product information develops subtopics. Documentation gains sections. An introductory page becomes the starting point for several more detailed explanations.

VerdinCore lets you organize Pages into parent–child relationships, assign their order, and give each page an address that reflects its place in the site. The hierarchy is part of the content model, not a collection of URLs that someone has to assemble by hand.

The result is a clearer structure for editors to maintain and for visitors to explore.

From isolated pages to a meaningful structure

Imagine a product website that begins with four pages: Product, Features, Architecture, and Support. Over time, the Features section expands to explain media handling and content editing, while Architecture gains its own technical subjects.

Instead of maintaining a flat list, you can express those relationships directly:

Product
├── Features
│   ├── Visual Editor
│   └── Media Management
├── Architecture
│   └── Rendering
└── Support

Each item is still a normal VerdinCore Page, with its own title, content, publication state, and editable URL slug. What changes is its place in relation to other pages.

A visitor exploring Media Management can understand that the page belongs to Features, which belongs to Product. An editor can see the same relationship when organizing content.

This is especially valuable for websites where information is meant to be revisited: product documentation, service descriptions, knowledge sections, and other lasting content.

Two controls: Parent Page and Page Order

You do not need a separate navigation-building application to define the basic relationships. The Page editor includes two straightforward controls:

Control	What it determines	Example
Parent Page	The Page above the current one in the hierarchy, or Top level if it has no parent.	Media Management belongs under Features.
Page Order	The Page's position in ordered page collections and navigation structures.	Visual Editor appears before Media Management.

Parent Page is selected from existing Pages. Page Order uses a numeric control with increase and decrease buttons. Lower order values come first; when values are equal, the application falls back to title and then identifier for a consistent order.

Those two decisions are independent. Changing the order does not change a Page's URL. Changing the parent can.

((Screenshot from VerdinCore Admin > Edit Page: open a sample Page titled "Media Management"; show the Parent Page selector with "Features" selected in the right sidebar and the Page Order numeric stepper in the left sidebar. Include the Page title and enough of the editor to establish context. Capture around 1920 × 1080; hide account names, internal links and unpublished business information. Suggested caption: "Choose a parent and set page order directly from the Page editor."))

A hierarchy that protects itself

The editor does not allow a Page to become its own parent or be moved beneath one of its descendants. Those assignments would create a circular structure with no meaningful beginning.

VerdinCore excludes the current Page and its descendants from the available parent choices when editing it, and also validates parent relationships when saving.

It is a small safeguard with an important purpose: a content structure should remain coherent even as it is reorganized.

URLs that follow the hierarchy

A Page has a slug, such as media-management. VerdinCore combines that slug with those of its ancestors to form the Page's full path.

For our example, the resulting addresses could be:

/product
/product/features
/product/features/visual-editor
/product/features/media-management
/product/architecture
/product/architecture/rendering

You do not have to type the complete path into each child Page. You maintain the parent relationship and the Page slug; VerdinCore resolves the hierarchy when building the public address.

A few practical details matter:

Page slugs are editable, so they can be short and readable.
A Page slug must be unique across Pages in the current implementation, even when Pages belong to different branches.
A Page without a parent sits at the top level of the hierarchy.
Changing a Page's parent or slug changes its resolved path. Moving a parent can therefore affect the addresses of its descendants as well.

This approach connects the structure visible to editors with the addresses visitors actually use. It also means reorganization deserves care: published URLs are links people may already have saved, shared, or indexed.

A hierarchy is not only a way to arrange a menu. It establishes where a piece of information belongs.

Navigation and breadcrumbs share the same context

The hierarchy is also available to the public-facing presentation layer. In the supplied VerdinCore theme, the Explore navigation can display nested Pages, with children grouped beneath their parents. Page order determines their sequence.

((Screenshot from a public VerdinCore website > open the Explore navigation popover with a sample three-level Page structure. Show the top-level "Product" Page, its "Features" child, and at least two Pages beneath Features; keep the site header visible. Capture around 1440 × 900, with readable labels and no private Pages. Suggested caption: "Nested navigation reflects the relationships defined in the Page editor."))

On an individual Page, breadcrumbs can make that context visible again. For example:

Home / Product / Features / Media Management

The breadcrumb trail is derived from the Page's hierarchy, including the names and paths of its ancestors. Visitors can see both where they are and how the current Page relates to the larger site.

((Screenshot from a published public Page > open "Media Management" within a three-level example hierarchy. Frame the Page title and the full breadcrumb trail, including Home, Product, Features and the current Page. Capture approximately 1440 × 750, hiding admin-only UI. Suggested caption: "Breadcrumbs give visitors context without requiring editors to build each trail manually."))

Navigation presentation is theme-dependent. The relationship and ordering data are part of VerdinCore, while the chosen theme determines how that information is displayed.

Give a section its own landing page

Not every parent Page needs to contain every detail about a subject. Sometimes its job is to introduce a section and direct visitors to the right child Page.

The supplied theme includes a section labeled In this section that can list a Page's directly related, published child Pages. Each entry can show its title and excerpt, turning a parent Page into a useful starting point rather than an empty container.

For example, a Features landing page might briefly explain the product's editing capabilities and then offer links to Visual Editor and Media Management. Those child Pages can develop independently without making the parent Page excessively long.

((Screenshot from a published public parent Page > scroll to the "In this section" area showing at least three sample child Pages, each with a short excerpt. Include the section heading and the complete row of child cards. Capture around 1440 × 850 and avoid real private content. Suggested caption: "A parent Page can introduce a subject and point readers toward its published child Pages."))

This is a good example of structure doing useful work: the relationships already exist, and the theme can use them instead of requiring authors to maintain a separate list of links in the Page body.

Reorganize thoughtfully as the website grows

Page hierarchies are not permanent monuments. A growing website may discover that a topic fits better in another section, or that a broad Page now deserves several children.

A typical reorganization might look like this:

Create a new parent Page for the subject, if needed.
Open each relevant Page and choose its new Parent Page.
Adjust Page Order to reflect the desired sequence.
Save the Pages and check their new public paths.
Review navigation, breadcrumbs, and any existing links to the moved Pages.

Important: The current source supports hierarchy-derived URLs; it does not establish automatic redirects from old paths when a Page is moved or renamed. Plan URL changes accordingly, particularly for established public content. Also verify the behavior of child Pages when changing the publication status or access settings of their ancestors.

For a step-by-step workflow, see Build a Page Hierarchy.

Structure without unnecessary ceremony

VerdinCore does not require editors to maintain page relationships in one tool, construct URLs in another, and duplicate the same hierarchy inside every article.

A Page knows its parent. It has an order. Its path and breadcrumb context can be derived from that information. The theme can turn the same structure into navigation and section listings.

A simple model, used consistently, can support a surprisingly rich website.

Continue exploring: Posts & Pages · Publishing Workflows · Build a Page Hierarchy