Limit Sitecore Content Editor search to direct hits only

Posted 15 Oct 2025 by Marek Musielak

I use Sitecore Content Editor a lot, and often I need to search for an item using either its ID or its path. When I do that, I don't like the fact that Sitecore tries to be smart and search not only by the ID I used but also by parts of the GUID or by parts of absolute Sitecore paths. That is not only unnecessary but also much slower. That's why I created two new Sitecore processors that make sure Sitecore doesn't waste its resources and my time.

The first processor takes care of the ID. The logic is very simple. It checks if the search pipeline is triggered from the Sitecore Content Editor and if the text passed in the query is a GUID. If it is, we try to get an item by that ID, and if one exists, we return only that item as a Direct Hit and abort all the other processors in that pipeline. I searched for a Sitecore item using its ID — I don't need any other results. I want only that item, and I want it fast:

using System;
using Sitecore.Data;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Pipelines.Search;
using Sitecore.Search;

namespace MyAssembly.MyNamespace
{
    public class CustomIdResolver
    {
        public void Process(SearchArgs args)
        {
            Assert.ArgumentNotNull(args, nameof(args));

            if (args.Type == SearchType.ContentEditor && Guid.TryParse(args.TextQuery, out var guid))
            {

                var item = args.Database.GetItem(new ID(guid), args.ContentLanguage);

                if (item != null)
                {
                    var result = SearchResult.FromItem(item);
                    args.Result.AddResultToCategory(result, Translate.Text("Direct Hit"));
                    args.AbortPipeline();
                }
            }
        }
    }
}

The second processor is very similar to the first one. It again checks if the search pipeline is triggered from the Sitecore Content Editor and, additionally, whether the query starts with /sitecore/. If it does, we try to get an item by that path, and if one exists, we return only that item as a Direct Hit and abort all the other processors in that pipeline. I searched for a Sitecore item using its full path — again, I don't need any other results:

using System;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Pipelines.Search;
using Sitecore.Search;

namespace MyAssembly.MyNamespace
{
    public class CustomPathResolver
    {
        public void Process(SearchArgs args)
        {
            Assert.ArgumentNotNull(args, nameof(args));

            if (args.Type == SearchType.ContentEditor
                && !string.IsNullOrEmpty(args.TextQuery)
                && args.TextQuery.StartsWith("/sitecore/", StringComparison.InvariantCulture))
            {
                var item = args.Database.GetItem(args.TextQuery, args.ContentLanguage);

                if (item != null)
                {
                    var result = SearchResult.FromItem(item);
                    args.Result.AddResultToCategory(result, Translate.Text("Direct Hit"));
                    args.AbortPipeline();
                }
            }
        }
    }
}

The last piece of the puzzle is a Sitecore config patch file that adds my two processors before any other processors in the search pipeline, which is triggered when the Sitecore Content Editor search is executed. A simple patch file uses patch:before="*" for my new processors:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"  xmlns:role="http://www.sitecore.net/xmlconfig/role/">
    <sitecore role:require="Standalone or ContentManagement">
        <pipelines>
            <search>
                <processor type="MyAssembly.MyNamespace.CustomPathResolver, MyAssembly" patch:before="*" />
                <processor type="MyAssembly.MyNamespace.CustomIdResolver, MyAssembly" patch:before="*" />
            </search>
        </pipelines>
    </sitecore>
</configuration>