From Tree to Search: What Explorer's Deprecation Means for How We Design Content in SitecoreAI

On September 22, 2026, Sitecore deprecated Explorer.

Its core jobs, creating content and finding content, now live in the new Content mode in Page builder. Editors don't browse a deep tree anymore. They search, get a flat list of results, and open items directly in a full-screen editor.

Most posts about this will stop at "Explorer is gone, here's Content mode." That's the easy part.

The harder question is this. For about 20 years, we've designed Sitecore solutions assuming editors would browse the content tree. If they now search instead, what should we, as developers, change?

The Tree Was Never Just Storage

The content tree has shaped almost every Sitecore architecture decision we've made.

• Folder structures. We built neat hierarchies so editors could find things by clicking down through them.
• Helix-style organization. Feature, Foundation, and Project layers gave the tree a predictable shape that editors learned over time.
• Datasource locations. We decided where component content lived partly based on where an editor would expect to find it.
• Context through position. An item called "Banner" made sense because it sat under "Homepage > Data." The tree did the explaining.

That last point is the one that matters most now. A lot of our content only makes sense because of where it sits. Take away the tree view, and that context disappears.

What Changes When Editors Stop Seeing the Tree

The tree still exists. Sitecore still uses it. But editors working in Content mode mostly won't see it.

That means:

• Editors land on items through search results, not through a path
• An item has to explain itself without its parent folders around it
• Deep nesting stops helping editors and starts hiding things
• "I know where that lives" knowledge stops being useful

The structure is still there for the system. It's just no longer the main way people find their way around.

Naming Is Now a Design Decision

When browsing was the default, a vague name was a small annoyance. You could still find the item by its location.

When search is the default, a vague name is a real problem.

Picture an editor searching "promo" and getting back:

• Promo 1
• Promo 2
• Promo 3
• Promo Copy
• New Promo

Which one is on the pricing page? Nobody knows without opening each one.

What to do about it:

• Name items for what they are, not where they are. "Pricing Page - Annual Plan Promo" beats "Promo 3."
• Use display names deliberately. They're what editors see. Make them clear and human.
• Name templates with editors in mind. "Hero Banner" is easier to search for and understand than an internal shorthand.
• Agree on naming conventions early. Then build them into templates and branch templates, so editors don't have to remember them.
• Avoid duplicate names across sections. Search flattens everything into one list, so ten items called "Content" become a real headache.

Good naming used to be good practice. Now it's how content gets found at all.

Insert Options and Branch Templates Matter More Than Ever

Content mode relies on guided insert options. When an editor creates something, they choose from what you've allowed.

So, your insert options are now the editor's main guide to creating content.

• Configure insert options carefully. If the list is too long, editors get confused. If it's too short, they get stuck.
• Lean on branch templates. A branch template can create a page along with its datasources, default components, and correctly named child items in one step.
• Bake structure into creation. If editors can't see the tree, the right structure should be created for them automatically.
• Review older solutions for gaps. Many tree-heavy builds left insert options loose, because editors could just right-click anywhere in the tree. That safety net is gone.

I covered how to set up page branch templates in detail in my earlier post on Page Branch Templates. If you haven't set them up yet, now is a good time.

Rethinking Datasource Strategy

Editors in Content mode work page-first. They think "I'm editing this page," not "I'm editing items in this folder."

That pushes on an old question: page-local or shared datasources?

Page-local datasources

• Fit naturally with page-first editing
• Easier for editors to understand, since the content belongs to the page they're on
• Lower risk of editing one thing and accidentally changing it on ten other pages

Shared datasources

• Still the right call for content that truly repeats, like a global CTA, a legal disclaimer, or a site-wide announcement
• Need strong, descriptive names, because editors will find them through search
• Should make it obvious that they're shared, so nobody edits them thinking the change only affects one page

A simple rule to work from:

• If content belongs to one page, keep it local to that page
• If content truly belongs to many pages, share it and name it so clearly that nobody can mistake it for something local

Who Still Needs Content Editor

Content Editor isn't going away for everyone. Depending on your setup and roles, some advanced or admin work may still need it.

The line now roughly looks like this:

Content mode is for:

• Day-to-day content creation
• Finding and editing items
• Page-focused editorial work

Content Editor is still for:

• Developers and admins
• Template and field configuration
• Advanced item management and troubleshooting
• System settings and setup tasks

The goal is that editors should rarely need Content Editor. If your editors keep switching to it for routine work, take that as a sign your solution needs better insert options, naming, or branch templates.

Migration Advice for Tree-Heavy XM Cloud Solutions

If your XM Cloud solution was built around browsing the tree, here's where I'd start:

• Audit your item names. Search for common words like "promo," "banner," "content," or "item" and see what comes back. If the results are confusing, editors will be confused too.
• Clean up display names. This is often the fastest win with the biggest impact.
• Review insert options on every key template. Make sure editors can only create what makes sense in each place.
• Introduce or update branch templates. Especially for page types editors create often.
• Revisit datasource locations. Move page-specific content closer to its page where it makes sense.
• Flatten where nesting adds no value. Deep folders built only for browsing may not be needed anymore.
• Talk to your editors. Watch how they actually search. Their search terms will tell you what to name things.
• Check roles and permissions. Be clear about who still needs Content Editor access and why.

The Bigger Shift

For two decades, the tree was the editor's map. We designed solutions so that map would make sense.

Now the map is mostly hidden. Search is the new way in.

That doesn't make good structure less important. It changes where good structure needs to show up. It now has to live in names, templates, insert options, and how content is created, not just in folder hierarchy.

The developers who adapt fastest won't be the ones who memorize Content mode. They'll be the ones who stop designing for browsing and start designing for search.