Search is one of the highest-intent areas of an eCommerce website. A customer who types a product name, part number, brand or problem into the search box is not casually browsing. They are telling you what they want.
That makes search a commercial system, not simply a website feature.
The right eCommerce search engine can help customers find suitable products faster, improve conversion rates, increase average order value and expose gaps in your product data. The wrong one can produce attractive demonstrations but struggle with your catalogue, business rules, B2B requirements or traffic volumes once it is live.
Choosing well requires more than comparing screenshots or accepting a vendor’s claim that its search is powered by AI. You need to understand what the engine can search, how it ranks products, how it handles your customers and commercial rules, what it costs at scale, where the data is stored and how its value will be measured.
Start with the search problems you need to solve
Before comparing platforms, document how customers currently search and where the experience fails.
Common problems include:
- Exact searches returning no results because of spelling, spacing or punctuation differences
- Relevant products appearing below accessories, discontinued items or low-value products
- Part numbers failing when customers enter only a partial code
- Search results ignoring synonyms, abbreviations and industry terminology
- Customers knowing the problem they need to solve but not the product name
- B2B buyers being shown products they cannot purchase
- Contract customers seeing the wrong price, availability or product range
- Search working on product titles but not attributes, technical specifications or fitment data
- Merchandisers having no practical way to influence results
- Search analytics showing queries but not whether those searches generated revenue
This initial work matters because a search engine should be selected against your real catalogue and customer behaviour, not a generic feature list.
For a retailer with 5,000 straightforward products, the right solution may be very different from the one required by an automotive supplier with millions of vehicle-product relationships, or a B2B distributor with customer-specific catalogues and pricing.
Not every search engine supports B2B commerce
Many search products were designed around a conventional B2C model: one public catalogue, one price per product and broadly the same results for every shopper. That can work well for retail, but it does not automatically support B2B.
In B2B eCommerce, search may need to respect:
- Customer-specific catalogues and product entitlements
- Contract pricing or customer price books
- Products restricted by company, account, branch, territory or user role
- Different stock availability by warehouse or location
- Minimum order quantities, carton quantities and units of measure
- Customer-specific product codes
- Manufacturer part numbers and internal SKUs
- Reorder lists, previously purchased products and approved substitutes
- Account-level brands, ranges or compliance requirements
- Products that can be viewed publicly but only purchased by authorised accounts
An engine may be technically capable of indexing this data while still being unable to enforce it securely or efficiently. Ask whether B2B rules are applied before results are returned, rather than hiding unsuitable results in the browser after the search has occurred.
That distinction is important. Filtering restricted products only in the front end can expose sensitive product, price or availability information and may create unacceptable performance problems.
You should also test whether relevance can vary by customer. A trade buyer may want an exact SKU match and rapid bulk ordering, while a consumer may respond better to popular products, editorial content and visual merchandising. One universal ranking model rarely serves both audiences equally well.
The features an eCommerce search engine should support
The right feature set depends on your business, but the following capabilities provide a strong evaluation framework.
Relevance and query understanding
At a minimum, search should support:
- Typo tolerance
- Synonyms and industry terminology
- Plurals, stemming and word variations
- Partial SKU and part-number matching
- Phrase matching
- Abbreviations and alternate spellings
- Numeric searches, dimensions and model numbers
- Attribute-level searching
- Natural-language queries
- Zero-result query management
Do not simply confirm that a feature exists. Test how much control it provides. A platform may support synonyms but impose a low limit, require every synonym to be maintained manually or treat two-way synonyms in a way that damages relevance.
For example, a shopper searching for “work boots” may reasonably see products described as “safety boots”. However, automatically treating every related term as interchangeable can create irrelevant results. Good search implementations use synonyms deliberately and validate their commercial impact.
Ranking and relevance controls
The search engine should allow you to control the factors that determine result order. These may include:
- Text relevance
- Product popularity
- Sales revenue
- Conversion rate
- Stock availability
- Margin
- Product recency
- Rating or review volume
- Promotional status
- Customer-specific purchase history
- Location or fulfilment availability
One of the most important questions is whether the engine can use sales and conversion data in ranking. Some platforms only rank according to textual relevance and manually configured boosts. Others can use behavioural data but offer limited visibility into how it changes results.
Sales weighting should also be applied carefully. If historical sales dominate the algorithm, bestsellers can remain permanently at the top while new or strategically important products receive little exposure. Strong implementations combine relevance, commercial signals, availability and explicit merchandising rules rather than relying on one measure.
Merchandising tools
Merchandising teams should be able to manage search without lodging a development request for every change. Useful controls include:
- Pinning and burying products
- Boosting or suppressing categories, brands and attributes
- Scheduling campaigns
- Creating rules for particular queries
- Adding promotional banners or content to results
- Managing redirects
- Excluding discontinued or unsuitable products
- Previewing changes before publication
- Applying rules by market, store, customer type or device
- Keeping an audit history of changes
The balance matters. Merchandisers need practical control, but hundreds of manual rules can become difficult to maintain and may conflict with algorithmic relevance.
Facets and filters
Search and product filtering are closely connected. Confirm that the engine supports:
- Dynamic facets based on the result set
- Multi-select filters
- Numeric and price ranges
- Category-specific filters
- Attribute ordering and display rules
- Customer-specific filters
- Stock and location filters
- SEO requirements for filtered landing pages
- High-cardinality attributes without serious performance loss
Also check whether filter counts remain accurate after B2B permissions, stock rules and customer catalogues have been applied.
Autocomplete and search suggestions
Autocomplete should do more than predict keywords. A mature implementation may display:
- Products with images and prices
- Categories and brands
- Recent or popular searches
- Content and buying guides
- Customer part numbers
- Suggested corrected queries
- Direct links to relevant landing pages
The experience should be fast on mobile, keyboard accessible and easy to operate without accidentally closing or obscuring the results.
Predictive search and on-page search results are not the same thing
Predictive search, sometimes called autocomplete or search-as-you-type, is the panel that appears while a customer is entering a query. The full search results page is what the customer sees after submitting that query. They are related, but they are often powered, configured and measured differently.
Predictive search is designed for speed and direction. It may show a small selection of suggested products, categories, brands, queries and content. Because it updates after each keystroke, it needs very low response times and careful limits on the number of requests generated. Its purpose is to help the customer reach a useful destination with minimal effort.
The full results page needs to support deeper product discovery. It commonly includes:
- A larger and more complete result set
- Facets and filters
- Sorting options
- Pagination or infinite scrolling
- Merchandising banners and content
- Alternative suggestions for weak or zero-result queries
- Customer-specific prices, stock and product permissions
- More detailed analytics and merchandising controls
Do not assume that strong predictive results guarantee a strong results page, or vice versa. Some solutions use a native platform feature for autocomplete and a different engine for submitted searches. This can produce inconsistent product rankings, different synonym behaviour and confusing transitions when a customer presses Enter.
During evaluation, ask whether both experiences use the same index, relevance logic, merchandising rules and B2B permissions. Test whether the product shown first in predictive search remains easy to find on the results page. Also confirm whether predictive requests and submitted searches are priced differently, as search-as-you-type can create several billable API operations from a single customer query.
Measure the two experiences separately. Useful predictive-search metrics include suggestion click-through rate, time to selection and the percentage of users who submit the full query. Results-page metrics should include filter engagement, product clicks, add-to-cart rate, conversion and revenue per search session.
Out-of-the-box search versus paid AI search solutions
Most modern eCommerce platforms include a native search capability. For smaller catalogues and straightforward retail requirements, the out-of-the-box engine may be entirely suitable. It is already connected to the product catalogue, usually has a lower operating cost and avoids another vendor, data store and integration layer.
Native search is a sensible starting point when:
- Product names and attributes are clear and consistent
- The catalogue is relatively simple
- Customers tend to search using predictable terms
- There are few customer-specific catalogue or pricing rules
- Basic synonym, filtering and merchandising controls are sufficient
- Search does not currently represent a major source of lost revenue
However, native search can become limiting when the catalogue is large, terminology is complex, B2B rules are extensive or the business needs greater control over relevance and experimentation.
Paid search platforms increasingly describe themselves as AI-powered. Depending on the product, this may include natural-language processing, semantic or vector search, automated synonym discovery, behavioural ranking, intent recognition, personalisation and generative answers.
These capabilities can be valuable, but the AI label does not prove that the product will outperform a well-configured conventional engine. A paid solution should demonstrate a measurable improvement using your own catalogue and real customer queries.
When comparing native and paid AI search, assess:
- Relevance improvement on a controlled set of real queries
- Support for exact SKUs, part numbers and technical attributes
- B2B catalogue and permission enforcement
- Explainability of rankings and the ability to override them
- Dependence on behavioural data before the model becomes useful
- The quality of results for new, low-volume and long-tail queries
- Additional latency introduced by semantic or generative processing
- Hallucination or unsupported-answer risk where generative responses are used
- Data storage, model training and privacy conditions
- Subscription, usage, implementation and optimisation costs
- The ability to revert or migrate if performance does not justify the investment
AI search may deliver its greatest value where conventional keyword matching genuinely struggles, such as customers describing a problem instead of naming a product. It is less compelling when buyers primarily enter exact SKUs and expect rapid, deterministic results.
A hybrid approach is often appropriate. Exact identifiers and strong keyword matches can be given priority, while semantic matching expands discovery for less precise queries. This protects high-intent searches from being displaced by results that are conceptually related but commercially wrong.
Voice search
Voice search can be useful where customers are mobile, working in warehouses, wearing gloves, or searching with complex product descriptions. It can reduce typing friction and improve accessibility.
However, voice input alone is not a search strategy. The engine still needs to interpret the transcribed query correctly. Product names, acronyms, model numbers and industry terminology are often difficult for general speech recognition systems.
When assessing voice search, test:
- Industry-specific terminology
- Brand and product names
- SKUs and model numbers
- Australian accents and regional language
- Noisy environments
- Permission and privacy behaviour on mobile devices
- Whether the spoken query can be reviewed and corrected
Voice search should be treated as an input method connected to a strong search engine, not as a substitute for relevance and product data quality.
Personalisation and recommendations
Some search engines can adjust results using behaviour, location, customer segment or purchase history. This can improve discovery, but it needs sensible controls.
Ask whether personalisation is transparent, whether merchandisers can override it and whether a user can become trapped in a narrow set of results based on previous behaviour. For B2B, account-level relevance may be more valuable than individual browsing behaviour.
Analytics and experimentation
Useful search analytics should show more than the most popular terms. Look for:
- Search volume
- Zero-result and low-result searches
- Search exit rate
- Click-through rate from search results
- Add-to-cart rate after search
- Search conversion rate
- Revenue generated after search
- Average order value for search users
- Queries that are frequently reformulated
- Filter usage
- Performance by device, market and customer segment
- Results before and after a rule or algorithm change
A/B testing or controlled experimentation is particularly valuable. Without it, a relevance change may feel better in a demonstration while reducing commercial performance in production.
Product data determines how good search can become
Even a sophisticated engine cannot reliably compensate for incomplete, inconsistent or poorly structured product data.
If colour, size, compatibility, material, application, brand and technical attributes are buried in descriptions rather than held in structured fields, the engine has less reliable information to search and rank.
Before implementation, assess:
- Which product fields are complete and trustworthy
- Whether attributes use consistent terminology
- Whether products have suitable categories and relationships
- Whether parent and variant data should be searched differently
- Which system owns each field
- How quickly ERP, PIM, inventory and pricing changes reach the index
- How discontinued, restricted and out-of-stock products are handled
Search projects often reveal broader product data issues. Resolving those issues can improve filters, SEO, recommendations, advertising feeds and marketplace performance as well as on-site search.
Common limitations hidden behind the feature list
Two vendors may both mark a capability as supported while delivering very different levels of usefulness. During procurement, investigate the limits attached to each feature.
Synonym limits
Check the number of synonym groups permitted, whether synonyms can be one-way or contextual, how they are imported and whether they vary by language, market or customer group.
Ranking limitations
Determine which fields can influence ranking, how many ranking rules are permitted and whether sales, margin, stock and conversion data can be supplied from external systems. Ask how frequently those signals are refreshed.
Catalogue and record limits
Pricing and performance may change materially based on product count, variant count, searchable records or index size. Some engines count each variant, customer-price record or language version separately. A catalogue described internally as 100,000 products can therefore become several million billable records.
API and query limits
Understand monthly search allowances, indexing limits, rate limits, concurrency restrictions and charges for exceeding the plan. Include autocomplete, filtering, merchandising previews, bots and internal users in your estimate because they may all generate billable activity.
B2B security and filtering limits
Ask how many customer groups, catalogues, price lists and permission combinations the platform can support. Confirm whether access rules are enforced in the search service and whether secure tokens or server-side queries are required.
Data freshness
Find out whether updates happen in real time, on a schedule or through a full reindex. A delay that is acceptable for product descriptions may be unacceptable for stock, price or account permissions.
Reporting limitations
Confirm how long analytics are retained, whether raw data can be exported and whether reporting can be connected to your analytics platform or data warehouse. Vendor dashboards can be useful, but you should not become dependent on reports you cannot independently validate.
Front-end and platform constraints
Some solutions work best only with a particular eCommerce platform, theme architecture or front-end framework. Check support for your current platform, headless storefront, mobile app, multiple websites, markets, currencies and languages.
Understand the upgrade obligation for Elasticsearch and OpenSearch solutions
Some eCommerce platforms and custom search implementations use Elasticsearch or OpenSearch as part of their architecture. These technologies can provide powerful search capabilities, but they are not install-once infrastructure.
Supported versions change over time. The search cluster, hosting environment, eCommerce platform, extensions, index mappings, client libraries and custom integrations need to remain compatible. Security patches and end-of-support dates can also create a requirement to upgrade even when the existing search experience appears to be working.
An upgrade may involve more than changing a version number. Depending on the age and complexity of the implementation, it can require:
- Reviewing breaking changes and deprecated features
- Updating application clients, modules and connectors
- Reworking index mappings, analysers or custom plug-ins
- Reindexing the entire catalogue
- Testing synonyms, stemming, facets and ranking behaviour
- Validating B2B permissions and customer-specific filtering
- Comparing relevance before and after the upgrade
- Planning cluster capacity, backups, rollback and cutover
- Revalidating monitoring, security and disaster recovery
Custom relevance logic can make upgrades more difficult. An analyser, plug-in or query written for an older version may behave differently or no longer be supported. Even where the eCommerce platform officially supports a new search version, third-party extensions and custom integrations may not be ready at the same time.
Ask who is responsible for monitoring version support, planning upgrades and testing relevance. Confirm whether these activities are included in hosting or support fees, and how frequently upgrades have historically been required.
A fully managed search service can reduce infrastructure work, but it does not eliminate application compatibility, data modelling or regression testing. A SaaS search platform may hide more of the underlying upgrade process, although the vendor can still change APIs, ranking behaviour, limits or commercial terms.
Include ongoing upgrade effort in the total cost of ownership. A self-managed Elasticsearch or OpenSearch solution may avoid some SaaS fees, but operational responsibility, specialist skills and periodic upgrade projects have a real cost.
Where is your search data stored?
Search systems commonly receive a substantial copy of your product catalogue and may also process queries, customer identifiers, pricing, inventory and behavioural data.
You should understand:
- The countries or regions where data is stored and processed
- Whether an Australian data region is available or required
- Which subprocessors can access the data
- Whether query logs contain personal or commercially sensitive information
- How data is encrypted in transit and at rest
- How long logs, backups and analytics are retained
- Whether customer data is used to train shared models
- How deletion and data export requests are handled
- What happens to your data when the contract ends
- Whether separate indexes and access controls exist for different brands or markets
Data location can also affect search speed. An overseas region may still perform well with appropriate architecture, but latency should be tested from the markets in which your customers actually shop.
For B2B organisations, customer-specific prices, product entitlements and query history may be commercially sensitive. Involve security, legal and privacy stakeholders early rather than treating data hosting as a final procurement checkbox.
How eCommerce search pricing models work
Search pricing can look inexpensive during a proof of concept and become significant at production scale. Common pricing inputs include:
- Number of searches or API operations
- Number of indexed records
- Catalogue or variant count
- Monthly sessions or users
- Revenue or gross merchandise value
- Number of websites, markets or languages
- Feature tiers
- Analytics retention
- Support level and service commitments
- Implementation and ongoing optimisation services
The definition of a “search” or “record” matters. One customer action can generate several requests as autocomplete updates with each keystroke. A single product can become multiple records when variants, locations, languages or customer-specific values are indexed.
Build a three-year cost model using realistic growth assumptions. Include:
- Software subscription and usage charges
- Initial discovery and implementation
- Product data remediation
- Front-end design and development
- Analytics and conversion tracking
- Ongoing relevance tuning and merchandising
- Internal ownership and training
- Charges for additional markets, traffic or records
- Migration or exit costs
Do not compare subscription prices alone. A lower-cost engine that requires constant developer intervention or produces weaker conversion can be more expensive overall.
How to measure the ROI of better search
The business case should connect search performance to revenue, margin, customer experience and operational efficiency.
Start by establishing a baseline for:
- Percentage of visitors who use search
- Conversion rate of search users
- Conversion rate of non-search users
- Revenue per search session
- Average order value after search
- Search exit rate
- Zero-result rate
- Time to find a product
- Customer-service enquiries caused by product discovery problems
A simple incremental revenue model is:
Incremental revenue = search sessions × improvement in search conversion rate × average order value
For example, if a site receives 100,000 search sessions per month, has a 4% search conversion rate and a $180 average order value, search contributes approximately $720,000 in monthly revenue. Improving the conversion rate from 4% to 4.4% would generate around 400 additional orders, or $72,000 in incremental monthly revenue before considering margin and implementation cost.
This is a useful forecast, but actual ROI should be validated through analytics and controlled testing. Account for seasonality, marketing mix, stock changes and other website releases that may affect conversion.
For B2B, the return may also include:
- More orders placed through self-service rather than by phone or email
- Reduced order-entry costs
- Faster repeat ordering
- Fewer incorrect product selections
- Greater adoption of the online portal
- Improved cross-sell and substitute-product uptake
- Reduced workload for sales and customer-service teams
Measure gross profit where possible, not revenue alone. A ranking model that increases revenue by disproportionately promoting low-margin products may not deliver the commercial improvement it appears to.
Run a proof of concept using your own data
A polished vendor demonstration is not enough. Shortlist suitable platforms and test them against a representative extract of your catalogue and real search behaviour.
Your test set should include:
- High-volume searches
- Long-tail queries
- Misspellings
- Partial product codes
- Industry abbreviations
- Natural-language searches
- Queries with no current results
- Ambiguous terms
- Products with similar names
- B2B customer restrictions
- Customer-specific pricing or codes
- Out-of-stock and discontinued products
Score result quality consistently. For each query, record whether the expected product appears, where it ranks and whether any unsuitable results are exposed.
Also test performance, indexing speed, administration workflows, analytics and integration complexity. The strongest search results are of limited value if stock updates take hours, account permissions are difficult to enforce or merchandising rules cannot be maintained by the business.
Questions to ask every search vendor
Use the following questions during evaluation:
- Does the platform genuinely support B2B catalogues, permissions and customer-specific results?
- Can security rules be enforced before results are returned?
- Which fields and behavioural signals can influence ranking?
- Can sales, margin, inventory and conversion data be incorporated?
- What limits apply to synonyms, rules, records, queries and indexes?
- How are variants, languages, locations and customer price records counted?
- How quickly can product, price, stock and permission data be updated?
- Can merchandisers manage and schedule rules without development?
- Does the platform support voice input, and what component performs speech recognition?
- Which analytics are included, and can raw events be exported?
- Where is data stored, processed and backed up?
- Is customer or query data used to train any shared AI model?
- What will the platform cost at our expected scale over three years?
- What happens if traffic or record volumes exceed the contracted allowance?
- How do we export our configuration and data if we leave?
- What implementation, optimisation and support capabilities exist in Australia?
- Do predictive search and the full results page use the same index, rules and permissions?
- What measurable improvement does the paid or AI product provide over our platform’s native search?
- Who owns Elasticsearch or OpenSearch upgrades, compatibility testing and reindexing?
Choosing the right implementation partner
Search touches more systems than the visible search box suggests. A successful implementation may require eCommerce platform development, ERP or PIM integration, catalogue modelling, analytics, UX design, privacy review and ongoing conversion optimisation.
Choose a partner that can evaluate the complete architecture and commercial objective, not simply install an extension. They should be able to explain:
- Which data belongs in the search index
- How B2B permissions will be enforced
- How rankings will be tested and improved
- How search will interact with categories and filters
- How performance will be measured
- How the solution will scale with catalogue and traffic growth
- Who will own optimisation after launch
The implementation should begin with discovery, real query data and measurable success criteria. Technology selection comes after the requirements are understood.
The best search engine is the one that fits your commerce model
There is no universally best eCommerce search engine. A strong choice is one that understands your catalogue, respects your commercial and security rules, gives the business appropriate control and produces a measurable improvement in customer outcomes.
For some retailers, that may mean a focused native search solution with modest costs and simple administration. For a large B2B distributor, multi-brand retailer or complex omnichannel business, it may require a dedicated platform with advanced relevance, secure filtering, behavioural data and extensive integration capability.
The decision should ultimately answer five questions:
- Can customers find the right product quickly?
- Can the engine support the way our business actually sells?
- Can our team understand and control the results?
- Can we prove the commercial return?
- Can we trust how the platform handles our data?
If those questions are answered properly, search can become one of the most valuable conversion investments on an eCommerce roadmap.
Talk to an eCommerce search specialist
OSE helps Australian retailers, wholesalers and distributors assess, design and implement search experiences across Shopify, Adobe Commerce and integrated B2B environments.
We can help you define the requirements, assess product data, compare suitable technologies, model the likely return and implement a search experience around the way your customers actually buy.