Written by
Halkwinds Editorial Team
Halkwinds Research & Editorial

Search Experience Optimization: Algolia, Elasticsearch, and AI Search
How to build site search that users actually rely on — relevance tuning, faceting, semantic search, and measurement.
Site search is the most under-invested surface in most digital products. Teams spend months A/B testing checkout flows and homepage hero images, then ship a search box that returns zero results for common typos and buries the most-clicked product on page three. Yet for users who search, intent is high and patience is low: they've told you exactly what they want, and a bad result set feels like being ignored. This article is a practical guide for product managers who want to turn search from a liability into a conversion engine — covering relevance tuning, faceting, semantic and AI-powered retrieval, and the measurement discipline that keeps it all honest.
- Background / Why This Matters
- Core Concepts and Architecture
- Implementation Strategy
- Scaling and Operational Considerations
- Common Mistakes / What to Avoid
- Frequently Asked Questions
- Conclusion
Background / Why This Matters
Users who engage with search convert at meaningfully higher rates than users who browse — research and vendor case studies consistently point to this pattern, though exact multiples vary by industry. The intuition is straightforward: someone typing "waterproof hiking boots size 10" has already made most of their decisions. Your job is simply not to lose them.
The problem is that site search optimization sits in an organizational gap. Engineering owns the search infrastructure but rarely owns relevance quality. Product owns the funnel but often can't articulate why result #1 is wrong. Nobody owns the boring, continuous work of tuning synonyms, promoting best-sellers, and killing dead-end queries. As a result, search quietly degrades as catalogs grow and language changes.
Three specific pain points show up again and again:
- Zero-result queries. A user searches "sneekers" and gets nothing, because your keyword engine has no typo tolerance and no semantic understanding. That's a lost sale from a customer who was ready to buy.
- Poor ranking. Results are technically relevant but ordered badly — the exact-match item is below three tangential ones because your relevance signal weights text frequency over business value.
- Weak faceting. Users can't narrow 4,000 results because filters are missing, slow, or don't update counts as they select.
Takeaway: Treat search as a product with an owner, a roadmap, and metrics — not as a feature that ships once and never gets touched.
Core Concepts and Architecture
Modern site search blends three retrieval approaches. Understanding the differences lets you make informed platform decisions rather than defaulting to whatever your framework ships with.
Lexical (keyword) search
The classic approach, powered by inverted indexes and ranking functions like BM25. It's fast, cheap, and interpretable — you can explain exactly why a document matched. Its weakness is vocabulary mismatch: "laptop" won't match "notebook" unless you've configured synonyms. Elasticsearch is the reference implementation here; Typesense and Algolia also do lexical retrieval extremely well with built-in typo tolerance.
Semantic (vector) search
Text is converted into embeddings — high-dimensional vectors — using a model, and retrieval finds items whose vectors are nearest to the query vector. This captures meaning, so "affordable running shoes for flat feet" can match a product described as "budget stability sneakers with arch support" even without shared keywords. The tradeoff is opacity (harder to explain rankings) and cost (embedding generation and vector indexing).
Hybrid and AI search
The current best practice is hybrid retrieval: run lexical and vector search in parallel, then fuse the results (often with Reciprocal Rank Fusion). This gives you exact-match precision plus semantic recall. Increasingly, "AI search" also layers in LLM-powered features — query understanding, conversational refinement, and generated answer summaries backed by retrieved documents (retrieval-augmented generation).
Choosing a platform
| Dimension | Algolia | Elasticsearch | Typesense |
|---|---|---|---|
| Model | Managed SaaS | Self-hosted or Elastic Cloud | Open-source, self-host or Typesense Cloud |
| Setup effort | Very low | High | Low |
| Typo tolerance | Built-in, excellent | Configurable | Built-in, excellent |
| Vector/semantic | Native (NeuralSearch) | Native (kNN, ELSER) | Native vector search |
| Relevance control | Rules + custom ranking | Full control, complex | Good, simpler |
| Cost profile | Per-operation, scales with volume | Infra + ops cost | Lower, predictable |
| Best for | Fast time-to-market, e-commerce | Complex data, full control, log/search platforms | Budget-conscious teams wanting Algolia-like DX |
Takeaway: Choose Algolia or Typesense when developer velocity and out-of-the-box relevance matter most; choose Elasticsearch when you need deep customization, own the operational skillset, or already run it for logging and analytics.
Implementation Strategy
A search implementation succeeds or fails on the unglamorous details. Here's a sequence that consistently delivers.
1. Model your data and index intentionally
Decide what a "search record" is. For e-commerce, it's usually a product, but you must denormalize the fields users search and filter on — title, brand, category, description, price, availability, rating. Store display attributes separately from searchable attributes. In Algolia, you explicitly declare searchable attributes and their order of importance; in Elasticsearch you control this through field mappings and boosts.
2. Configure the fundamentals before anything fancy
- Typo tolerance: Enable it. "iphon" should find "iPhone."
- Synonyms: Build a starter list from your own query logs — "tv"/"television," "hoodie"/"sweatshirt." This is the single highest-ROI relevance lever.
- Stemming and language analyzers: "running" should match "run."
- Faceting: Expose the filters users actually need, with dynamic counts that update as they refine.
3. Tune ranking with business signals
Pure text relevance is rarely enough. Blend in signals like popularity, conversion rate, margin, and stock status. Algolia's custom ranking and Elasticsearch's function_score both let you promote items that perform. Add merchandising rules for specific queries (e.g., pin a seasonal collection when someone searches "gifts").
4. Add semantic search where it pays off
Don't rip out lexical search to add vectors — augment it. Start hybrid: keep your keyword index for precision and add embeddings for recall on long, natural-language, and zero-result queries. Measure the lift on those specific query segments before expanding.
5. Build the search UI as a first-class experience
Instant results (search-as-you-type), query suggestions, clear "no results" states with recovery paths, and mobile-friendly facets all move the needle. Halkwinds' Digital Experience team frequently pairs an InstantSearch-style front end with a tuned backend index so that the perceived speed and the actual relevance improve together — because a fast search that returns the wrong thing still fails.
Takeaway: Ship fundamentals (typos, synonyms, faceting) first, add business-signal ranking second, and introduce semantic search as a targeted upgrade — not a rewrite.
Scaling and Operational Considerations
Search that works for 5,000 records and 50 queries a day behaves very differently at 5 million records and 5 million queries.
Index freshness
Decide how quickly changes must appear. Price and stock updates often need near-real-time indexing; product descriptions can be batched. Build an incremental sync pipeline rather than full re-indexes, and monitor indexing lag as a first-class metric.
Latency budgets
Set a target — for instant search, aim for sub-50ms server-side response. Vector search adds latency, so cache aggressively, quantize embeddings where supported, and consider approximate nearest-neighbor tuning to balance speed and recall.
Cost management
Managed platforms bill by operations or records; costs can surprise you when search-as-you-type fires a request on every keystroke. Debounce input, and consider whether you truly need per-keystroke queries or just per-word. For self-hosted Elasticsearch or Typesense, right-size clusters and separate hot/warm data.
Multi-tenant and localization concerns
If you serve multiple markets, you'll need per-language analyzers, locale-specific synonyms, and possibly separate indexes. Plan this early; retrofitting localization into a single index is painful.
Measurement infrastructure
You cannot optimize what you don't measure. Instrument at minimum:
- Zero-result rate — the clearest signal of coverage gaps.
- Click-through rate on results and average click position.
- Search-to-conversion rate versus non-search sessions.
- Query volume by term — your synonym and merchandising roadmap lives here.
Takeaway: Treat freshness, latency, and cost as explicit budgets with alerts, and stand up search analytics before you start tuning — otherwise you're guessing.
Common Mistakes / What to Avoid
- Shipping and forgetting. Relevance decays. Schedule a recurring review of top queries and zero-result queries.
- Adding AI to fix a data problem. If your catalog metadata is thin and inconsistent, semantic search will paper over it inconsistently. Clean data first.
- Ignoring zero-result queries. These are a free backlog of demand, misspellings, and missing synonyms. Mining them weekly is the cheapest relevance win available.
- Over-boosting business signals. Weighting margin or popularity too heavily makes search feel manipulative and irrelevant. Keep text match as the domin
Explore Further