Pages based navigation

Ideally i would like to create a widget that we can use to pull pages from a selected path to make a navigation. I don't want to have to recreate all the pages in the content hub. is this possible and is there anything in the documentation?

Environment

  • Xperience by Kentico version: [30.11.2]

  • .NET version: [8|9]

  • Execution environment: [SaaS|Private cloud (Azure/AWS/Virtual machine)]

  • Link to relevant Xperience by Kentico documentation

Answers

is there anything in the documentation?

Yep. I went to docs.kentico.com, typed "navigation" into the search box and was greeted immediately with 5 results all focused on how to design and implement navigation.

You can also search for the word "navigation" here in the community Q&A discussions and see several results on this topic.

Try it out yourself!

Yes, this is absolutely possible in Xperience by Kentico without touching the Content hub at all - your existing website channel pages are the data source.

The core approach: Build a View Component (not a controller-based widget) that accepts a configurable root path as a widget property. In the component, use the IContentRetriever API (the recommended approach in current XbyK versions) with PathMatch.Children(path, nestingLevel) to pull pages under the selected path. You can use PathMatch.Children to recursively retrieve all children of a specified parent page, and even limit the depth with a nesting level parameter.

For the widget property (path selector): Use a PageSelectorComponent as the widget property editor so editors can pick the root page via the tree UI rather than typing a path manually. This makes it editor-friendly and avoids hardcoding.

For URLs: Use .GetUrl() on your generated page model - it returns a WebPageUrl object with relative and absolute URL, and crucially, it never causes additional database queries.

Don't forget caching: Wrap your retrieval in cache dependencies keyed to the pages in that tree section - otherwise your navigation won't invalidate when editors publish changes.

A rough outline of what the implementation looks like:

// Widget properties
public class NavigationWidgetProperties : IWidgetProperties
{
    [EditingComponent(PageSelectorComponent.IDENTIFIER)]
    public IEnumerable<WebPageRelatedItem> RootPage { get; set; } = [];
    
    public int MaxDepth { get; set; } = 2;
}

// View Component
public class NavigationWidgetViewComponent : ViewComponent
{
    private readonly IContentRetriever _contentRetriever;

    public NavigationWidgetViewComponent(IContentRetriever contentRetriever)
        => _contentRetriever = contentRetriever;

    public async Task<IViewComponentResult> InvokeAsync(NavigationWidgetProperties props)
    {
        var rootPath = props.RootPage?.FirstOrDefault()?.WebPageTreePath ?? "/";
        
        var pages = await _contentRetriever.RetrieveWebPagesByPath(
            PathMatch.Children(rootPath, nestingLevel: props.MaxDepth),
            // add your content type + language params
        );
        
        return View("/Components/Widgets/Navigation/Default.cshtml", pages);
    }
}

Trevor's NavigationRepository is a great reference for the full production-ready pattern with caching - definitely worth looking at. The key thing his implementation does well is separate the data retrieval concern from the view component, which makes it testable and reusable.

Official docs to bookmark:

The content tree-based approach is the right call for your scenario — editors build navigation menus by arranging pages directly in the content tree, and the navigation structure mirrors the actual live site structure, making it intuitive. Kentico No Content hub duplication needed.

To response this discussion, you have to login first.