Site search development replaces a box that returns “no results” with an engine that tolerates typos, understands the words your customers actually type and filters a catalogue the way people shop. On a store, a documentation site or a large content archive, search is often the shortest path from intent to a page that earns money or answers a question. The built-in search of WordPress, WooCommerce, Magento or a SQL LIKE query rarely does that job once the catalogue grows.
Contents
At CodeWiz we design and build search for websites, online stores and applications. We choose the engine for your data and your team, model the index, keep it in sync with the source of truth, and ship an interface with autocomplete, filters and result pages that stay fast on mobile. We also wire up query analytics so relevance improves from real searches, not from guesswork.
This service is for stores whose customers cannot find products they know you sell, publishers and documentation sites with thousands of pages, B2B catalogues with customer-specific prices, and teams whose current search is slow, blind to spelling mistakes or impossible to tune without a developer in the database.
Typesense for Site Search Development
Typesense is the engine we reach for first on most store and content projects. It is open source, typo-tolerant by default, and simple to operate: a single binary, an HTTP API and an in-memory index that answers typical product queries in milliseconds. You can run it on your own server or use Typesense Cloud when you would rather not run the cluster.
Synonyms (“trainers” and “sneakers”, or “patike” and “tenisice”), pinned hits and field weights let a shop manager influence results without a full reindex. Collections swap through an alias, so a rebuild never takes search offline.
Where Typesense fits
- Product catalogues from a few thousand to a few million SKUs, including variants, prices and stock.
- Site and documentation search where typo tolerance matters more than a heavy linguistic analyzer.
- Geo search for stores, branches or classifieds, and vector search when you later add semantic matching on top of keywords.
- Teams that want open-source software and predictable hosting, rather than a usage invoice that grows with every keystroke.
What we deliver
- A collection schema: which fields are searchable, which are facets, which are used only for sorting or filtering.
- An indexing pipeline from your CMS, store or database, with incremental updates and a safe full reindex.
- A search UI: autocomplete, a results page, filters, highlighting and an empty state that offers a correction or a popular query.
- Synonym sets, curation rules and a small admin path so your team can adjust relevance after launch.
Typesense’s official documentation is the reference for the API. For older shops still searching with SQL, we have written separately about bringing a Typesense-powered stack to legacy projects.
Elasticsearch and OpenSearch for Large, Complex Indexes
Elasticsearch and OpenSearch are the right tools when the query model outgrows a simpler engine: deep aggregations, relevance rules, search-log analytics, or an index that already lives in an ELK-style platform. They are heavier. A cluster needs sizing, upgrades, snapshots and someone who understands shards and mappings.
- OpenSearch is the Apache-2.0 distribution we prefer when the licence has to stay permissive. It covers full-text search, aggregations, dashboards and alerting.
- Elasticsearch is source-available under the Elastic License and AGPL. Elastic Cloud removes the cluster work; the licence and the feature set are the trade-off you accept.
- Mappings and analyzers are designed up front. Changing a field type later means a reindex, so we treat the mapping as a schema, not as something to discover in production.
- Aliases point the application at one index while the next one builds, which is how we reindex large catalogues without downtime.
We recommend this tier when you already run the stack, when you need features a lighter engine does not have, or when search and log analytics belong in one place. For a typical online store, the operational cost is hard to justify. The OpenSearch documentation is the reference we follow for cluster and query design.
Meilisearch and Algolia
Meilisearch and Algolia sit at opposite ends of the same idea: search that feels instant, with relevance that works well before anyone tunes it. The difference is who runs the servers and how the bill is calculated.
- Meilisearch is open source (MIT), written for speed and a short API. It suits content sites, directories and catalogues that want typo tolerance and filters without operating Elasticsearch. Meilisearch Cloud is there if you want it hosted.
- Algolia is a hosted service. Relevance, analytics and a mature UI library are included, and there is no cluster to patch. Pricing follows records and operations, so a busy autocomplete on a large catalogue needs a forecast before you commit.
- Instant results on either engine are loaded so they do not block the first paint of the page. The search library starts when the visitor focuses the field, not on every page view.
- A clean exit matters. We keep the index schema and the UI behind a small interface, so moving from a hosted engine to a self-hosted one later is a project, not a rewrite of the store.
Meilisearch’s documentation is a good picture of how small a search API can be. We pick Algolia when the team explicitly wants a managed service and has modelled the usage cost; otherwise an open-source engine on infrastructure you control is the default.
Faceted Search and Autocomplete
The engine is half of the product. The other half is the interaction: a visitor types three letters, sees sensible suggestions, lands on results and narrows them by brand, size, price or topic. Faceted search and autocomplete are where most plugin installs fall short.
Filters that match how people choose
- Facets come from real attributes (brand, category, price range, availability, content type), with counts that update as other filters change. Selecting a brand must not wipe out the other brands in the list.
- Price is a range, not fifty checkboxes. Stock and “on sale” are explicit filters, and out-of-stock products are omitted or pushed down according to a rule you choose.
- On mobile, filters live in a panel that shows how many results the current selection will return before the visitor applies it.
- The URL holds the query and the filters, so a result view can be shared, bookmarked and indexed where that is desirable.
Autocomplete that helps and then gets out of the way
A useful suggestion set mixes products, categories and query completions, highlights the matched letters and can be driven from the keyboard. Requests are debounced, cancelled when the visitor keeps typing, and never trusted as the only path to results: pressing Enter still opens a full results page. A short Typesense query for that results page looks like this:
{
"q": "plava kosulja",
"query_by": "name,description,brand",
"query_by_weights": "4,1,2",
"facet_by": "brand,size,color,in_stock",
"filter_by": "in_stock:true",
"sort_by": "_text_match:desc,popularity:desc",
"num_typos": 2,
"per_page": 12
}Search Analytics and Relevance Tuning
Search gets better only if you can see what people typed. We record the query, the number of hits, the filter set and which result was opened, and we keep personal data out of that log. A weekly look at zero-result queries is usually worth more than another round of synonym guessing.
- Zero results become synonyms, a stemmed or normalized token, or a content gap. If fifty people search for a product you do not sell, that is a merchandising signal, not a search bug.
- Top queries get pinned hits for the products or pages you want to lead with, and bad results get hidden.
- Language for this region needs an explicit decision. Bosnian, Croatian, Serbian and Montenegrin mix ijekavian and ekavian (“mlijeko” and “mleko”), and shoppers omit diacritics (“kosulja” for “košulja”). Typo tolerance covers some of that; synonym sets and a normalized field cover the rest. Cyrillic queries, where you serve that audience, are folded to Latin at index time.
- Ranking signals stay understandable: text match first, then in-stock, popularity or margin, with a rule written down so the next change is deliberate.
- No silent drift. Synonyms and pins live in configuration we can review, not in a plugin screen nobody remembers.
Which Search Engine Fits
There is no universal winner. This is the comparison we use before any index is created:
| Engine | Licence | Who runs it | Best fit | Watch out for |
|---|---|---|---|---|
| Typesense | GPL-3.0 | You, or Typesense Cloud | Stores and content sites that want typo tolerance without a cluster | Very large analytical aggregations are a better fit for OpenSearch |
| OpenSearch | Apache-2.0 | You, or a managed service | Complex queries, large indexes, search plus observability | Cluster operations, mapping changes, memory |
| Elasticsearch | Elastic License and AGPL | You, or Elastic Cloud | Teams already on Elastic, or features tied to that platform | Licence terms and upgrade planning |
| Meilisearch | MIT | You, or Meilisearch Cloud | Fast, simple search for content and mid-sized catalogues | Fewer knobs than Elasticsearch for unusual relevance |
| Algolia | Commercial SaaS | Algolia | Teams that want hosted search and will pay per use | Cost at high query or record volume, and a hosted dependency |
Built-in database search still has a place: a blog with a few dozen posts does not need a dedicated engine. We say so when that is the case.
Indexing, Sync and Fresh Results
A brilliant index of yesterday’s catalogue is a customer-facing bug. Prices, stock and unpublished pages have to move quickly, and a full rebuild has to be possible when the schema changes.
- The store or CMS remains the source of truth. The search index is a derived read model, rebuilt from that source.
- Creates, updates and deletes travel through a queue, so a slow index never blocks checkout or the editor’s save button.
- A nightly reconciliation compares source counts with the index and repairs drift.
- Multi-language fields are separate, with per-locale synonyms, so a German query does not rank through an English description by accident.
- Secrets, customer-specific prices and draft content stay out of any index a public API key can read. Public search keys are restricted to the operations a browser is allowed to call.
Self-hosted engines need backups, metrics and, for a large catalogue, a server of their own. We place that workload the same way as in our guide to deployment across DigitalOcean, AWS, Hetzner and bare metal. When the catalogue is pushing the database, search is the read path that takes pressure off it; our guide to sharding and partitioning covers the database side.
Common Site Search Mistakes We Fix
- Searching with
LIKE '%term%', which cannot use a normal index and gets slower as the table grows. - No typo tolerance, so “reciever” and a missing diacritic both return nothing.
- Indexing drafts, hidden categories or out-of-stock items, then wondering why they appear in suggestions.
- Facet counts that ignore the current filters and show options that lead to zero results.
- A large search JavaScript bundle on every page, competing with the content the visitor came to see.
- No record of queries, so relevance never improves after launch day.
What Site Search Development Costs
We estimate after looking at the catalogue, the platforms and how fresh results must be. The drivers are consistent:
- Catalogue size, number of languages and how clean the product data is.
- The engine and whether you self-host or pay a hosted service.
- How many sources must be indexed, and whether updates are webhooks, a queue or a nightly file.
- The UI: a simple results page, or autocomplete, facets, merchandising and analytics.
- Ongoing tuning: synonyms, pins and zero-result reviews after launch.
Hosted services add a usage fee on top of the build. We include that in the recommendation so the monthly bill is not a surprise.
How We Work
- Discovery: we review the catalogue, languages, current search, and the queries or complaints you already know about.
- Plan: we choose the engine, define the schema, the sync path and the UI, and agree on what “good results” means for your top queries.
- Build: we index a staging copy, implement autocomplete, filters and the results page, and connect updates from the source system.
- Test: we check typos, diacritics, empty results, filter combinations, stock changes and the speed of the search UI on a phone.
- Launch: we switch traffic, watch error rates and zero-result queries, and keep the old search available for a short rollback window.
- Support: we tune synonyms and ranking from real queries and keep the engine updated.
Why CodeWiz
- Open-source first: Typesense, OpenSearch and Meilisearch are the default. A hosted service is a choice we explain, not a starting assumption.
- Stores and the index, together: we build WooCommerce, Magento, PrestaShop, Shopify and custom applications, so the sync matches how your catalogue actually changes.
- Tailored scope: a single collection on one server when that is enough, a cluster when the data demands it.
- Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally.
- The rest of the stack in the same hands: APIs, queues, hosting and performance sit with the same team – more about CodeWiz.
Frequently Asked Questions
How much does site search development cost?
A Typesense or Meilisearch index on an existing store, with autocomplete and a handful of filters, is a focused project. Multi-language catalogues, several data sources, merchandising rules and a self-hosted OpenSearch cluster take longer. Hosted engines add their own monthly fee. You get an estimate after we see the catalogue.
Typesense, Elasticsearch or Algolia?
For most stores and content sites we start with Typesense or Meilisearch. OpenSearch or Elasticsearch earns its place when you need heavy aggregations or already operate that stack. Algolia fits teams that want search fully hosted and have checked the usage pricing. The schema we design does not lock the choice in forever.
Will a new search engine slow my site down?
The index runs as its own service, and a well-built query is faster than a SQL scan of the products table. The risk is the front end: a heavy instant-search library on every page. We load that code when the visitor uses search, so the rest of the page stays light. Google’s guidance is an LCP under 2.5 seconds; search should not be what breaks it.
Can you replace WooCommerce or Magento search?
Yes. We index products, categories and content from the platform, keep stock and price updates flowing, and replace the theme’s search form and results template. The platform stays the place you edit products.
How do you handle Bosnian, Croatian and Serbian queries?
We plan for missing diacritics, ijekavian and ekavian variants, and Latin queries as the baseline. Where the audience searches in Cyrillic, those queries are normalized to the same index fields. Synonym lists are part of the handover, so your team can extend them.
Ready for Search That Finds Something?
Tell us what people cannot find today and which platform the content lives on. We will propose a site search development plan that fits the catalogue. Contact us to talk it through, or see the rest of our development services.