When a separate search service makes sense
Consider a separate search service when shoppers use product codes, synonyms or misspellings and your current results miss relevant products. Another use case is a mixed collection: products, categories and articles need a shared search interface. Start with observed queries and support feedback. Slow responses and poor ranking are different problems and may need different fixes.
If few visitors use search, first make the search box discoverable and collect a baseline. Missing product attributes cannot be recovered by swapping search software. Define the problem the pilot needs to solve: exact SKU lookup, a synonym mismatch, stale availability or mobile navigation. Installing a widget alone is not an acceptance criterion.
Record a useful baseline
Choose a reporting window without major promotions or assortment changes. Export anonymised queries, search sessions, empty results and visits to result pages. Record device, language, filters, product availability and response time. Remove emails, telephone numbers and personal information that visitors may have typed into the search box before sharing the export.
The zero-result rate is executed searches returning no results divided by all executed searches. Search click-through rate is search sessions with a result click divided by all search sessions. Use one attribution window for purchase reporting. A higher purchase rate among search users does not establish that search caused it: those shoppers may already have stronger buying intent.
Build a repeatable query set
Include an exact SKU, partial product code, model name, misspelling, synonym, category, combination of two attributes and a query with no matching product. For every row, list expected product IDs, acceptable alternatives and the reason you expect them. Include similar products with different sizes or compatibility requirements, where returning the wrong variant is costly.
Keep some queries for tuning and a separate set for acceptance. Otherwise a pilot may pass familiar examples without generalising to new queries. The CSV below provides blank fields and test categories. It is a worksheet, not customer performance data. Keep the original query and filter settings so another reviewer can reproduce the result.
Check catalog data and updates
The pilot needs stable IDs, titles, URLs, availability and the fields shoppers search by. For commerce, also check prices, currency, images and variant rules. Agree on the source format, catalog size, update schedule and deletion behaviour. Compare sample feed records with public product pages: a search result must not link to a missing URL.
Test the complete update path using a controlled catalog item. Change availability in the source, wait for the agreed update interval and check the result. Repeat for a price change and deletion. The Site Search integration page describes connection options. Confirm a custom CMS, authentication requirements and any unsupported source before choosing a subscription.
Agree on acceptance before tuning
Write down which critical queries must return a particular SKU, where that SKU should appear and the maximum acceptable response time for your use case. Set thresholds from your baseline and buyer needs. Do not substitute a universal conversion promise. Evaluate matching, filtering, result clicks and price display as separate checks with a named owner.
For every failure, record the query, index update time, expected result and actual order. Test the mobile experience: keyboard visibility, opening and closing search, empty results, long titles and keyboard navigation. A critical product code pointing to the wrong item is more important than a small ranking difference among secondary results.
Measure impact without false precision
Where feasible, use a parallel experiment with the same assortment and randomly allocated visitors. If you can only compare before and after, document promotions, price changes, advertising and stock availability. Show session counts alongside percentages. A small sample may support a technical decision without supporting a conclusion about revenue.
Separate integration reliability, relevance on the control set and commercial impact. The first two can be accepted with repeatable checks. The third needs observation after launch. Empty results, clicks and add-to-cart events are useful intermediate signals, but connect the business decision to orders, support costs and subscription expenses.
Compare the complete scope and cost
Site Search currently publishes RUB plans of 990, 1,990 and 4,990 per month, or 9,900, 19,900 and 49,900 for twelve months. Check the pricing page for current limits and terms. These are published RUB prices, not a US dollar or UK pound offer. Confirm payment arrangements for your market before purchasing.
Subscription and implementation are separate costs. Ask whether feed preparation, interface installation, ranking configuration, analytics, acceptance testing and ongoing support are included. Validate integration feasibility first for a custom stack. A lower subscription alone does not make an offer cheaper when implementation or maintenance sits outside its scope.
Prepare a focused scope request
Share the store URL, CMS, approximate object count, anonymised feed sample, update schedule and control queries. Describe the current search problem and identify the owner of catalog data. Do not send production credentials in an initial enquiry. This is enough to start evaluating feasibility and the work needed for a useful pilot.
Request included deliverables, exclusions, acceptance criteria, named owners and a way to return to the previous search interface. Delay a general rollout if the index cannot stay current or critical queries fail. If the pilot passes, start with a limited audience and monitor failures, data freshness and search sessions before expanding.
A working template for your pilot
Open the CSV in Excel or Google Sheets. It is a blank template: fill it with your own catalog data. Do not include personal data.
Download the search query template (CSV)The next step is to check feasibility with your data and agree on the scope.