Search Relevance on Shopify: When to Ditch the Native Search and What to Replace It With

Shopify merchants tend to discover their search problem the same way: a category manager types a common misspelling of a hero product into their own store, gets zero results, and forwards the screenshot to the CEO. By the time it reaches engineering, it's already framed as "our search is broken." It usually isn't broken. It's just been asked to do a job it was never built for.

This is a field guide to that conversation. When is Shopify's native search actually the bottleneck? What do you replace it with? And how much of the migration pain is real versus imagined?

What Shopify's native search actually does

Before ripping anything out, it's worth being honest about what ships in the box. The default storefront search on Shopify is a prefix-matching, token-based search over product title, vendor, type, tags, and (depending on plan and configuration) body HTML and variant data. It's fast, it scales with the platform, and for a catalog of 500 SKUs with clean titles, it's genuinely fine.

The free Search & Discovery app extends this meaningfully. You get synonyms, boosts, product redirects, filters (they call them "refinements"), and some analytics on what people search for and what returns zero results. For a lot of stores, installing Search & Discovery and spending an afternoon on synonyms fixes 60–70% of complaints in our experience.

So the first question is never "which vendor should we buy?" It's "have we exhausted Search & Discovery?"

The signals that you've actually outgrown it

A few patterns tell us the native stack is genuinely the ceiling:

• Zero-result rate above ~8% on non-junk queries, even after synonym work.
• Typos and morphological variants dominating the zero-result log ("tshirt" vs "t-shirt", "trousers" vs "trouser", plurals, accents).
• Merchandising requests the platform can't express: "boost in-stock items, but only for this collection, and demote items with less than 3 reviews."
• Faceted navigation on metafields that Search & Discovery filters can't reach cleanly, especially on B2B catalogs with technical attributes.
• Search-driven revenue share above ~15% of sessions. Once search is that load-bearing, small relevance gains compound.
• Multi-language or multi-market catalogs where stemming and language-aware tokenisation matter.

If none of those are true, close the tab and go work on your PDP instead.

The realistic replacement options in 2026

There are more search vendors than there are honest reviews of them, so we'll focus on the four shapes of solution we actually reach for.

1. Search & Discovery + a hard look at your data

Not a replacement, but worth naming. Half the "bad search" projects we're asked to quote end here. Product titles are inconsistent, tags are a graveyard, and nobody has ever entered a synonym. Fix the data, and the built-in engine gets surprisingly capable.

2. Algolia (or a direct competitor like Klevu, Searchspring)

Hosted, opinionated, expensive at scale, and genuinely good. Algolia's tradeoff is that you're buying a whole product — InstantSearch UI components, dashboards, A/B testing, personalisation, query suggestions — not just an index. If your team is small and search is strategic, that bundle is often cheaper than building it.

The pain points are real though: pricing that scales on operations and records (a 50k SKU store with lots of variants gets expensive fast), and a lock-in on their query DSL and ranking config. Migrating off Algolia later is not free.

3. Typesense or Meilisearch (self-hosted or their cloud)

Open-source, much cheaper, and honestly close enough on relevance for most catalogs under 100k SKUs. You give up some polish — the merchandising UIs are thinner, personalisation is DIY — but you own the stack.

We pick this when the client has an engineering team that will actually maintain it, or when Algolia's bill has become the reason we're being called.

4. A hybrid lexical + vector search layer

This is the 2026 answer that didn't really exist as a mainstream option three years ago. You keep a fast lexical engine (Typesense, OpenSearch, or even Postgres FTS) for exact and prefix matching, and add a vector index (pgvector, Pinecone, Weaviate, Qdrant) for semantic recall. Fusion at query time — usually reciprocal rank fusion — gives you both "black cotton tshirt size L" and "something to wear to a summer wedding" from the same box.

Worth it when your catalog has rich descriptions, editorial content, or a lot of long-tail intent (home goods, beauty, gifting). Overkill for a 200-SKU apparel drop store.

How we actually wire Algolia into a Shopify stack

Because this is the most common migration, here's the shape we use. It applies whether you're on Liquid or headless.

The indexing side runs off Shopify webhooks. We avoid the official connector for anything non-trivial because it doesn't handle metafield-heavy catalogs well.

// worker: shopify -> algolia indexer
import { algoliasearch } from 'algoliasearch';

const client = algoliasearch(APP_ID, ADMIN_KEY);
const index = client.initIndex('products_en');

export async function onProductUpdate(product) {
  const record = {
    objectID: product.id,
    title: product.title,
    handle: product.handle,
    vendor: product.vendor,
    type: product.product_type,
    tags: product.tags,
    price_min: minVariantPrice(product),
    in_stock: product.variants.some(v => v.inventory_quantity > 0),
    // flatten the metafields you actually facet on
    material: mf(product, 'specs', 'material'),
    fit: mf(product, 'specs', 'fit'),
    review_count: mf(product, 'reviews', 'count') ?? 0,
    review_avg: mf(product, 'reviews', 'average') ?? 0,
    // for ranking
    popularity_30d: await getPopularity(product.id),
  };

  await index.saveObject(record);
}

A few things worth calling out:

• Flatten metafields at index time, don't try to resolve them at query time.
• Denormalise inventory and price into the record. Yes, it means more updates. Yes, it's worth it.
• Push a popularity signal (orders, add-to-carts) on a schedule. This is the single biggest relevance lever most stores never touch.
• Index per language and per market as separate indices. Do not try to filter by locale at query time.

On the storefront side, we usually skip InstantSearch's out-of-the-box widgets on serious builds and write our own query layer. The widgets are fine for prototypes, but they fight you the moment design has an opinion.

The migration trap nobody warns you about

The technical migration is the easy part. The trap is that you now own relevance as a product surface, and nobody at the client has ever owned it before.

Who decides that in-stock items should be boosted by 1.5x but not 2x? Who reviews the zero-result log weekly? Who owns synonyms when marketing launches a campaign using new terminology? On native Shopify search, these questions don't exist because you can't answer them. On Algolia, they exist and someone has to be accountable.

We've seen more "failed" Algolia migrations die from this org gap than from any technical issue. Before we quote a search project now, we ask who the merchandiser is going to be. If the answer is a shrug, we recommend a smaller project.

A rough decision tree

Just to make this concrete:

• Under 1,000 SKUs, single language, clean data: stay on Search & Discovery. Spend the budget on PDP speed or performance work instead.
• 1k–50k SKUs, growing, English-heavy, small team: Algolia or Klevu. The bundled tooling pays for itself.
• 10k+ SKUs, strong engineering team, cost-sensitive: Typesense or Meilisearch, self-hosted or cloud.
• Editorial catalog, gifting, home, beauty, long-tail intent: hybrid lexical + vector, usually behind a thin API you own.
• B2B with 50+ technical facets: often none of the above — a custom OpenSearch index with a bespoke facet UI ends up cheaper than fighting a SaaS vendor's data model.

Where we'd start

Before committing to any vendor, spend one week doing this: export your last 90 days of on-site search queries, sort by frequency, and manually score the top 200 for relevance on a 0/1/2 scale. Do the same on a competitor. You'll learn more from that spreadsheet than from any vendor demo, and you'll have a baseline to measure the replacement against. Most of the search work we're proudest of started with that exact sheet — not with a procurement decision.