Praful Jangid
+3
Jun 11, 2025
visibility 1174
star star star star star
(7 votes)

Boosting Indexing Efficiency: Reindex Pages Directly from Optimizely’s Navigation Pane

There can be various reasons why you might want to trigger indexing or reindexing of a page/node directly from the navigation pane. In my case, we were working with a large volume of content and needed to test newly introduced custom indexing fields. Waiting for the entire site to be reindexed through the standard indexing job wasn’t feasible.

While there are certainly other ways to handle this, adding a manual reindex trigger proved especially helpful in our upper environments (such as Integration and Preproduction), where faster feedback loops are critical.

Here's a quick look at how it appears in the UI:

 

To implement this, I used Dojo to create new navigation items and added them to Optimizely’s plug-in area within the navigation tree. Here's the setup from Initializer.js:

define([
    "dojo",
    'dojo/_base/declare',
    'epi-cms/plugin-area/navigation-tree',
    'epi/_Module',
    'optimizelyModules/ReIndexTree/ReIndexTree',
    'optimizelyModules/ReIndexTree/ReIndexChildren'
], function (
    dojo,
    declare,
    navigationTreePluginArea,
    _Module,
    ReIndexTree,
    ReIndexChildren
) {

    return declare([_Module], {
        initialize: function () {
            this.inherited(arguments);
            navigationTreePluginArea.add(ReIndexTree);
            navigationTreePluginArea.add(ReIndexChildren);
        }
    });
});

 

Both ReIndexChildren.js and ReIndexTree.js follow a similar pattern, differing mainly in naming and intent. For reference, here’s the code for ReIndexChildren.js:

define([
    "dojo/topic",
    "dojo/_base/declare",
    "epi/dependency",
    "epi/shell/XhrWrapper",
    "epi/shell/command/_Command"
], function (topic, declare, dependency, XhrWrapper, _Command) {

    return declare([_Command], {

        label: "Reindex Children",
        iconClass: "epi-iconReload epi-icon--success",

        constructor: function () {
            var registry = dependency.resolve("epi.storeregistry");
            this.store = registry.get("epi.cms.contentdata");
        },

        _execute: function () {
            var contentLinkId = this.model.contentLink;

            // Create an XhrWrapper for making the API call
            var xhr = new XhrWrapper();
            xhr.xhrGet({
                url: "/api/indexing/reindex-tree",
                handleAs: "json",

                content: {
                    contentLinkId: contentLinkId,
                    childrenOnly: true
                },

                failOk: true,

                load: function (response) {
                    // Handle the success response (e.g., show a message)
                    console.log("Reindexing successful:", response);
                },

                error: function (response) {
                    // Handle the error response (e.g., show an error message)
                    console.error("Error reindexing:", error);
                }
            });
        },

        _onModelChange: function () {
            this.set("canExecute", true);
        }
    });
});

 

In the above implementation, I’m calling a custom controller endpoint at /api/indexing/reindex-tree. This endpoint accepts two parameters:

  • childrenOnly: A flag indicating whether to reindex only the direct children or the entire content tree under the selected node.

  • contentLinkId: The ID of the selected node, which is used to identify the starting point for reindexing.

This approach gives editors or developers an easy way to trigger indexing selectively, without needing to reindex the entire site.

You can find the full code in the GitHub repository (branch) here: https://github.com/pjangid/OptimizelyReindexModule/tree/feature/opti-module-reindex-tree

 

As always, there’s room for improvement. I’d love to hear your thoughts—please feel free to leave suggestions or feedback in the comments below.

 

Thanks & Regard,

Praful

Jun 11, 2025

Comments

error Please login to comment.
Latest blogs
Integrating a Third-Party DAM into Optimizely CMS 12: A Case Study

There is no handbook for wiring an external DAM into Optimizely CMS 12. This case study walks through the research, dead ends, and breakthroughs —...

WilliamP | Jul 7, 2026 |

Ringing a Physical Sales Bell from Optimizely Commerce

This one started as a weekend project that got a little out of hand. I built an “On Air” sign for my office — one of those LED signs streamers use ...

KennyG | Jul 6, 2026

Exploring Asset Lifecycle Management Approaches for Bynder and Optimizely SaaS CMS

Note: This is Part 3 of our Bynder integration series. For setup and filtering prerequisites, see Part 1  and  Part 2 . Introduction In my previous...

Vipin Banka | Jul 5, 2026

Unlock AI-Ready Experiences with Optimizely

Over the past few months, almost every customer conversation has shifted from SEO to AI readiness. The questions are no longer just: “How do we......

Madhu | Jul 5, 2026 |

Planning Your Bynder DAM and Optimizely SaaS CMS Integration the Right Way: Avoiding Asset Sprawl and Unnecessary Synchronization

Note: This is Part 2 of our Bynder integration series. If you missed the Part 1, check out " Implementing the Bynder DAM Connector with Optimizely...

Vipin Banka | Jul 4, 2026

Implementing the Bynder DAM Connector with Optimizely SaaS CMS: Lessons Learned

What I learned while integrating Bynder DAM with Optimizely SaaS CMS, exploring Optimizely Graph, and building a headless frontend experience....

Vipin Banka | Jul 3, 2026