Smart search on Typesense: 50 times faster than built-in WooCommerce

Last week the owner of an online auto parts store wrote to me. He has 14 thousand positions in the catalog, WooCommerce, hosting for three thousand rubles per month, and one very specific pain - search. The person says: “The client enters the part number, presses Enter, waits six seconds, gets an empty result, and goes to a competitor. I'm losing money every day and I can't figure out what to do about it." I asked what he had already tried. It turned out that I installed three different search plugins, one paid for $79 a year, and none of them really solved the problem. The search was still slow, it didn’t forgive typos, and I didn’t understand Russian morphology at all. The word “bearing” was found, but “bearings” was no longer found.

This story is no exception. I hear this almost every week from different people, with different stores, but with the same problem. And you know what amazes me most? It’s not that WordPress’s built-in search is bad—that’s been known for a long time. And the fact that a huge number of store owners do not even suspect how bad it is and how much money they lose because of it every month. They attribute low conversion to competition, to seasonality, to advertising - to anything other than that small search box in the site header, through which 30 to 60 percent of all buyers pass.

Let's look at why this happens, what you can do about it, and why we ended up building our own Typesense search module right inside our COS WP Woo plugin. I will tell you without embellishment - with real numbers, with the rake that we stepped on, and with the results that we got in a combat store with almost seventeen thousand products.

Why the built-in WordPress search is a death sentence for an online store

To understand the scale of the problem, we need to take a second to look under the hood. When a customer types a query into the standard WordPress search bar and presses Enter, the following happens: WordPress takes that query and generates an SQL query against the MySQL database. Moreover, it does this in the most primitive way possible - through the LIKE operator with percentages on both sides. Translated into human language, it sounds something like this: “Dear database, please go through each row of the wp_posts table and check if the post_title or post_content field contains this sequence of characters somewhere within itself.” No index, no optimization, no nothing - just a complete search, line by line.

On a blog with fifty articles this works fine. In a store with a thousand products, it’s tolerable. But when you have ten, fifteen, twenty thousand positions, and each product has meta fields, attributes, descriptions, variations - this turns into a disaster. MySQL is starting to choke. The request, which should be executed instantly, takes from one and a half to three seconds. And if the server is loaded with other tasks at that moment, it’s easy in five to six seconds.

But slowness is not so bad. The real problem is that this search is stupid. He does not understand morphology - if a product is called “Synthetic motor oil”, and the buyer is looking for “motor oils”, a standard search will not find it. Because “motor” and “motor” are different strings for the LIKE operator. It doesn’t forgive typos - you typed “Shell oil” instead of “Shell oil”, and that’s it, zero results. He doesn’t know how to be relevant - if three hundred products match a query, they are ranked not by importance, but by publication date. An industrial cable for two hundred rubles will be higher than a generator for a million simply because it was added to the catalog later.

I thought for a long time why WordPress, after twenty years of existence, has not acquired a normal search. And I came to the conclusion that the problem is not the laziness of the developers, but the architecture. WordPress was designed as a blogging engine, and searching a blog is a completely different task than searching a product catalog. For a blog, just search for an article using keywords. For a store, you need to find a product by article, by brand, by characteristic, by synonym, by part of the name, taking into account typos - and do this in a split second, with instant preview and filtering. WordPress is simply not created for this, and no plugins that try to “finish” the standard WP_Query will fundamentally solve this problem. You can't fix what's broken by design.

Here's the thing: most WooCommerce "search plugins" do just that - try to improve a standard query. They add a search by meta fields, by SKU, and improve relevance through additional JOINs to tables. And it gives an effect - by twenty, maybe thirty percent. But the fundamental problem remains: the search still goes through MySQL, still through exhaustive search, still without morphology and without normal handling of typos. It's like trying to win a Formula 1 race in a Zhiguli by simply painting it red and sticking a spoiler on it.

Typesense - when I first saw the difference

We didn't come to Typesense right away. First we looked at Elasticsearch, a recognized full-text search standard used by Amazon, eBay and half of the world's major e-commerce sites. Technically, Elasticsearch is great. But for a small and medium-sized online store, it’s like buying a mining dump truck to transport products from Pyaterochka. Elasticsearch requires at least two gigabytes of RAM just to run. In practice, for comfortable work you need four to eight gigabytes. This is a separate server or a powerful VPS. Plus the Java stack, plus the complex configuration, plus the need for monitoring and maintenance. For a store with ten to fifteen thousand products, it’s like shooting sparrows from a cannon, and the cannon is also expensive to maintain.

Then a colleague recommended Typesense. To be honest, I was skeptical - the open-source project is not as widely known as Elasticsearch or Algolia. But I decided to try it, and the first test literally amazed me. We loaded an index of fifteen thousand products into Typesense, and the search query began to execute in five to twelve milliseconds. Not seconds - milliseconds. For comparison, the same request through a standard WooCommerce search on the same catalog took from eight hundred to one and a half thousand milliseconds. The difference is not several times, but tens of times.

But speed is only one side of the coin. Typesense out of the box can do something that MySQL will never be able to do: search taking into account typos, the so-called typo tolerance. The buyer types “Castrol” instead of “Castrol” - and still finds the necessary oils. Writes “hydraulic oil” - Typesense understands that this is a typo and gives the correct results. For a Russian-language store, this is critically important, because the Russian keyboard layout and Latin brand names are an endless source of typos. People switch layouts at the wrong moment, write in transliteration, confuse “i” and “th”, “e” and “e” - and Typesense processes all this correctly.

Separately, it is worth mentioning the morphology. For the English language this is not so critical - the morphology there is relatively simple. But the Russian language is a different story. In our country, one noun can have twelve forms, and a verb can have even more. “Oil”, “oils”, “oil”, “oil”, “oil”, “oils” - all these are the same product, and the search engine must understand this. Typesense supports Russian morphology, and it doesn’t work perfectly - there are edge cases - but it’s an order of magnitude better than stupid string comparisons in MySQL.

Typesense also consumes ridiculously few resources compared to Elasticsearch. For an index of twenty thousand products, one to two hundred megabytes of RAM are enough. It is written in C++, runs as a single binary, does not require Java, and does not require complex infrastructure. You can install it directly on the same server where WordPress runs, and it will coexist peacefully, consuming a minimum of resources. Or use the cloud-based Typesense Cloud - there is a free plan for small projects and quite affordable paid plans.

When I saw all this in action, it became obvious: WordPress's built-in search needs to be replaced entirely, not "improved." And we started building a Typesense integration right inside our plugin so that a store owner could get Algolia-level search, but without paying hundreds of dollars in monthly fees and without having to figure out how to set up search engines.

How we built it - and what kind of mistakes we stepped on

The idea sounds simple: we take data from WooCommerce, load it into Typesense, display the results via an AJAX widget. In practice, of course, everything turned out to be more complicated. The first question that arose was what exactly to index. The name of the product is obvious. Description too. And then the nuances begin. SKU (article number) is a must, because many B2B buyers search specifically by article number. Product attributes - yes, because a person might search for “5W-30 oil” and expect the search to find products with the 5W-30 viscosity attribute. Price - needed for facet filtering so that you can filter results by price range. Categories are for the same facets. Brand - the same. In stock - because there's nothing worse than finding the perfect product only to find it's out of stock.

We've gone even further and added content-based indexing for PDF files attached to products. This sounds exotic, but for industrial stores, where each product is accompanied by technical documentation, safety data sheets, and certificates, this changes the rules of the game. The purchasing manager can enter the GOST number or the name of a specific approval, and the search will find products in whose documentation this GOST is mentioned. Previously, this required opening each PDF manually.

The next task is synchronization. The Typesense index must be up to date. When a manager adds a new product, changes the price, updates the description, these changes should be reflected in the search. We implemented this through Action Scheduler, a built-in WooCommerce task scheduler. Each time a product is saved, a hook is triggered that queues the task of updating the index. SearchIndexerJob picks up this task and updates the corresponding document in Typesense. This happens asynchronously, in the background - the manager does not wait for the index to be updated, he simply saves the product and moves on.

Honestly, it was with synchronization that we suffered the most. The first version updated the index synchronously, right in the save_post hook - and when mass importing goods from 1C, this killed the server. Imagine: a package of three hundred products arrives, and for each one there is an HTTP request to Typesense. Three hundred requests per minute is still tolerable, but if the import comes in chunks and there are fifteen thousand products, the server begins to choke. We switched to the queue via Action Scheduler - and the problem went away. Now, during bulk import, tasks to update the index are queued and processed in batches, without loading either WordPress or Typesense.

Another non-obvious problem is initial indexing. When a store just connects the search module, it needs to index the entire catalog. For a store with a thousand products, this takes a minute or two. For our combat store with 16,844 products, the initial indexing took about twenty minutes. We optimized the process by breaking it into batches of 250 products, with pauses between batches so as not to overload the server. A progress bar is displayed in the admin panel - the owner sees how many percent have been indexed and can easily do other things.

There was also a story with encodings. Typesense works fine with UTF-8, but some WordPress stores have products with tricky characters - non-breaking spaces, special dashes, brand symbols. One oil store kept a "™" in their product names, and it broke JSON serialization when sent to Typesense. I had to add text normalization before indexing - clearing invisible control characters, replacing “smart” quotes with regular ones, and other joys of working with real data.

Separate chapter - facet filtering. When a customer searches for “motor oil,” he gets, say, four hundred results. Without filtering, this is useless - no one will flip through four hundred cards. You need facets: filter by brand (Shell, Castrol, Lukoil), by viscosity (5W-30, 10W-40), by type (synthetic, semi-synthetic), by price (from 500 to 2000 rubles). Typesense supports faceted filtering natively - we simply specify which fields are faceted, and the engine automatically counts the number of products in each category. The user sees not just a list of filters, but filters with quantities - “Shell (47)”, “Castrol (32)” - and can quickly narrow down the results to the desired products.

Synonyms, curation and analytics - the three pillars of smart search

There are three things that separate a truly smart search from a simply fast one. The first is synonyms. Each niche has its own jargon, its own abbreviations, its own alternative names. In the oil store, “transmission” = “gear oil” = “gear oil” = “gear oil”. In an electronics store, “mobile” = “smartphone” = “telephone” = “cell”. In a building materials store, “plasterboard” = “gypsum board” = “dry plaster.” If the search engine doesn't know these synonyms, it loses customers.

We've made managing synonyms as easy as possible. In the WordPress admin panel, in the search section, there is a “Synonyms” tab. You add a group of synonyms - for example, “gear oil”, “transmission”, “gear oil” - and Typesense begins to consider all these terms as equivalent. The buyer enters any of the options and receives the same set of results. Setup takes five minutes, and the effect is dozens of saved search sessions per day.

There is another type of synonyms - unidirectional. This is when Mobil must find Mobil branded products, but not vice versa. Or when "power steering fluid" should find "power steering oil", but the search for "power steering oil" does not have to include everything labeled "power steering fluid". Such subtleties are especially important in technical niches where terminology can be ambiguous.

The second important thing is curation of results. There are requests that are strategically important for the business. For example, you know that the query “motor oil 5W-30” brings you the most search buyers. And you want the first items in the search results to be not just any random 5W-30 oil, but specific items - maybe with the highest margin, maybe from a partner brand, maybe those that are currently on sale. Curation allows you to record the positions of specific products in search results for specific requests. You say: “When searching for “5W-30 oil”, always show Shell Helix Ultra first, Castrol Edge second, and hide product X from the search results altogether.” And it works.

I know that some people are offended by the idea of ​​manually tweaking search results. They say that the search must be objective, the algorithm must decide. And in theory this is true. But in practice, business is not an academic exercise. You have products that need to be promoted. There are goods that need to be sold. There are partnership obligations. And smart merchandising in search is as legitimate a tool as merchandising in a physical store, where candy is always at the checkout counter and milk is always in the farthest corner.

The third and perhaps most underrated feature is search analytics. We record every search query: what they were looking for, whether they found something, whether they clicked on a result. From this data, a picture emerges that cannot be obtained in any other way. You see that in the last month, two hundred people searched for “antifreeze red G12”, and not a single one found any results - because in your catalog this product is called “coolant G12+ red”. Add a synonym - and two hundred lost search sessions per month turn into two hundred found products and potential sales.

Or another example. You see that a hundred people a month are looking for a specific article - let's say, "550046983". This is a Shell oil part number that you do not have in the catalogue. But you have an analogue from another manufacturer. Without search analytics, you would never know that these hundred people come, don’t find the product and leave. And now you see this request in the top “searches without results” and you can make a decision: either add this product to the catalog, or set up a synonym that will redirect this request to an analogue, or at least show the banner “Didn’t find this item? Try our analogue...”

Search analytics is essentially a direct line of communication to the needs of your buyers. They themselves tell you what they want through the search bar. All that remains is to listen.

We show analytics in a convenient form: top queries, queries without results, queries with low CTR (when people find results but don’t click, which means the results are irrelevant), trends by day and week. A store manager can go to the analytics section once a week, spend fifteen minutes, and get more useful information about demand than from any market research.

Search widget - what it looks like for the buyer

Everything I talked about before is the backend. Indexation, synonyms, analytics - the buyer does not see any of this. He sees a search bar, and his experience with it determines whether he buys something or leaves. Therefore, we did the search frontend with special care.

The search widget works like this. The buyer begins to enter text - and after the second or third character, a drop-down window with results appears under the search bar. Not just text links, but full-fledged product cards: thumbnail image, name, price, availability in stock. The buyer sees the results even before he completes the request and presses Enter. This is called search-as-you-type, and it is the standard that people have become accustomed to thanks to Google, Amazon and other large platforms. When your store can do this too, it’s not just convenience, it’s a signal: “We are a serious store, everything here works as it should.”

A request to Typesense goes out with each keystroke, but with a debounce of 200 milliseconds - so as not to bombard the server with requests while the buyer is typing quickly. The response comes in 5-50 milliseconds, and the results are updated instantly. The feeling is as if the results are already ready and just waiting to be shown.

The widget can be inserted onto any page via a shortcode. You can put it in the site header instead of the standard WordPress search - to do this, in most themes you just need to add a shortcode to the desired widget block. Can be placed on a separate search results page. Can be used as a landing page element: “Find the oil you need in 3 seconds” - and there’s a search line that instantly shows the results. This works as a powerful element of trust because it demonstrates to the buyer that the catalog is really large and easy to navigate.

When a customer presses Enter or clicks "Show All Results", they will be taken to a search results page. This is where facet filtering, which I talked about earlier, comes into play. On the left is a filter panel with categories, brands, price range and attributes. On the right are product cards with pagination. Filters work instantly - without reloading the page, via AJAX. Clicked on “Shell” - the list was updated in a split second, showing only Shell products. I removed the filter and the whole list came back. This is the level of UX that customers are accustomed to on marketplaces, and which sharply distinguishes your store from competitors, where the search returns all the results in one endless sheet without the possibility of filtering.

I’ll tell you separately about highlighting matches. When a customer searches for “HLP 46 hydraulic oil,” the search results highlight the words found in bold or color. The buyer instantly sees why this particular product appeared in the search results and can quickly assess its relevance. It's a small thing, but it significantly improves the experience and reduces the time from request to click.

And one more thing that is often overlooked is adaptability. The search widget works correctly on mobile devices. And mobile traffic now is 60-70 percent for most online stores. On a phone, a drop-down window with results takes up the entire width of the screen, product cards adapt to a narrow screen, filters on the results page are collapsed into a sliding panel. Nothing breaks, nothing fits on top of each other. It would seem like an obvious requirement, but you’d be surprised how many search plugins still work crookedly on mobile phones.

16,844 products - how it works in battle

Theory is good, but let's talk about real experience. We have a lubricants store - 16,844 products, WooCommerce, a custom theme based on Porto, and our COS WP Woo plugin with a search module on Typesense. This store is our combat training ground, where we test all functions on real data and real customers.

Before the introduction of Typesense, the search on this store worked through standard WooCommerce with several improvements - search by SKU and by attributes through an additional plugin. The average response time to a search query ranged from 800 to 2000 milliseconds, depending on the server load. On mobile devices, where every second counts, it was disastrously slow. We didn’t collect search query analytics at all—there was no tool.

After launching the search module on Typesense, we carried out a full indexing of the catalog. More than sixteen thousand products - indexing took about twenty minutes in the background, through Action Scheduler. The index size in Typesense is about one hundred and fifty megabytes. RAM consumption by Typesense itself is about two hundred megabytes. For a server with eight gigabytes of RAM, this is imperceptible.

The average search query response time after switching to Typesense is 8-15 milliseconds. This takes into account the network latency between WordPress and Typesense, which is on the same server. For the consumer, this looks like an instant response - he starts typing, and the results appear before he can even lift his finger from the key.

We started collecting search analytics from day one, and it quickly showed interesting things. It turned out that a significant part of buyers search for products by article number - not by name, but by alphanumeric code. This is typical for the B2B segment: the purchasing manager has a specification with articles and simply punches them in one by one. For such a scenario, instant search with auto-completion is a huge time saver. Instead of waiting three to five seconds each time for the results page to load, the manager receives an answer instantly and can process the order many times faster.

Another discovery from analytics is the number of queries with zero results. In the first week there were about 15 percent of the total. That is, every sixth or seventh buyer did not find what he was looking for. We analyzed these queries and discovered several patterns. Some of the requests were typos and alternative spellings, which were resolved by setting up synonyms. Some of them were requests for products that really weren’t in the catalog, but that made sense to add. Some are requests for products that were in the catalog, but under a different name. After a month of working with analytics and synonyms, we reduced the share of requests with zero results to 4-5 percent. This means that about ten percent of buyers who previously left empty-handed now find what they are looking for.

Here is a specific example. Buyers often searched for “VMGZ” - this is a brand of hydraulic oil that is well known in the industry. But in the catalog the product was called “Hydraulic oil VMGZ-45”, and a standard search found it only by full occurrence. If the buyer simply entered “VMGZ” without “-45”, there was a result, but if he entered “VMGZ oil”, the search was already lost because the words were in a different order. After switching to Typesense, this problem disappeared - Typesense searches in all fields, takes into account word order, and finds partial matches. Plus, we added synonyms: “VMGZ” = “VMGZ hydraulic oil” = “VMGZ-45 oil” - and now any of these queries leads to the correct products.

If we talk about the impact on business metrics - and here we need to be honest, we did not conduct a pure A/B test, so I cannot say with scientific accuracy that the conversion increased by X percent precisely because of search. But we see a correlation: after the introduction of the new search, the percentage of search sessions that end with adding an item to the cart has increased. Buyers began to use search more often instead of navigating through the catalog - which is logical, because search is now faster and more reliable than searching through categories. And the number of support requests with the wording “I can’t find the product” has practically disappeared.

I will not give specific figures for conversion growth, because I think this is dishonest - too many factors influence conversion, and it is impossible to isolate the contribution of one of them without a controlled experiment. But I can say with confidence: a quick smart search removes one of the most annoying obstacles between a buyer and a purchase. And removing obstacles is the essence of conversion optimization.

There is another aspect that is rarely discussed - server load. A standard WooCommerce search is a heavy SQL query that loads the MySQL database. Each search query is a JOIN of several tables, a full-table scan, CPU and disk I/O consumption. When ten people are searching on the site at the same time, there are ten heavy queries at the same time. On a hosting with limited resources, this can slow down not only the search, but also the entire site - catalog pages, cart, checkout. With Typesense, the search load is completely removed from MySQL. The database does what it should - processing orders, updating balances, working with the shopping cart. And the search is processed by a separate engine optimized for this. This is especially critical during peak loads - sales, promotions, when traffic increases significantly.

We noticed at our store that after moving the search to Typesense, the average MySQL load decreased by fifteen to twenty percent. This doesn’t sound like a lot, but in practice it’s the difference between “the site is stable” and “the site periodically slows down during peak hours.” And for a store that receives orders worth tens and hundreds of thousands of rubles, every second of delay at checkout is a potentially lost order.

And we can’t help but mention document search. This is a feature that few people implement, but which is invaluable for industrial and B2B stores. Our module can index the content of PDF files attached to products. Technical data sheets, certificates of conformity, safety data sheets, instructions for use - all this is text, and all this becomes available through a search. The engineer enters the TU or GOST number, and the search finds products in whose technical documentation this standard is mentioned. For a company that purchases industrial lubricants, and where the choice of oil is determined not by price, but by compliance with a specific standard, this fundamentally changes the experience of working with the catalog. They no longer call the manager and ask “to find an oil that complies with GOST 17479.4-87” - they find it themselves, in three seconds, through a search.

A special pride is the speed of re-indexing. When we connected synchronization with 1C through our own integration module, and every night the store receives updates of prices and balances for all sixteen thousand products, it was important for us that the search index was updated just as quickly. Typesense handles updating a single document in 1-2 milliseconds. Sixteen thousand updates is about thirty seconds in total. By comparison, reindexing Elasticsearch for this volume would take minutes, if not tens of minutes, depending on the configuration.

I’ll tell you about another situation that well illustrates the difference between “search works” and “search works correctly.” In our catalog we have oils of different packaging - the same oil can be sold in a 1 liter, 4 liter, 20 liter canister and in a 208 liter barrel. These are four different products with different prices, different articles, but essentially the same product. When a buyer searches for “Shell Helix HX8 5W-30”, he expects to see all the packaging side by side so he can choose the one he needs. A standard WordPress search returned them mixed with other Shell oils because relevance was determined by word order in the title and date of publication. Typesense ranks by degree of match - an exact name match is always higher than a partial match, and all four packages are in the first positions, grouped in a natural way. The buyer immediately sees all the options and can choose without scrolling through three pages of results.

Another point that I consider fundamentally important is data security and isolation. Typesense only indexes data that you explicitly choose to index. It does not have access to the WordPress database, does not know user passwords, does not see orders, and does not store personal data of customers. The index contains only product information: name, description, price, attributes, images. For stores that work with corporate clients and must comply with requirements for the processing of personal data, this is a significant plus. The search engine physically cannot “leak” anything other than public catalog information, because there is nothing else in it.

And I also want to talk about cost of ownership, because this is the question that gets asked most often. Algolia, Typesense's best-known competitor in the cloud search world, starts at $1 per thousand searches. Sounds cheap until you do the math. If you have a thousand visitors per day, and each makes an average of three search queries (one basic and two qualifying queries with autocomplete), that's 90 thousand transactions per month. Plus indexing - each product update is also considered an operation. For a store with sixteen thousand products and active trading, the bill from Algolia can easily be 50-100 dollars per month. And despite the fact that Algolia is an excellent service, I won’t say anything bad about it.

Typesense Cloud is significantly cheaper, starting at $29.99 per month for a dedicated instance that handles an unlimited number of requests. No transaction fees, no bills, no surprises at the end of the month. And if you are ready to install Typesense on your server, it’s completely free, because Typesense is completely open-source. For our combat store, we chose the self-hosted option - Typesense runs on the same server as WordPress, consumes two hundred megabytes of memory and does not cost a penny. The only “cost” is the initial installation time, which takes about thirty to forty minutes for a person familiar with Linux, or a few clicks if using Docker.

When I compare the cost of Typesense to how much a store loses due to poor search, the difference is so obvious that the question itself seems rhetorical. One lost order per day—let’s say the average bill is three thousand rubles—that’s ninety thousand rubles a month. One. And how many orders are lost when 15 percent of search queries end in zero results? When does search not understand typos? When a customer waits three seconds and goes to a competitor who gets instant results? I don’t want to speculate on specific numbers, but the scale of the losses clearly exceeds the cost of the solution—by orders of magnitude.

Here's what I realized while working with search: proper search is not a feature, it's infrastructure. This is the same critical part of an online store as the shopping cart or checkout. You can have the perfect catalog, beautiful design, fast delivery - but if the buyer cannot find the product he needs, nothing else matters. And yet, search is one of the most underinvested parts of most WooCommerce stores. People spend thousands of dollars on advertising, attract traffic, and then lose customers due to the simplest thing - “I didn’t find what I was looking for.”

What if we look at it from the other side? Every ruble invested in improving search does not work to attract new traffic, but to convert existing ones. You don’t pay per click, don’t pay per impression - you simply stop losing those who have already arrived. And in this sense, the ROI from a good search can be significantly higher than the ROI from another advertising campaign.

I've been thinking a lot about why the WordPress community has tolerated poor search for so long. And I think the fact is that most store owners simply don’t know how it could be different. They are accustomed to the fact that search is a slow thing that does not always find what they need. They didn’t see how search works on Amazon or Ozon, and didn’t think that the same technology is available for a WooCommerce store. And when you show them the difference - you literally open two browser windows, one with standard search, the other with Typesense, and enter the same query - people's jaws literally drop. “Was it possible to do that?” - the most common reaction.

Yes, that's possible. And it is necessary. And we made it as accessible as possible - we built it right into the plugin, with step-by-step setup, an easy-to-understand admin panel, and automatic synchronization. No dancing with a tambourine, no programming, no separate servers - although this option is also available for those who need scalability. Connect Typesense Cloud or install it on your server, specify the API key in the settings, click “Index” - and in twenty minutes you have a search that works fifty times faster, understands typos, Russian morphology and articles. This is not a marketing exaggeration, this is literally what happens.

And the last thing I want to say. We didn't stop at what we have now. Search is a living system that must evolve with the store and customer expectations. Our immediate plans include personalizing search results based on purchase and browsing history, integration with a recommendation engine, and voice search for mobile devices. The world of e-commerce is moving towards an increasingly intelligent customer experience, and search is at the forefront of this movement.

In the meantime, if you have a WooCommerce store with more than a thousand products and a standard WordPress search, try typing some query with a typo and look at the result. If the result upsets you, then it’s time to change something. And I know where to start.

Try COS WP Woo - 14 days free.Install the plugin, connect the smart search module to Typesense and see how your customers' experience will change. No functionality restrictions, no card binding. Just fast, smart search that finds what your customers are looking for—in milliseconds, not seconds.