Try our conversational search powered by Generative AI!

Jonas Bergqvist
Jan 14, 2014
(3 votes)

Indexing catalog content using EPiServer Find Content Indexing Job

When developing a commerce site, a good search product might be the key to success. Working search driven can make the site fast, easy to understand, and simple to use. For me, EPiServer Find is the obvious choice when working with EPiServer Commerce.

Find search provider

When using EPiServer Find in a commerce site, you might end up using the “Find seach provider” on the site, which isn’t that good. Instead you should work with the strongly typed “catalog content”, that are being indexed when adding or updating content in the new catalog UI. The problem with the typed catalog content, is that there’s no indexing job for it.

So, why should we use catalog content (the content types you create in code) instead of the content stored by the find search provider? The Find search provider index the data untyped in different dictionaries. The provider system can be used for free text search and maybe an simple facet, but is not useful for more complex operations. Indexing the content types you have created, makes it possible to make strongly typed search queries, facets, and listings. All the properties you create in code, and all the properties in the base classes can be used in the search queries. The code will also be pretty and easy to understand when working against typed data. You will also get help from the compiler to write correct code when working with typed data.

Indexing catalog content using the find indexing job

We can make the “EPiServer Find Content Indexing Job” index catalog content for us using the code below.

public class DescendetLinksOfCatalogRoot : IReindexInformation
    private readonly IContentLoader _contentLoader;
    private readonly ReferenceConverter _referenceConverter;
    private readonly ILanguageBranchRepository _languageBranchRepository;
    public DescendetLinksOfCatalogRoot(ReferenceConverter referenceConverter,
        IContentLoader contentLoader,
        ILanguageBranchRepository languageBranchRepository)
        _contentLoader = contentLoader;
        _referenceConverter = referenceConverter;
        _languageBranchRepository = languageBranchRepository;
    /// <summary>
    /// Returns all descendents of the <see cref="Root"/>.
    /// </summary>
    public IEnumerable<ReindexTarget> ReindexTargets
            var catalogs = _contentLoader.GetChildren<CatalogContent>(Root);
            foreach (var catalogContent in catalogs)
                var reindexTarget = new ReindexTarget()
                    ContentLinks = _contentLoader.GetDescendents(catalogContent.ContentLink)
                var languages = catalogContent.ExistingLanguages.ToList();
                if (!languages.Select(x => x.Name).Contains(catalogContent.DefaultLanguage))
                reindexTarget.Languages = languages;
                yield return reindexTarget;
    /// <summary>
    /// Gets the reference of the catalog root.
    /// </summary>
    public ContentReference Root
        get { return _referenceConverter.GetRootLink(); }
Jan 14, 2014


Marcus Granström
Marcus Granström Jan 15, 2014 09:24 AM

Nice post Jonas!

K Khan
K Khan Jan 15, 2014 05:34 PM

Straight to favourites

Jonathan Roberts
Jonathan Roberts Jan 17, 2014 10:03 AM

This is amazing - many thanks for this - it saved our bacon :)

Feb 5, 2014 04:14 PM

Hi Jonas, I see this is for Commerce 7.5, would you know if this will work with Commerce 1 R3?

Mar 4, 2014 05:33 PM

This will not work for Commerce 1 R3, because there is no such thing as strongly typed catalog content in that version.

Arve Systad
Arve Systad Jul 8, 2014 04:34 PM

While this will indeed index your strongly typed product/variant classes, I'm guessing it won't really affect the search provider itself? As in, when searching from within the catalog gadget inside commerce, it will still look in my FindDocuments , I guess? Aka, the index will basically be twice the size (in number of documents). Which is, obviously, not very practical.

And, in some cases, it might even burst the entire license model (If I have 4000 products, I need 8000 documents in the index, which tips me from the (current) Standard Small package to the Standard medium - more than doubling the price because of a weak implementation. This is currently an issue for me with a developer index...

Is this something that will be fixed in the (near?) future?

IMO, the default indexing should be:
1. Moved out from the commerce manager, and into the normal CMS Admin interface.
2. Index my real IContent based types, and not as FindDocuments
3. Use these documents as the basis for the gadget search. If need be (temporarily or not), make remapping from proper to oldschool objects in the commerce manager, not the other way around like it seems to be today.

Any useful input? :-)

K Khan
K Khan Jul 9, 2014 09:21 AM

Hi Jonas,
Any Idea?


Aug 18, 2014 08:16 AM

Arve: Thanks for the input.

Johannes Mols
Johannes Mols Apr 16, 2021 12:48 PM

Has there ever been a solution to this? I'm facing the same issue as Arve where our Find Index is twice the size because of FindDocument types.

Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog