On-Site Search for Your DTC Site: Configuring SearchWP and Elasticsearch to Lift Conversion

Choosing Your Search Stack: WP Default vs. SearchWP vs. Elasticsearch by Scale and Cost

On-Site Search for Your DTC Site: Configuring SearchWP and Elasticsearch to Lift Conversion

Bottom line first: On-site search isn’t just “install a search box and you’re done” — it’s a seriously underrated conversion entry point. After two weeks of tracking with Google Analytics 4, if search usage is below 2% and the zero-results rate is above 20%, the problem usually isn’t the search engine — it’s your content structure and product categories. Only when search usage tops 5% and the zero-results rate is still above 15% is it worth upgrading from WP default to SearchWP or Elasticsearch. Pick your tier by scale: under 200 pages, stick with WP default; 200 to 5,000 pages, move to SearchWP (about $199/year); over 5,000 pages or more than 1,000 SKUs, go with Elasticsearch.

1. Why DTC Teams Systematically Ignore On-Site Search

Most B2B DTC sites treat the search box as decoration — tucked in the top right corner, never configured, never monitored. But B2B buyers behave differently from B2C shoppers: they aren’t browsing aimlessly, they arrive with exact specs in mind — “304 stainless flange,” “1000W inverter,” “IP65 enclosure 200×150.” Category navigation can’t surface results for needs that precise. Only the search box can.

Here’s the counterintuitive part:Sites with low search usage don’t lack a need for search — their search is so bad nobody dares use it. A visitor types a query once, gets zero results or a pile of irrelevant pages, and closes the tab for good. So “nobody uses search” is itself a red flag, not evidence against optimizing it. For tracking setup, see GA4 Setup and Events for the method.

Common Misconception	What the Data Actually Says	Correct action
Nobody uses search, so why bother	High zero-results rate = search is broken	Track for two weeks before deciding
A search box in the top right is enough	The search entry is hard to find on mobile	Pin a search bar to the top on mobile
The search results page doesn’t matter	Conversion after search is 2–3x higher than after browsing	Add filters and sorting to the results page
WP default search is good enough	WP default only searches titles and body text	Product attributes need their own index
Just switch to Elasticsearch and you’re set	A poorly designed index is still bad	Tune the weighting before swapping engines

2. The Decision: How to Choose Among the Three Search Tiers

The most common mistake DTC teams make is jumping straight to “Elasticsearch or Algolia?” — that puts tool selection ahead of problem diagnosis. The right order: spend two weeks tracking search usage, zero-results rate, and first-click rate, then decide which tier you need.

The threshold is straightforward: if search usage is below 2%, improve your navigation and content first, don’t upgrade your engine. Between 2% and 5%, installing SearchWP for synonyms and weight tuning is enough. Only when usage exceeds 5% and you have more than 500 product SKUs should you consider Elasticsearch or a SaaS search service. For overall search design across your product catalog, see the search experience for product catalogs.

Tier	Best for	Response Time	Annual cost	Maintenance cost
WP default WP_Query	<200 pages, blog only	1-3 seconds	$0	Almost zero
SearchWP plugin	200-5000 pages with products	200-400 milliseconds	About $199	Annual renewal + index rebuild
Self-hosted Elasticsearch	>5000 pages, SKU>1000	80-150 milliseconds	Self-hosted server $30-80/month	Requires ops capability
Algolia/Meilisearch cloud	Team has no ops resources	50-120 milliseconds	$99-399 per month	Billed by document count
WooCommerce Product Search	Small ecommerce-only site	300-600 milliseconds	About $99/year	Deep integration with Woo

3. How to configure SearchWP: weights, synonyms, and zero-result pages

SearchWP is the most cost-effective search upgrade in the WordPress ecosystem. Its core value isn’t “faster” — it’s “configurable relevance.” Default WP search sorts by post_date descending, while SearchWP lets you assign weights to titles, body text, tags, custom fields, categories, and short descriptions separately. This matters especially for product sites — buyers search for model numbers, not article titles.

A concrete configuration example: for a product site, set the “product model” field weight to 10, “short description” to 5, “body” to 2, and “tags” to 3. That way, when a buyer types “WF-200,” it hits the model field directly instead of surfacing a blog paragraph that mentions WF-200. Configure at least 50 synonym groups, covering industry abbreviations, spelling variants, and US/UK spelling differences (like “aluminum” vs “aluminium”). For how to set up your WP tech stack, see WordPress tech stack.

Setting	Recommended for product sites	Recommended for content sites	Tuning signal
Title weight	8	10	Increase when first-click CTR <30%
Body weight	2	5	Decrease when zero-result rate is high
Custom field weight	10 (model/specs)	1 (barely used)	Increase when model searches perform poorly
Tag weight	3	4	Add when synonym coverage is incomplete
Category weight	5	2	Decrease when results are too broad
Minimum word length	2 characters	3 characters	Lower to 2 when short model numbers can’t be found
Fuzzy match	Enable (edit distance 1)	Close	Enable for markets with many typos

4. When you actually need Elasticsearch, and how to configure it

Elasticsearch isn’t a synonym for “advanced search” — it’s designed for large-scale full-text search and complex aggregations. A standalone site should only adopt it if it meets one of these two conditions: first, more than 1000 product SKUs and a need for real-time faceted filtering (filtering simultaneously by price range, material, and certification); second, more than 5000 total pages and search response times already exceeding 500 milliseconds. If you don’t meet these two conditions, adopting Elasticsearch is using a cannon to shoot mosquitoes.

The biggest configuration pitfall is Chinese and multilingual tokenization. The standard analyzer works fine for English, but for Chinese you must install the IK tokenizer and configure a custom dictionary (add your product model numbers and industry abbreviations), otherwise “304 stainless steel flange” gets split into single characters and recall is completely scrambled. Multilingual sites also need a separate index per language, mapped with hreflang. For that part, see Hreflang for multilingual sites. For how to configure CDN and caching, see CDN global acceleration.

Scenario	Recommended Plan	Key configuration	Expected result
500-page blog site	SearchWP free version	Title weight 10, body 5	Zero-result rate cut from 25% to 8%
3,000-page product site	SearchWP Pro	Model field weight 10 + synonym list	Post-search conversion rate +15%
2,000-SKU ecommerce site	Local Elasticsearch + WP plugin	IK tokenizer + faceted aggregation	Response <150ms
Multilingual B2B site	Elasticsearch multi-index	Index per language + synonyms	Zero-result rate <10% per language
Team has no ops staff	Algolia/Meilisearch cloud	Use the official WordPress plugin	No ops, pay by document volume

5. Zero-result rate matters more than ranking

Many teams fixate on “where do my search results rank,” but the real killer metric for B2B search is the zero-result rate. When a search term returns nothing, visitors don’t page through results, they close the browser. Industry benchmarks: a zero-result rate above 20% means your search terms and content structure are misaligned, and above 35% means search is essentially broken.

Fixing a high zero-result rate comes in two steps. First, export your zero-result queries into a table, sort by frequency, and handle the top 20 high-frequency zero-result terms. Second, for each term decide whether “the content for this term doesn’t exist” or “the content exists but can’t be found.” The former means adding content; the latter means adjusting index weights or adding synonyms. For how to mine on-site search queries into content gaps, see mining on-site search terms. Search results pages also affect LCP in Core Web Vitals, see Core Web Vitals Optimization.

Metrics	Healthy range	Alert threshold	Action
Search usage rate (share of sessions with search)	5% to 15%	Below 2% for 4 straight weeks	Improve navigation and search entry visibility
Zero-result rate	Under 10%	Above 20%	Export high-frequency zero-result terms, add content or adjust weights
First-click click-through rate	Above 40%	Below 25%	Result ranking relevance is off, adjust weights
Post-search conversion rate	2 to 3 times higher than regular browsing	On par with browsing	Results page lacks filters and CTAs
Search response time	Under 300 milliseconds	Over 800 milliseconds	Add caching or upgrade the engine

FAQ

Does your own site really need Elasticsearch?

Not necessarily. It’s only worth it if you meet one of two conditions: more than 1,000 SKUs with a need for real-time faceted filtering, or more than 5,000 pages with search response times already over 500 milliseconds. Otherwise SearchWP (about $199/year) is enough. The vast majority of B2B standalone sites have under 500 SKUs, so Elasticsearch is over-engineering, costing $300 to $1,000 a year in servers and ops for a UX improvement you won’t even notice.

How do you decide whether on-site search needs optimizing?

Start by tracking events in GA4 or SearchWP for two weeks and watch three numbers: search usage rate, zero-result rate, and first-click rate. If search usage is below 2%, navigation matters more than search, so leave search alone for now. If usage is 2% to 5% and the zero-result rate is above 15%, install SearchWP and tune the weights. If usage is above 5% and the zero-result rate is still above 20%, then consider upgrading your search engine.

How is SearchWP different from WordPress default search?

WordPress default search only uses WP_Query, sorts by post_date descending, and searches only titles and body content. It does not support custom fields, synonyms, or fuzzy matching. SearchWP lets you set separate weights for titles, body content, custom fields, and tags, supports synonym lists and fuzzy matching, and stores its index in its own tables for faster queries. For product sites, the biggest win is being able to set the model number field weight to 10, so buyers who search a model number land on the right product.

Why does Chinese search perform so poorly in Elasticsearch?

The default standard analyzer splits Chinese into single characters, so “304 stainless steel flange” gets chopped into individual characters and recall is completely scrambled. You have to install the IK tokenizer and add your product model numbers, industry abbreviations, and brand terms to a custom dictionary. Choosing the wrong tokenizer hurts more than choosing the wrong search engine, because results look like they “have content” while relevance is completely off.

The zero-result rate is high. What should I do, and how do I handle it at scale?

Export every zero-result query from the past two weeks, sort by frequency, and go through the top 20 high-frequency terms one by one: if the content does not exist, add a landing page or product page; if the content exists but cannot be found, adjust index weights or add synonyms. This usually clears up 70% of zero-result queries. You do not need to handle the remaining long-tail zero-result terms one by one. Put a “Not found? Submit an inquiry” form on the zero-result page as a fallback.

How do I choose between Algolia and self-hosted Elasticsearch?

If your team has no dedicated ops person, choose Algolia. It costs $99 to $399 per month based on document volume, and the WordPress plugin takes 5 minutes to set up. For sites with under 10,000 daily UV, Algolia usually costs $100 to $200 per month, far less than self-hosting plus the cost of an ops hire. Only when daily UV exceeds 50,000, or you need deeply customized search logic, should you consider self-hosted Elasticsearch. Server costs are $30 to $80 per month, but someone has to maintain it long term.

Final thoughts

On-site search is the most underrated module on an independent site in terms of return on investment. It does not require a big overhaul. Start with two weeks of event tracking, then use the zero-result rate and search usage rate to decide which level to upgrade to. Most sites are fine staying at the SearchWP level. Elasticsearch is not mandatory; it is the natural choice once you reach scale, not the starting point for search experience.

Three steps to get this live: first, add GA4 event tracking to your search box this week and log the query, the click, and the result count. Second, two weeks later, export the zero-result queries and fix the top 20 by volume. Third, let your search usage rate decide whether you need SearchWP. If you install it, tune the weighting once, then run it for a month and see whether the first-click rate climbs from 25% to 40% or higher.

One line worth remembering: low search usage doesn’t mean people don’t need search. It means search is so bad nobody dares use it. Instrument and diagnose first, then talk about which engine to buy.