If your WordPress site has more than a few hundred posts and you have ever watched a visitor type a query into your search box and then immediately leave, you have met the problem. WordPress core search is not a search engine. It is a LIKE query bolted onto a content database, and the gap between what it does and what people expect a search box to do is the single most common reason readers bail out of a content site.

What WordPress core search actually does under the hood

When a visitor submits a query, WP_Query builds a SQL statement against the wp_posts table. For a query like caching plugin, the generated WHERE clause is roughly a set of post_title LIKE '%caching%' and post_content LIKE '%plugin%' conditions, OR'd together, then ordered by post_date DESC. That one sentence explains almost every complaint people have about it.

It matches substrings, not words. A search for cat happily matches "communication," "category," and "duplicate." There is no tokenization, so the engine has no concept of a word boundary.
It has no stemming. Running will not find "run," caches will not find "cache." Each grammatical form is a different string to a LIKE comparison.
It cannot rank. A post that mentions your phrase once in a 2009 footer gets the same relevance as a post titled exactly your query. Worse, because the only sort is post_date DESC, the most relevant result is frequently buried under newer, weakly-matching posts.
The leading wildcard kills the index. A LIKE '%term%' with a wildcard on the left cannot use a B-tree index, so MySQL performs a full table scan of post_content on every search. On a large site this is slow and relevance-blind at the same time.
It ignores typos and synonyms entirely. One transposed letter returns zero results, and "USA" never matches "United States."

None of this is a bug. It is a 2003-era implementation that core has kept for backward compatibility because changing the default would break thousands of themes and plugins that depend on its exact behavior. Below roughly 100 posts it is genuinely fine — the result set is small and order barely matters. Above that, it actively works against you.

The two real paths to better search

Every meaningful upgrade falls into one of two architectures, and choosing the wrong one is the most expensive mistake people make here.

Path one: a better index on the same database

Plugins like Relevanssi and SearchWP leave search running on your existing MySQL/MariaDB database but replace the naive LIKE with a proper inverted index. They crawl your content into their own tables (Relevanssi builds wp_relevanssi), tokenize it into individual terms, and store which terms appear in which posts and how often. At query time they look terms up in that index and compute a relevance score instead of scanning raw content.

This buys you the things core lacks: weighting (title matches count more than body matches), stemming, configurable stopwords, custom-field and taxonomy indexing, and relevance-ordered results. Relevanssi's free tier covers the core of this; its Premium tier adds did-you-mean suggestions and multisite support. SearchWP is commercial-only and shines when you need to search WooCommerce products, custom fields, PDF/document content, or to define multiple weighted "engines" for different parts of the site.

The catch is scale. Because the index lives in your application database, very large catalogs (tens of thousands of posts, or heavy WooCommerce stores) put the indexing and query load on the same server that renders your pages. It works well into the low thousands of posts; past that you start fighting database contention.

Path two: offload to a purpose-built search service

ElasticPress (backed by Elasticsearch or OpenSearch) and Algolia move search off MySQL entirely into a system designed only to do search. Your content is synced to the service, and queries hit that engine instead of your database.

The payoff is a different class of experience: sub-100ms responses on huge catalogs, real typo tolerance, instant search-as-you-type, and faceted filtering (filter by category, author, price, date while results update live). Elasticsearch also unlocks the same engine for your own WP_Query calls, which can dramatically speed up archive and filter pages, not just the search box.

The cost is operational. Algolia is a hosted SaaS billed on record count and search operations — generous to start, but it can climb on a large or high-traffic store. Self-hosted Elasticsearch means you are now running and patching a Java service with real memory requirements; managed options (Elastic Cloud, or hosts like WordPress VIP) remove that burden but add a monthly bill.

A concrete decision guide

Under ~1,000 posts, search is a convenience not a core feature: install Relevanssi free. Setup is roughly half an hour: install, run the initial index build, set title weight higher than content, enable stemming for your language, and you are immediately ahead of 95% of WordPress sites.
1,000–10,000 posts, or WooCommerce / custom-field / document search: SearchWP is worth its license. The weighted-engine model and document indexing solve problems the free options simply do not address.
10,000+ posts, or search is the product (large store, news archive, knowledge base): ElasticPress or Algolia. The performance and feature gap over database-backed plugins becomes too large to ignore, and the speedup to filtered archive pages is a bonus.

Tuning matters more than the plugin choice

Installing any of these and walking away leaves most of the value on the table. The settings that move the needle:

Field weights. A title match should outrank a body match by a wide margin. Most relevance complaints trace back to default-flat weighting.
Synonyms. Map the terms your readers use to the terms you write. "WP" → "WordPress," product SKUs to product names. This single step fixes a surprising share of zero-result queries.
Stopwords and minimum word length. Stripping "the," "and," "how" keeps short noise words from diluting scores.
Re-indexing discipline. Database-backed indexes do not always update live. Confirm new and edited posts get re-indexed (on save, or via cron) or your search silently goes stale.

The honest test is to pull the actual queries people type from your analytics or the plugin's own query log, run the top 20 yourself, and check whether the right post is in the top three. If it is not, the fix is almost always a weight or a synonym, not a different plugin.

Do not forget the results page

Even a perfect engine fails if search.php dumps ten untitled excerpts with no context. A results template that earns clicks shows the query back to the user, a result count, highlighted matching terms in each snippet, and — once you have faceting — filters to narrow down. This is a one-to-two-hour theme edit and it compounds on every single search a visitor ever runs.

Why this is quietly an SEO issue too

Search engines do not crawl your internal search results, so better on-site search is not a direct ranking factor. But the behavior it changes is. A visitor who finds the right article stays, reads more, and does not pogo-stick back to Google — and dwell time, pages per session, and the absence of that bounce-back are exactly the engagement patterns that correlate with sites Google rewards over time. Fixing search is one of the rare improvements that helps the reader in front of you today and the search rankings that bring the next one.

WordPress Search: Why The Default Is Bad And What Fixes It