How to Approach Elasticsearch for Large eCommerce Catalogs

Search is often the highest-leverage feature in an eCommerce platform. A good search experience leads directly to conversions. A poor one leads to abandoned sessions.

Elasticsearch is the right tool for many large catalog scenarios, but it requires deliberate design decisions at the mapping, indexing and query level. This article walks through the most important ones.

Start with the mapping, not the data

The most common mistake is letting Elasticsearch auto-detect field types from the data. Auto-mapping works for small, simple datasets. For a product catalog with thousands of SKUs, varied attribute structures and multi-language support, it will cause problems.

Define your mappings explicitly before indexing any data. Key decisions:

Which fields need full-text search vs. exact match? Use text for the former, keyword for the latter. Many fields need both, using multi-fields.
Which fields will be used for filtering and aggregations? These should be keyword or numeric types with doc_values enabled.
Which fields will affect relevance scoring? Keep the number of scored fields small and deliberate.

A well-designed mapping is the foundation of both search quality and indexing performance.

Normalize before you index

Product data coming from ERPs, PIMs and supplier feeds is rarely clean. Inconsistent attribute names, mixed-case values, redundant whitespace and encoding issues all degrade search quality.

Build a normalization layer before data reaches Elasticsearch. This means:

Lowercase and trim all text fields
Standardize category hierarchies into consistent paths
Resolve attribute value synonyms (e.g. “Blue”, “BLUE”, “Azul” → normalized value)
Validate required fields and log missing data rather than silently indexing incomplete documents

Normalization is not glamorous work, but it is the single biggest driver of search quality improvement in most catalog systems I have worked with.

Design the indexing flow for real-world constraints

Full reindex cycles are expensive and problematic in production environments. A catalog with hundreds of thousands of products can take minutes or hours to reindex, during which search quality degrades.

Design for incremental updates from the start:

Track a last_modified timestamp on every product
Build an incremental indexer that processes only changed documents
Use Elasticsearch’s bulk API with appropriate batch sizes (usually 100–500 documents per batch depending on document size)
Implement dead-letter handling for failed documents rather than silent failures
Monitor indexing lag as an operational metric

Reserve full reindexes for mapping changes and use index aliases with zero-downtime reindexing patterns to avoid search disruption.

Relevance is a product decision, not just a technical one

Elasticsearch’s default BM25 scoring is reasonable, but it is not tuned for your catalog. Relevance requires iteration and business input.

Start with a clear definition of what “good results” means for your use case:

Should exact matches in the product title rank higher than matches in the description?
How should category and brand affect ranking?
Should in-stock products rank higher than out-of-stock ones?
How should price or popularity factor in?

Implement these priorities using field boosts, function score queries or custom scoring. Then validate with real queries from actual users — not test queries you designed yourself.

Faceted search and aggregations at scale

Faceted navigation (filtering by category, brand, price range, attributes) is computationally expensive in Elasticsearch when not handled carefully.

Key practices:

Use the filter context for all facet filters, not the query context. Filter context results are cached and do not affect scoring.
Compute aggregations for the full result set first, then apply user-selected filters. This keeps facet counts accurate.
Limit the number of terms returned in aggregations to what is visible in the UI. Large aggregation requests are expensive.
For high-cardinality fields like brand or category, consider using eager_global_ordinals for better aggregation performance.

Monitoring search quality in production

Good search is never finished. User behavior changes, the catalog grows and edge cases emerge.

Set up basic observability:

Log all search queries with result counts and response times
Track zero-result queries — these are direct signals of search quality gaps
Monitor click-through rates from search results pages
Periodically review the top 100 queries and validate that results are correct

Search quality is an ongoing operational concern, not a one-time implementation task.

Elasticsearch is a strong foundation for large eCommerce search, but the engineering decisions around mapping design, data normalization, indexing strategy and relevance tuning are what separate a functional system from one that actually performs well for users and the business.

If you are working on search optimization for a large catalog and would like to discuss the specific challenges you are facing, get in touch.