Indexing content

By Optimizely Education
Published: Feb 24, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Architectural Choice: Leverage Search & Navigation for .NET-heavy sites or Optimizely Graph for decoupled, SaaS-first delivery.
Sync Strategy: Combine real-time IContentEvents for immediate updates with scheduled jobs for full-tree integrity.
Precision Control: Use the [Searchable] attribute and Conventions API to eliminate index bloat and technical noise.
Security Default: Ensure data privacy by enforcing FilterForVisitor() and the IExcludeFromSearch interface.

In Optimizely CMS 12, indexing is the process of extracting, transforming, and sending content data to a specialized search engine to enable high-performance retrieval and filtering. This architectural component is essential for building complex navigation systems, faceted search interfaces, and omnichannel data delivery. Technical teams must architect the indexing pipeline to ensure data precision while maintaining system performance within PaaS constraints.

1. Indexing Engine Architecture

Optimizely CMS 12 primarily utilizes two indexing technologies: Optimizely Search & Navigation (formerly Find) and Optimizely Graph.

Optimizely Search & Navigation

Historically the standard for CMS indexing, this service uses a proprietary .NET client to push content to an Elasticsearch-based back end. It is tightly coupled with the IContent repository and supports advanced features like Unified Search and Best Bets.

Optimizely Graph

The modern, SaaS-based GraphQL service. It acts as a platform-agnostic content hub, allowing CMS data to be indexed and queried via a strongly-typed GraphQL schema. In PaaS environments, Optimizely Graph is preferred for high-scale, multi-platform architectures where content delivery is decoupled from the web application.

2. Managing the Indexing Pipeline

The indexing process is handled through two distinct mechanisms to ensure both real-time accuracy and long-term data integrity.

Event-Driven Indexing

By default, Optimizely listens to the IContentEvents pipeline. When a content item is published or deleted, the system automatically triggers a delta indexing request for that specific item. This ensures that search results remain synchronized with the editorial state.

Scheduled Jobs

For bulk operations or repairing index discrepancies (e.g., after a database restore), the "Optimizely Search & Navigation Indexing Job" or "Content Graph Sync Job" must be executed. These jobs perform a full crawl of the content tree, ensuring all nodes adhere to the current code conventions.

3. Controlling Index Inclusions and Exclusions

To prevent performance degradation and "index bloat," technical governance must be applied to determine exactly which content and properties are sent to the search engine.

Property-Level Control: The Searchable Attribute

The [Searchable] attribute determines if a property's content is included in the default full-text index. Technical data or structural IDs should be excluded.

[Display(Name = "Internal ID", GroupName = "Technical")]
[Searchable(false)] // Excludes this specific property from indexing
public virtual string InternalReferenceId { get; set; }

Type-Level Control: Programmatic Conventions

To exclude entire content types (e.g., technical blocks or container pages), developers should utilize the Conventions API within an initialization module.

[ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
public class SearchInitialization : IInitializableModule
{
    public void Initialize(InitializationEngine context)
    {
        // Prevent instances of TechnicalBlock from being indexed
        ContentIndexer.Instance.Conventions
            .ForInstancesOf<TechnicalBlock>()
            .ShouldIndex(x => false);
    }

    public void Uninitialize(InitializationEngine context) { }
}

4. Performance Optimization Strategies

Indexing can be resource-intensive. Implementing these strategies minimizes the impact on the application's runtime performance.

ContentArea Depth Management

By default, Optimizely does not index content inside a ContentArea deeply to avoid circular reference loops and massive document sizes. To include specific block data in a page's index, the IndexInContentAreas attribute must be used on the block type definition.

Batching and Parallelism (Optimizely Graph)

When using Optimizely Graph, batching parameters can be tuned in the Startup.cs file. Increasing the grace period reduces the frequency of API calls during heavy editorial periods.

services.AddContentGraph(options => {
    options.BufferedIndexingGracePeriod = 15000; // Buffer for 15 seconds
    options.MaxBatchSize = 100; // Send items in groups of 100
});

5. Security and Governance in Indexing

Search results must always respect the CMS security model. If sensitive data is indexed and retrieved via a client-side API without proper filtering, it presents a security risk.

Filtering for Visitor: Always utilize .FilterForVisitor() in search queries to ensure the engine only returns content the current user is authorized to view.
Excluding Sensitive Types: If a content type implements IExcludeFromSearch, the indexing engine will automatically honor the ExcludeFromSearch property, providing a code-based circuit breaker for technical content governance.

Conclusion

Efficient indexing in Optimizely CMS 12 requires a disciplined approach to content modeling and an understanding of the technical contract between .NET code and the search back end. By utilizing property attributes for field-level control, initialization modules for type-level conventions, and tuned batching parameters, technical teams can deliver a search experience that is both highly relevant and computationally efficient.