Site Search Migration: How to Switch Search Engines Without Losing Traffic or Sales

The riskiest part of a site search migration is that a worse search breaks nothing. No error appears; visitors find less and leave, and weeks later sales dip with nobody connecting it to the search box.

The short answer: measure the old search first, so you have a baseline. Test the new one on your own real searches before any visitor sees it, run both side by side, carry over the rules and redirects the old search depended on, and check that analytics still record searches. Then switch in stages with the old search as a fallback, and agree in advance the numbers that would make you switch back.

This guide is for CTOs, heads of digital and e-commerce managers replacing an old search: a hosted provider, an Elasticsearch cluster nobody wants to maintain, or a platform's built-in search.

Why do site search migrations go wrong?

Most failed migrations are caused not by a bad engine but by things the old search did that nobody wrote down.

• No baseline, so nobody can say whether the new search is better.
• Testing on exact titles. A test of exact product names passes on any engine and tells you nothing about the misspellings, part numbers and half-phrases your visitors type.
• Lost hand-made fixes. Years of synonyms and pinned products live in the old tool's settings and vanish when the contract ends.
• Broken tracking. Analytics stops recording searches, and a drop in counting looks like a drop in searching.
• No way back. The old search is switched off on launch day, so a problem found on day three is fixed live.

Step 1: How well is your old search working today?

Record four weeks of the current search's numbers first. The new search must beat them, and they decide any rollback.

Measure	What it tells you	Where it usually comes from
Zero-result rate	How often search found nothing	Search provider logs or a custom event
Clicks per search (click-through rate)	Whether results were worth clicking	Search provider, or click events tied to the search
Top 200 searches	What must keep working on day one	Search provider or analytics search-term report
Top zero-result searches	Where the old search was failing	Search provider logs
Response time (typical and slowest)	Speed the new search must match	Server logs or monitoring
Orders or enquiries from search visits	The business number behind it all	Analytics, joined to orders

Count them the same way you will count the new search: completed searches, not keystrokes, and without your own team's test searches (how to measure enterprise search success covers the counting rules). If you are leaving a hosted provider, export this history now; once the account closes, so does your baseline.

Step 2: How do you test the new search before visitors see it?

Build a test set: real searches, each with the result that should come back, so "feels better" becomes a score you can re-run. It has four parts:

1. Your top searches, with the result a visitor should see first. These must not get worse.
2. The old search's failed searches, checked by hand. Where the item exists, the new search should find it.
3. Damaged versions of known items: misspellings, swapped or missing words, abbreviations, plurals. Engines differ most here.
4. A few dozen nonsense queries that should return nothing. If the new engine returns results for these, it will also show visitors confident nonsense.

The method is in a realistic dataset for comparing enterprise search solutions. Score the four parts separately and compare the part your visitors use most, not just the total.

Step 3: How do you run the old and new search side by side?

Index the same catalogue export in both engines, send every test query to each, record both top fives and sort them into three piles:

• Same or better on the new search: no action.
• Worse: review each one. Often the cause is a rule the old search had (step 4) or a field the new index does not search.
• Different, unclear which is better: ask whoever knows the catalogue, usually a merchandiser, to judge.

If you can, also copy live queries to the new search in the background, unseen by visitors. Continue until the "worse" pile is empty or every item left is an accepted trade-off.

Step 4: What has to be carried over from the old search?

List everything the old search did beyond matching words.

What	Why it matters	How to carry it over
Pinned results	Someone decided a product must appear first for a query	Export the list; recreate the pins that still make sense
Hidden results	Discontinued or inappropriate items kept out of results	Export; recreate, and check the items are still in the catalogue at all
Synonyms	"Sofa" also finds "couch"; trade names find generic ones	Export; if the new engine has no direct equivalent, add the affected queries to your test set and check them
Query redirects	A search for "returns" goes straight to the returns page	Recreate in the new search or in the search box code
Search page addresses	Bookmarks, emails and links point at the old results address	Permanent redirect from the old address to the new one, keeping the query

How you export depends on the old tool. Algolia's dashboard exports an index's settings, synonyms or rules as a JSON file, while the records themselves need the command-line tool or an API client (Algolia, "Export and import indices and settings"). In a self-run Elasticsearch, curated results often live in query code, for example a pinned query that promotes chosen documents (Elastic, "Pinned query"), so someone has to read the code to find them.

Don't copy every rule blindly: many were workarounds for the old engine. Re-test each query with and without its rule and keep only those that still earn their place.

Step 5: Will your analytics still count searches?

Two things commonly break; check them before launch:

• The query parameter. Google Analytics 4's enhanced measurement records a site search event, viewsearchresults, by default only when the page address contains one of five query parameters: q, s, search, query or keyword (Google, "Enhanced measurement events"). If the new results page uses a different parameter name, check the site search settings, or searches stop being recorded.
• Custom events. Zero-result and click events written for the old search box may not exist in the new one, or may be renamed, and reports built on them go blank. Fire each event your reports use by hand on the test site.

Step 6: Will changing search affect your Google rankings?

For most sites, no: internal search result pages rarely belong in Google's index. Google lists an empty internal search result page as a typical source of "soft 404" errors, and advises blocking infinite spaces, which a search box can generate, from crawling with robots.txt (Google Search Central, "Troubleshoot crawling errors").

If your result pages are indexed today or linked from other sites, check two things:

1. robots.txt and noindex are not working against each other. robots.txt stops crawling but "is not a mechanism for keeping a web page out of Google" (Google Search Central, "Introduction to robots.txt"). A noindex tag works only if the crawler can reach the page: if robots.txt blocks it, the noindex is never seen (Google Search Central, "Block search indexing with noindex"). So to remove result pages that are already indexed, let Google crawl them with noindex in place; Google notes that a recrawl can take months, and its URL Inspection tool can request one sooner.
2. Old result addresses redirect. If the results page address changes, use a permanent server-side redirect, which Google describes as the best way to send both Google Search and people to the correct page (Google Search Central, "Redirects and Google Search").

Step 7: How do you switch over with a way back?

Switch in stages, with the old search still running behind the new one.

1. Internal only. Staff use the new search on the live site for a few days.
2. A small share of visitors. Send a fixed share, say one visit in ten, to the new search and compare the step 1 measures for the two groups; this is also the cleanest proof of business effect (site search ROI).
3. Everyone, with a fallback. If the new search errors or times out, the old one answers. Count every fallback; a rising count is an early warning.
4. Old search retired, only after the first-month watch period.

Make switching back a configuration change, not a code release. ITMTB's enterprise search case study describes a cutover with this safety net: the old search answered whenever the new service failed or timed out, and switching back was one configuration value. On one live catalogue, the same engine cut zero-result searches roughly tenfold (measured differently before and after; see the case study).

When should you switch back?

Agree rollback rules with numbers before launch, and who decides. An example, not a recommendation:

Signal	Example rollback rule
Zero-result rate	Clearly above the baseline for two days running
Clicks per search	Clearly below the baseline for two days running
Errors, timeouts or fallbacks	Any sustained rise after the first day
Orders from search visits	Below the comparison group by more than normal weekly variation

Set "clearly" from the normal weekly movement in your baseline.

What to watch in the first month

• Daily, first week: zero-result rate, clicks per search, fallbacks, response time.
• Weekly: the new top zero-result searches (catalogue gaps or search problems), and your baseline top 200 re-checked.
• After a month: orders from search visits against the baseline, adjusted for season.
• Every change: re-run the test set first.

Give the weekly zero-result report to one named person, and make the watch period end only when that person signs it off. The live measures, including a fallback counter, are set out in how to measure enterprise search success.

The site search migration checklist

Phase	Step	Owner	How you know it's done
Before	Record four weeks of baseline measures	Analytics	A dated sheet with every measure from step 1
Before	Export analytics history and configuration from the old tool	Engineering	Files saved: top queries, zero-result queries, rules, synonyms
Before	Agree rollback rules and who decides	Head of digital	Written thresholds signed off
Test	Build the test set from real queries	Merchandising with engineering	Expected result recorded for every query
Test	Score both engines on the test set	Engineering	Per-part scores for old and new
Side by side	Review every query that got worse	Merchandising	"Worse" pile empty or accepted in writing
Carry over	Recreate pins, hides, synonyms and query redirects that still matter	Merchandising	Each rule re-tested with and without
Carry over	Redirect old results addresses	Engineering	Old address lands on new results with the query kept
Analytics	Confirm search, zero-result and click events fire	Analytics	Test searches visible in reports with the right terms
SEO	Check robots.txt, noindex and redirects for result pages	SEO	Rules match the intended indexing; no blocked noindex
Cutover	Internal, then share of visitors, then all with fallback	Engineering	Each stage held for its agreed period; fallbacks counted
After	Daily then weekly watch list	Search owner	Watch period ends inside the rollback rules
After	Retire the old search	Engineering	Switched off only after the watch period

Getting help with a migration

ITMTB runs site search migrations end to end: the test set from your catalogue and real searches, your current search scored against our engine, the side-by-side run and the fallback cutover, with the engine deployed and tuned on your own infrastructure if needed (enterprise search). Still deciding whether to replace search? See build vs buy enterprise search.

For a mid-size catalogue, Tomorrow Central Search runs the same engine as a self-serve hosted service and covers several steps above:

• Testing before going live. Upload a catalogue as a CSV, JSON or Google Merchant feed file and search it while signed in; those test searches are not counted in the statistics.
• Carrying over rules. Pin up to three results to the top of a search or hide ones you don't want shown, and compare the results with and without your rules.
• The watch list. Searches, zero-result rate, clicks, click-through rate, response times, and top searches and zero-result searches.

Misspellings are corrected against your own catalogue's words, not a general dictionary. Going live, and importing straight from your website, need proof that you own the website (a DNS record or a small file); uploading a file and testing it do not. There is a free plan (at the time of writing: up to 5,000 products, 10,000 searches a month and one search project); the guide to site search for a catalogue covers setup.

Questions people ask about site search migration

What is a site search migration?

The move from one search engine or provider to another behind your website's search box and results page. Done well, visitors notice better results and nothing else, because the catalogue, rules, analytics and page addresses all carry over.

How long does a site search migration take?

It depends on catalogue size and how customised the old search was. Plan for four weeks of baseline data before the switch and two to four weeks of close watching after it, with the old search available throughout.

What should we export from the old search provider before cancelling?

The catalogue, the configuration (synonyms, pinned and hidden results, redirect rules) and as much analytics history as you can: top queries, zero-result queries and clicks. That history is your baseline and is hard to recover later.

When should we roll back a search migration?

When a threshold agreed before launch is crossed, such as zero-result rate or clicks per search clearly worse than the baseline, or errors and timeouts rising. Agreeing thresholds in advance makes rollback a routine decision, not an argument.

Key takeaways

• A worse search breaks nothing visibly, so measure the old search for four weeks before you change it.
• Test the new engine on your own real and misspelt searches, not on exact product names.
• Export rules, synonyms and analytics history before the old contract ends; re-test each rule rather than copying it blindly.
• Switch in stages with the old search as a fallback, and agree the rollback numbers before launch.

Where to start

Start with step 1: pull four weeks of searches, zero-result searches and clicks from your current search. To try a new engine against that baseline, sign up for Tomorrow Central Search on the free plan and run your test set in the signed-in search before anything goes live. To have ITMTB run the migration, or deploy the engine on your own infrastructure, contact us.

Sources

• Algolia, "Export and import indices and settings", Algolia documentation, accessed 19 October 2026: https://www.algolia.com/doc/guides/sending-and-managing-data/manage-indices-and-apps/manage-indices/how-to/export-import-indices
• Elastic, "Pinned query", Elasticsearch documentation, accessed 19 October 2026: https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-pinned-query
• Google, "Enhanced measurement events", Analytics Help, accessed 19 October 2026: https://support.google.com/analytics/answer/9216061
• Google Search Central, "Troubleshoot Google Search crawling errors", last updated 18 December 2025, accessed 19 October 2026: https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors
• Google Search Central, "Introduction to robots.txt", last updated 10 December 2025, accessed 19 October 2026: https://developers.google.com/search/docs/crawling-indexing/robots/intro
• Google Search Central, "Block search indexing with noindex", last updated 10 December 2025, accessed 19 October 2026: https://developers.google.com/search/docs/crawling-indexing/block-indexing
• Google Search Central, "Redirects and Google Search", last updated 14 April 2026, accessed 19 October 2026: https://developers.google.com/search/docs/crawling-indexing/301-redirects
• ITMTB enterprise search case study: /blog/enterprise-search-case-study-business-research-company