Page Tree

By Optimizely Education
Published: Feb 16, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Performance anchor: The "100-item rule" prevents database latency and editorial lag in high-volume environments.
Architectural split: Container pages decouple logical data storage from the visual navigation tree.
Multi-site logic: SiteDefinitions and unique start pages enable scalable governance within a single PaaS instance.
Inheritance control: The tree structure dictates both URL routing segments and granular security permissions.

Effective page tree organization in Optimizely CMS 12 is an architectural requirement that balances editorial efficiency with system performance. The page tree serves as both the visual representation of the website's navigation and the logical hierarchy for data storage and permission inheritance. For technical teams, designing a scalable tree structure is essential for maintaining high performance in enterprise PaaS environments.

1. Visual vs. Logical Hierarchy

The Optimizely page tree typically reflects the visual navigation structure of the website through the parent-child relationships of pages. However, sophisticated implementations often require a separation between what is navigable and what is structural.

Container Pages

Container pages are utilized to house logically related content that should not be directly accessible via a URL. These are defined as page types without an associated rendering template.

Purpose: Holding global settings, reusable snippets, or archived content.
Editorial UX: Container pages are visually distinguished in the CMS edit view (usually with a custom icon or greyed-out text) to indicate to editors that they are non-navigable.
Technical Mechanism: Because they lack a template, the routing engine will not resolve a URL directly to these nodes, and they won't appear in standard navigation loops unless explicitly queried.

2. Multi-site Architecture and Site Definitions

Optimizely CMS 12 PaaS supports multi-site configurations within a single instance. Success in this environment depends on a clear root-level architecture.

Site Definition Requirements

Unique Start Pages: Each site must have its own unique start page. These start pages cannot be nested under one another.
Root Node Mapping: Every site is mapped to a specific node in the tree using the SiteDefinition API.
Hostname Mapping: Unique hostnames must be associated with each start page node to ensure the routing engine directs traffic to the correct branch.

Accessing Site Data Programmatically

For multi-site implementations, avoiding hard-coded IDs is critical. Developers should use the SiteDefinition repository to resolve the context of the current request.

// Resolve the current site context in CMS 12
var currentSite = SiteDefinition.Current;
var startPageLink = currentSite.StartPage;
var siteName = currentSite.Name;

// Accessing the root page (useful for global settings containers)
var rootPageLink = currentSite.RootPage;

3. High-Performance Organization: The "100-Item Rule"

In enterprise sites with high content volume (e.g., news archives or product catalogs), the depth and width of the page tree significantly impact rendering performance and database load.

The 100 Children Limit

A fundamental technical best practice is to avoid having more than 100 content items below a single node. Exceeding this limit results in:

Edit Mode Latency: Slow loading of the page tree in the navigation pane for editors.
Database Stress: Increased SQL calls for the GetChildren method, as the system must materialize larger object graphs.
Search Overhead: Challenges in efficiently indexing and retrieving immediate children during programmatic traversal.

Strategies for Structuring Large Content Sets

When more than 100 items are required, use a structural "bucket" strategy:

Date-based Buckets: Structure items by year, then month (e.g., /News/2024/03/Article-Name/).
Alphabetical Bucketing: For dictionaries or glossaries, use initial-letter folders (e.g., /Glossary/A/Architecture/).
Category Folders: Use functional categories to divide the tree logically.

4. URL Routing and Segment Generation

Page URLs are generated hierarchically based on the URLSegment property of each node in the path.

Segment Inheritance: A page at path /Services/Cloud/Hosting inherits the segments of all its parents.
Duplicate Segment Prevention: Optimizely prevents duplicate segments within the same level of the tree to avoid routing conflicts.
Slug Management: Developers can customize how segments are generated from the PageName property to ensure SEO compliance across the entire site structure.

5. Governance and Permission Inheritance

The page tree acts as the primary vehicle for editorial governance. Permissions are inherited from the parent node by default.

Granular Control: By organizing the tree by department or functionality (e.g., a "Legal" container), technical teams can set access rights at the top-level node, ensuring that all child content adheres to the same security standards.
Bypassing Inheritance: For specific security requirements, the inheritance can be broken at any node, providing explicit access control for sensitive areas while maintaining the logical structure.

Conclusion

Organizing the Optimizely CMS 12 page tree requires a design that prioritizes both system performance and editorial clarity. By enforcing the 100-item rule, separating logical containers from visual navigation, and leveraging SiteDefinitions for multi-site governance, architects can ensure the CMS remains responsive and manageable as content volume scales.