Five-level nesting cap in Sulu content node tree

Short answer

Based on Sulu's architecture, a nesting cap of this kind is almost certainly a display-side limit in the admin tree UI, not a hard repository constraint. Nodes beyond the limit most likely still exist in the PHPCR content repository, remain routable on the frontend, and stay available to content queries — they are simply not rendered in the tree. However, the exact semantics of a max_depth key in config/sulu/content.yml could not be confirmed against a specific Sulu release, so treat everything below as a working hypothesis to verify against your installed version before restructuring content.

Likely explanation vs. confirmed facts

Confirmed by architecture: Sulu stores pages as a PHPCR node tree, and the admin tree component loads children lazily, level by level. A depth cap fits naturally as a UI safeguard: each additional level means more lazy-load requests and more tree state, so capping render depth protects admin performance. Because Sulu resolves page URLs from the full node path in the webspace route tree, a page hidden from the tree should still resolve on the frontend. Translations live as properties on the same node, so any node-level limit would apply consistently across locales — multi-language installations should not see divergent behavior.

Likely but unverified: that a max_depth configuration key exists with a default of five in your version, that raising it is officially supported, and that hidden nodes cause no downstream rendering issues. These points are version-sensitive and not clearly documented; they need checking against your codebase.

How to verify on your installation

1. Create a sixth-level page in a staging environment. Visit its frontend URL directly. If it renders, the cap is display-only and your published content is safe.
2. Confirm the node exists in the repository independently of the tree, e.g. via the PHPCR shell or a custom query against the document manager.
3. Search the installed vendor code for the actual key and default:

   grep -rn "max_depth\|maxDepth" vendor/sulu/sulu/src --include=*.php | head -20

   This tells you whether the key is read at all, where it applies (tree component, repository query, or both), and what the default is for your version.
4. If the key is honored, raise it by one on staging and check: do previously hidden nodes reappear in the tree, does the tree still load acceptably, and does anything in routing or navigation output change?

Answers to your three questions

Can the limit be adjusted safely? Probably, if the key exists in your version — the expected cost of raising it is admin UI performance (more lazy-load round trips, larger tree state), not data integrity. But because support is undocumented, pin the change to staging first and be prepared for it to break silently on a Sulu upgrade.

Does truncation affect queries and routing? Most plausibly no. Routing derives from the node path, and repository queries operate on the full tree unless the depth parameter is explicitly passed. Verify with step 1–2 above rather than assuming.

Recommended patterns for deep hierarchies? Don't encode taxonomy in page nesting. Flatten the page tree and model categories using Sulu's built-in category/taxonomy system (or a custom entity) linked to pages. This sidesteps the depth cap entirely, keeps the admin tree fast, and gives you cleaner filtering and listing than deep nesting ever would.

One caveat

If verification shows the sixth-level page is not routable, the limit is deeper than the UI and this advice changes — in that case, report your Sulu version and the exact behavior to the Sulu issue tracker before migrating content, since that would indicate a repository-level constraint rather than a cosmetic one.