Umbraco 18 Elements: A New Way to Manage Reusable Content

Every Umbraco developer knows the "Settings" node. Buried at the bottom of the content tree, holding footer text, promo banners, and taxonomy data that was never really a page but had nowhere else to live. It's the quiet source of technical debt on almost every long-running Umbraco build.

Umbraco 18 fixes this with Elements, the headline feature of the release. Element types themselves aren't new, if you've built with Block List or Block Grid, you've already worked with them. What's new is a proper home for them: a dedicated Library section in the backoffice, separate from the page tree, built for content that needs reuse without needing to be a routable page.

For enterprise builds, multi-site setups, and customer portals, this is a structural fix to a problem most teams have quietly worked around for years.

The Problem Elements Solves

Use case: A marketing team manages shared footer content, reusable CTAs, and promo panels across multiple landing pages, none of it a "page," all of it modeled as one anyway.

For years, the document tree was the only place to store this content. Reusable CTAs and settings got turned into pages, usually parked under a hidden node. It worked, but at a cost:

• Non-page content cluttered the tree, making navigation harder for editors
• Developers had to manually prevent "settings" nodes from rendering or being indexed
• No clean separation between routable pages and reusable fragments

What Elements Actually Are

Use case: Understanding where Elements fit relative to Block List, Block Grid, and standard content.

Reusable Elements in the Library behave like standard content nodes, you can create, move, and delete them the same way.The key difference is that they exist without rendering and routing, though otherwise they behave a lot like content.

@inject IPublishedContentQuery Content

@{

    var promoPanel = Content.Content(Guid.Parse("your-element-key-here"));

}

@if (promoPanel != null)

{

    <div class="promo-panel">

        <h3>@promoPanel.Value<string>("headline")</h3>

        <p>@promoPanel.Value<string>("body")</p>

    </div>

}

Benefits

• Structured, validated properties, just like page content
• No accidental routing or URLs for non-page content
• One Element referenced from unlimited pages
• Updates propagate everywhere the Element is used

A Dedicated Library Section

Use case: An enterprise site with multiple sub-brands needs shared content disclaimers, contact blocks, seasonal banners managed apart from the pages that use it.

A new Library section within the backoffice provides a dedicated location for managing reusable content independently of website pages.Editors now have a clear model: pages live in Content, reusable fragments live in the Library.

What this enables:

• A content tree with only actual pages
• Independent governance for Elements vs. pages
• A foundation for deeper Block Editor integration in Umbraco 19

The Element Picker

Use case: An editor building a landing page needs to insert a centrally-managed CTA without duplicating its content.

Elements are surfaced through a new Element Picker, scoped specifically to Library content.

@{

    var pickedElement = Model.Value<IPublishedElement>("featuredCta");

}

@if (pickedElement != null)

{

    <div class="cta-block">

        <h4>@pickedElement.Value<string>("ctaTitle")</h4>

        <a href="@pickedElement.Value<string>("ctaLink")">

            @pickedElement.Value<string>("ctaLabel")

        </a>

    </div>

}

Benefits

• Editors reuse approved content instead of recreating it
• One edit reflects everywhere the Element appears
• Faster page-building with pre-approved blocks

Permissions for the Library

Use case: A global team wants marketing to manage promo Elements while restricting who touches legal content in the same Library.

Overview: You can set permissions for a User Group using the same inheritance and scoping system as Content Permissions, with an Access Viewer showing effective permissions per group or user.The Element Picker itself can be locked down by start node, and by user permissions.

Best Practices

• Audit existing "fake pages" first footers, settings nodes, promo blocks — as your initial migration list
• Keep Element Types narrow and purpose-built, not one large catch-all type
• Set up Library permissions before opening it to the full editorial team
• Use start-node restrictions on the Element Picker for multi-site setups
• Document Element Types for editors, since they won't appear in the familiar page tree
• Structure Element Types now with Umbraco 19's Block Editor integration in mind

Wrapping Up

Elements isn't flashy, and Umbraco hasn't positioned it that way. It's a structural correction to a problem that's existed for years, reusable content with no proper home, forced into a page tree never designed to hold it.

This is also Phase One. Deeper Block Editor integration, mixing Elements with standalone blocks, converting blocks into Library Elements is planned for Umbraco 19 later in 2026. Teams adopting Elements now are building a foundation, not a one-off feature.

Migrating long-standing "settings" nodes into the Library now means a cleaner content model heading into 19, rather than a larger effort later.

For a quick visual walkthrough, check out this video :

Written by

Nishant Vaghasiya

Technical Architect

I'm Nishant Vaghasiya, a Technical Architect and Umbraco & Sitecore Certified Developer at Arroact Technologies. I specialise in building digital solutions with Umbraco and Sitecore that are practical, scalable, and built to last.

Over the years, I've learned that the best solutions aren't always the most complex ones, they're the ones that make a team's day-to-day work simpler and give them confidence that the system won't let them down.

That's what drives me writing code that performs well, stays reliable, and continues to create real impact long after it goes live.