Replacing search engine with Bizzkit Ecommerce Search

Moving from one search engine to another is a well-known exercise, and the technical migration is rarely the hard part. The real work sits in your product data, in deciding who owns search after launch, and in a short tuning period once real customers start typing.

This page describes what to plan for, the mistakes we see most often, and how a typical go-live runs. Everything in it comes from migrations that have already been completed and from reviews of live Ecommerce Search solutions, so you can benefit from those lessons instead of discovering them yourself.

What to plan for

Your product data is the foundation

Ecommerce Search can only find what it receives. Before go-live, check that names, descriptions, brands, colours, sizes, and materials are complete and consistent.

Heads-up: Many "search problems" are in fact data problems.

Good news: You can add your own attributes freely and update data as often as you like.

Plan your data updates early

This is the most important technical decision in the project. Send only what changed: changed products, and only the changed fields.

Heads-up: To do this, your integration must remember what it has already sent. Use a version number, a timestamp, or a hash per product. Please avoid these habits, because they create unnecessary load and slow updates:

Deleting and re-creating products instead of updating them
Sending products or fields that did not change
Sending products long before they become active
Rebuilding the whole dataset as a routine
Asking the search API which data is outdated

Good news: Small, precise updates are fast, so your prices and stock stay fresh. Keep full rebuilds for real exceptions, such as a change to your data model.

See Common pitfalls for more detail on update strategies.

Decide how prices work

Heads-up: Three points to agree on early:

Price groups have no fallback. If you use price groups, every SKU needs a price in every group.
Planned price changes work per hour, not per minute. An immediate update still takes effect at once.
Price groups require authenticated search, so your frontend must request a token for logged-in customers.

Good news: You can plan a whole sale period in advance with valid-from dates, and different customer groups can see different prices from the same index.

Keep complex promotions, such as vouchers and coupon codes, in your own solution. Simple cases can be handled with price groups. See Planning price changes.

Someone needs to own search

Search moves out of the IT backlog and into the hands of the business. That is a big win, but only if a person is given the role.

Heads-up: Appoint a search manager and reserve a few hours per week in the first months. The role is wider than maintaining synonyms and suggestions. Those tasks are the busiest during the first weeks, and they become a small routine afterwards. From then on, the interesting work begins: reading the dashboards, using diagnostics to understand why a result looks the way it does, designing experiences for campaigns and category pages, tuning commercial sorting and facets, and testing changes in the playground before publishing them.

Heads-up: This work does not require a developer, but it does reward a structured and curious person who is comfortable with data and enjoys learning a professional tool. Choose someone who wants to become the expert, not someone who only has a free hour.

Good news: The person who knows your customers and your assortment can go far, because every part of the tool is built for business users and every change can be tested safely before it goes live.

Involve more than one part of the business

Search touches many teams, and each of them sees something the others do not.

Our recommendation: give several roles access, and agree on how they work together:

Customer support hears the exact words customers use, and notices quickly when something cannot be found.
Back office and merchandising know the assortment, the campaigns, and which products should be promoted or buried.
The e-commerce manager owns the numbers, and can connect search behaviour to conversion and revenue.
Marketing knows the campaign calendar, so search can be prepared before a campaign starts instead of after it.

Good news: Search then becomes a shared tool rather than the task of one person, and you avoid the situation where all knowledge disappears when that person is on holiday or changes job.

Language work takes a little time

Text analysis uses dictionaries for synonyms, hypernyms, misspellings, irregular words, and ignored words. Each segment covers one language.

Heads-up: Building your first dictionaries is a real task, and it improves over time rather than ending. Plan one segment per language, and separate segments for B2B and B2C.

Good news: Dictionaries can be shared between segments, the dashboard tells you which words to fix next, and the Bizzkit AI Assistant helps you validate them.

Frontend integration is real development work

Ecommerce Search delivers products, SKUs, content, facets, suggestions, "did you mean", and related tags through REST APIs.

Heads-up: Reserve development time for the search page, quick search, and category pages. Agree early on how product data reaches Ecommerce Search from your PIM or ERP.

Good news: Ready-made SDKs are available, and one Unified Search call returns everything a search page needs.

Measure before you switch

Heads-up: Write down your current numbers before go-live: search conversion rate, zero-result rate, click-through on search, and response times.

Good news: With a baseline you can prove the value of the change, and the dashboards help you keep improving.

Classic mistakes to avoid

These are the findings that appear most often in reviews of live solutions.

Use hypernyms, not synonyms, for word families

A synonym means "these words are identical". If you make wool yarn and cotton yarn synonyms, a customer searching for wool yarn also gets cotton yarn. That is not what you want.

Model it as a hypernym instead: yarn is the general word, wool yarn and cotton yarn are the specific ones. A specific search then gives specific results. Hypernyms can have several levels, for example peeler, then vegetable peeler, then potato peeler.

Use attributes to improve relevance

Add attributes such as product type, brand, colour, and material as searchable fields, and give them a high relevance boost.

Then a search for red trousers ranks trousers that really have colour = red above trousers that only come in a red bag.

Remember to allow your filters

A field can only be used as a filter or a facet if it is on the allowed filters list first. Not every allowed filter needs to become a customer-facing facet, because some are only for your own service-level filtering.

Use alternative search words with consideration

Alternative search words are a quick and precise way to make a single product easy to find, and many customers use them happily in the beginning, while the team is still becoming familiar with the dictionaries. That is a perfectly good start.

Just keep in mind that they are managed per product. As the list grows, so does the manual work, and results can become inconsistent because a rule that helps one product does not help similar products. As your team grows more confident, move the general cases into synonyms, hypernyms, and misspellings, which work across your whole assortment, and keep alternative search words for the specific products that need them.

One practical detail: do not enable partial matching on them. The words are invisible to your customers, so a partial match is confusing. A product with the alternative word training would otherwise also appear in a search for tra.

Keep quick search and full search consistent

Customers get confused if the same phrase gives a different order in the quick search and on the search page. This happens when the two use different endpoints, or different commercial values and relevance boosts.

Our recommendation: use Unified Search for both, and keep the same weights. It is still a good idea to have separate experiences, so you can show a different set of facets.

Let relevance lead, and commercial sorting follow

Commercial sorting breaks a tie. When two products match the phrase equally well, it decides which comes first. It should not overrule relevance.

Stock is the usual exception, because a sold-out product is rarely what the customer wants. Rather than giving stock a very high commercial weight, use the bury feature. A bury rule on In stock = false moves sold-out products below all other results, but keeps them easy to find for customers who search for them directly. You can also bury by category or by a product attribute, which is useful for clearance items and discontinued colours.

Do not control pinning from your PIM

It looks convenient to mark products as "pinned" in the PIM and boost that value. The problem is that it then applies to every experience.

For example, if duct tape is pinned because its description says it can fix a bike, a search for bike may return duct tape as the best match. Pin products in the search experience where you actually want them, and use it sparingly. See also Commercial sorting best practices.

It is tempting to create a facet for every attribute, and to let every scope return every field. Both cost response time.

Our recommendation: for each experience, ask which facets really help the customer choose, and let each scope return only the fields that page needs.

Watch out for category names that join two words

A category called screws and nails means a search for screws also returns nails. This is worth knowing when you review search quality, because the same names are often useful for browsing.

Support the customer journey in your frontend

Ecommerce Search is built around best practice for search user journeys and CRO. Every search response contains the building blocks for that journey, and we recommend implementing all of them in your frontend, because the frontend is where your customer actually meets them.

In our experience this is the part that is easiest to underestimate. The admin interface and the frontend work together, and even perfect tuning cannot show a customer something the frontend does not display.

Each step of the journey has its own element:

Before the customer types. Quick search spotlight fills the empty search box with up to ten phrases, either automatically from your most popular searches or curated for a campaign with a start and end date. It gives direction to customers who do not yet know what they want, in a place that is often left blank.
While the customer types. Suggestions lead towards phrases that are known to give good results, so the customer reaches a useful result page instead of an empty one.
Straight to the goal. When a phrase clearly matches a category, product, or brand, redirects let you send the customer directly to that page. Fewer steps to the goal is one of the most reliable ways to increase conversion. This requires your frontend to act on the action object in the response.
Narrowing the result. Related tags turn red into red hoodie with a single tap. This is especially valuable on mobile, where typing is slow, and it reduces the number of customers who give up on a long result list.
Choosing with confidence. Facets need real room in the design, on mobile as well as on desktop. When filtering is hidden behind an unclear button, customers scroll instead of narrowing, and long result lists convert poorly.

Our recommendation: treat this as a design task as much as a development task. Walk through the search journey with a designer before development starts, and decide where each element belongs on desktop and on mobile. It is usually a small effort with a measurable effect on conversion.

Tell the customer when you changed the phrase

If a search gives no results, Ecommerce Search automatically retries with the best did you mean phrase. This saves many empty result pages.

Our recommendation: compare originalPhrase and usedPhrase in the response. If they differ, show a short message such as "No results for X. Showing results for Y." and let the customer click back to their own phrase. Your frontend then repeats the search with forceSearch set to true.

Features that save you work

Several things you may be planning to build are already included.

Signal parameters. Ecommerce Search can boost products from real customer behaviour: turnover, number of order lines, and clicks. The values are collected through Bizzkit Event Tracking and refreshed every hour from the last 24 hours of events, so your ranking follows what customers actually buy. You do not export sales figures or build an analytics integration, because you create the parameter, give it a weight, and it keeps itself up to date.
Semantic search. For your most popular phrases, and for phrases that often give zero results, Ecommerce Search can match on meaning instead of exact words. It understands that coat and long jacket are related, so a customer searching for coat also finds the long jackets, even when that word appears nowhere in your data.
Agentic search. When a search still gives no results, an AI agent can reason about what the customer really wants and suggest specific products. This is what handles a long sentence such as outdoor pool my grandkids can have in. It is a preview feature today, so plan it as a natural next step rather than part of your first release.
Redirects. Beyond sending customers to the right page, you can exclude phrases such as sale from ever redirecting, and map phrases manually, for example sneakers to your Running shoes category. That gives your marketing team control over branded search terms without involving a developer.
Suggestion generators. You do not have to write your suggestions by hand. They can be generated from fields you already have, such as brand and product type, and from combinations such as brand plus category.
Content search. Customers can also find your articles and guides, not only products. Setup is a simple mapping between your CMS and your search segment. Product search is the more advanced of the two, so plan facets and relevance tuning around products.

Migration and go-live

A proven order of work:

Confirm your own setup. Review your segments, experiences, synonyms, and searchable fields before you migrate, and let your business team approve them. Check that fields such as product ID, product name, product number, SKU ID, SKU name, and SKU number have the correct partial-match setting.
Ingest your product data and verify it. Once your data is in place, send real search requests and check the results before any customer sees them.
Pick a quiet migration window and ask your team to avoid product updates during it.
Keep the old engine ready. Make sure you can still run the old solution, so you can compare results side by side and roll back if needed. Write the rollback steps down before you start, including how to rebuild the old index.
Roll out gradually. How you do this depends on your own hosting setup, for example a staging environment first, a small share of live traffic, or one instance at a time. Whichever method you use, verify search after each step, and finish by testing from the outside, exactly as a customer reaches your shop.
Test the whole journey, not only the search box. Search touches more than you expect. A good test list covers quick search, suggestions, all filters and sortings, category pages, brand lists, colour pickers, the product detail page, related products, add to basket, checkout, order confirmation, and generated feeds.

After go-live

Plan a hypercare period of two to four weeks with active monitoring. Look for missing results and optimise searches with zero results. The dashboard and diagnostics show you exactly where to look.
Expect small adjustments so that behaviour matches what your customers were used to. This is normal and quick to do.
Remember that changes go live only when you publish. You can test everything safely first and roll back to an earlier version at any time. If something looks wrong on the website, first check whether it has been published.
Turn off the old engine last. Reduce its size right after go-live to save cost, but only delete it and end the agreement when a rollback is no longer relevant. Then clean up the old services, sites, and databases.
Stay up to date. Go-live is the starting point, not the finish line. Set aside a little time each quarter to look at what has been added and decide what is worth adopting. A search solution that is never revisited slowly falls behind the shop around it, while a solution that is kept current keeps improving with no big project.
Follow the yearly API version. A new major version of the Bizzkit APIs is released once a year, in the first quarter, and it is the only release that may contain breaking changes. The changes are usually small, but they do need attention, so reserve a little development time for them every year. Each major version keeps supporting the previous one, which gives you at least a year to move, and a preview API is available if you want to test the changes in advance. See Versioning strategy.

Good news: Ecommerce Search is developed at a high pace. Because it is a cloud product, new features and fixes reach you continuously, and you never have to install or host anything yourself. Some features you simply switch on, while others need a little work in your frontend before your customers see them. You do not have to follow that development on your own either, because your solution partner is always happy to advise you and to give inspiration on which new features fit your setup, and where your next improvements are likely to be found.