Implementing Semantic Product Search for Magento Shops With Vector Search

1. Starting point: how Magento's CatalogSearch works today

Magento's CatalogSearch module builds a composite search text per product from configured, searchable attributes during indexing, searched classically via BM25 through Elasticsearch or OpenSearch. Layered navigation, price filters, and attribute facets are based on aggregations over exactly the same indexed attributes, which makes CatalogSearch a tightly coupled system where text search and faceting share the same data foundation.

This coupling is exactly why semantic search only makes sense as an additional component, not as a wholesale replacement: facet navigation, price filtering, and sorting by attribute do not work with a vector field alone, since vectors do not represent discrete, filterable categories, only continuous similarity in meaning space.

2. Embedding generation for product data: which fields are suitable

Free text fields with actual semantic content are the best fit for embedding generation, such as product name, short description, and full description, while structured attributes like color, size, or article number should still be treated classically as filterable facets, not as part of the embedding text. A sensible approach is to merge the relevant text fields into a single, weighted body of text before computing the embedding, with the product name typically weighted more heavily than the long description.

The actual embedding computation happens outside of Magento, either through an external inference service, a self hosted embedding model, or through ELSER directly inside Elasticsearch. For a classic Magento setup, a dedicated asynchronous worker process is the most pragmatic route, consuming new or changed products from a queue, computing the embedding, and then writing the result into the existing product index via the bulk API.

{
  "worker_pattern": "async embedding worker",
  "trigger": "Magento indexer partial reindex event",
  "input_fields": ["name", "short_description", "description"],
  "field_weighting": {"name": 3, "short_description": 2, "description": 1},
  "embedding_model": "multilingual sentence transformer, 384 dim",
  "output": "bulk update via _bulk API into existing product index"
}

3. Integration with CatalogSearch: plugin instead of preference

The practical integration into Magento is cleanest through a plugin on the existing search query construction, which leaves the BM25 query part built by the CatalogSearch module untouched and instead adds an additional knn or rrf retriever block once an externally computed embedding is available for the search query. This approach respects the existing CatalogSearch architecture and avoids a risky preference that would reach deep into Magento's core search logic.

The query vector for the search request itself also has to be computed, either synchronously during request handling via the same inference service also used for product data, or, when using ELSER, automatically by Elasticsearch itself. Synchronous embedding computation per search query adds an extra network round trip to response time, so that service needs to deliver low, reliable latency to avoid noticeably degrading the live search's user experience.

4. Hybrid instead of replacement: semantic results as a complement

The most robust practical approach combines classic BM25 search with vector search via Reciprocal Rank Fusion, instead of deploying pure vector search as the sole result source. That keeps exact matches on article numbers, brand names, or specific model designations reliably intact, while semantically relevant but differently phrased results are additionally pulled in, without degrading existing search quality for queries that already work well.

Nothing changes for layered navigation and facet aggregations in this setup: they remain fully on the classic, attribute based path, while the semantic component only influences the relevance ordering of the result list, not the available filter options themselves.

5. Realistic expectations: a complement, not a silver bullet

Semantic search delivers its biggest measurable effect on longer, paraphrased search queries and on synonyms not explicitly maintained in the catalog, for example a search for rain jacket when the product is listed as waterproof outdoor coat. For short, exact search queries with an article number or a clear model name, it brings barely any measurable additional benefit, since classic text search already covers those cases reliably.

A common project planning mistake is to sell semantic search as a blanket improvement to the entire search experience, instead of measuring it specifically against concrete, documented weaknesses of the existing search. Analyzing actual zero result search queries from the shop's analytics data before the project starts delivers far more solid arguments for the business case than general expectations about semantic search.

6. Maintenance overhead on product changes: keeping embeddings current

Every change to a searchable text field of a product, for example a revised description as part of an SEO optimization, potentially makes the previously computed embedding stale and requires recomputation. In practice that means extending the existing Magento indexer mechanism so that relevant product changes reliably trigger an event for the embedding pipeline, instead of recomputing embeddings only during a rare manual full reindex.

This additional asynchronous process is a permanent operational component that needs its own monitoring: a queue backing up due to a failed embedding service otherwise means changed products keep showing up in semantic search with stale embeddings for days, without this being visible in the normal Magento indexer status.

# Example monitoring of the embedding job queue
# (conceptual, adapt to the actual queue system in use)
queue_depth=$(rabbitmqctl list_queues name messages | grep embedding_jobs | awk '{print $2}')
if [ "$queue_depth" -gt 5000 ]; then
  echo "WARNING: embedding queue is backing up, ${queue_depth} pending jobs"
fi

7. Rollout strategy: incremental instead of big bang

A proven rollout approach starts with a small, clearly scoped product category, for which embeddings are computed and hybrid search is enabled, while the rest of the catalog keeps running unchanged on classic BM25 search. This phase makes it possible to observe actual result quality, embedding pipeline latency, and operational overhead under real conditions before rolling the change out to the whole catalog.

Only after a successful test phase with measured, documented results does expanding to the full catalog pay off, and at that point the embedding pipeline also has to allocate enough capacity and time for the initial full indexing run, since the first computation for a large existing catalog can take several hours to days depending on the embedding service used.

8. Fallback behavior: what happens when the embedding service fails

Because vector search introduces an additional external dependency into request handling, the integration must define fallback behavior for the case where the embedding service does not respond to the query in time. A robust setup runs the search transparently with only the classic BM25 retriever in that case, instead of letting the entire search request fail, and logs the failure for later monitoring.

A sensible timeout for synchronous embedding computation during request handling is typically well under one hundred milliseconds, since any additional latency flows directly into the response time the customer perceives for live search, and a too generous timeout can noticeably slow down the entire search experience.

9. Measuring the business case: A/B tests instead of gut feeling

The actual business benefit of a semantic search extension should be measured through a controlled A/B test, where part of the search traffic continues to be served exclusively via classic BM25 search, while a comparable user group receives hybrid search, followed by comparing click through rate on search results, conversion rate, and the share of zero result search queries between the two groups.

Without such a measurement, the benefit of the added complexity and ongoing operating cost remains hard to substantiate, and projects risk keeping semantic search running indefinitely as a technically interesting but economically unjustified feature, without ever concretely demonstrating actual value for revenue or customer satisfaction.

10. Summary

11. FAQ: Semantic Product Search for Magento: The Essentials at a Glance