Skip to main content
Optimizely Academy

End-user eLearning

Upcoming events

Certification

Partner training

Community

All Topics

Page Tree

  • By Optimizely Education
  • Published: Feb 16, 2026
  • Rating
    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 parent-child relationships. However, sophisticated implementations often require a separation between what is navigable and what is purely structural.

Container Pages

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

  • Purpose: Holding global settings, reusable snippets, or archived content that editors need to manage but visitors should never directly access.
  • Editorial UX: Container pages are visually distinguished in the CMS edit view - typically 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. They will not 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 established before content is created.

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 of the tree.

Accessing Site Data Programmatically

For multi-site implementations, avoiding hard-coded content IDs is critical. Use the SiteDefinition repository to resolve the context of the current request at runtime.

C#
// 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 - news archives, product catalogs, or knowledge bases - 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 under 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 under a single node, use a structural "bucket" strategy to distribute the load:

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

4. URL Routing and Segment Generation

Page URLs are generated hierarchically based on the URLSegment property of each node in the path. The tree structure directly determines every URL on the site.

  • Segment Inheritance: A page at path /Services/Cloud/Hosting inherits the segments of all its parents - each level of the tree contributes its own segment to the final URL.
  • 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, making tree organization a security architecture decision as much as an editorial one.

  • Granular Control: By organizing the tree by department or functionality - for example, a "Legal" container - technical teams can set access rights at the top-level node. All child content automatically inherits the same security standards without individual configuration.
  • Bypassing Inheritance: For specific security requirements, inheritance can be broken at any node, providing explicit access control for sensitive areas while maintaining the logical tree structure.

Pro tip: Design your tree's top-level structure around permission boundaries first, then editorial convenience. Retrofitting security onto a flat or ad-hoc tree is significantly harder than inheriting it from a well-planned hierarchy.

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 SiteDefinition for multi-site governance, architects can ensure the CMS remains responsive and manageable as content volume scales.