WordPress Search
Core search matches words in post titles and content, in date order, with no ranking worth the name. On a small blog that is fine. On anything larger it quietly sends people away.
Core WordPress search is a LIKE query ordered by date. It looks for your words in the post title, content and excerpt, and returns whatever matches newest first. There is no ranking, no stemming, no typo tolerance, and no awareness of anything stored outside those three fields.
On a fifty-post blog that is adequate. On a documentation site, a shop or a site built with a page builder, it produces results bad enough that visitors stop using the search box and leave.
The four specific failures
No relevance. A page mentioning your term once, published yesterday, appears above the page about that term written last year. Users assume the good page does not exist.
Fields it cannot see. Custom fields, taxonomy terms, product attributes, and page builder content held in post meta are all invisible. This is why a site rebuilt in a builder appears to lose its search — see page builders for why the content moved.
No forgiveness. A singular does not match a plural, a typo matches nothing, and two words match only where both appear somewhere in the same post.
It gets slower as you grow. A wildcard LIKE across the content column cannot use an index. On a large site each search is a full scan, and a burst of bot traffic hitting search URLs is a real cause of load — one reason searches belong in the picture when speeding up a site.
The three levels of fix
| Level | What it changes | When it is right |
|---|---|---|
| Tune core | Exclude noise, restrict post types, improve the results template | Small sites where results are nearly right |
| A relevance plugin | Weighted ranking, custom fields and taxonomies included, its own index | Most sites, most of the time |
| A hosted search engine | External index, typo tolerance, instant results, no database load | Large catalogues and heavy search use |
Work down the list rather than up. A surprising number of "search is broken" complaints are solved at level one, because the site was returning attachments, revisions or a hundred irrelevant post types.
Level one: what to fix without a plugin
Start by restricting what is searchable. Attachment pages, in particular, pollute results on media-heavy sites — see the media library for why they exist at all.
// Search only posts and pages on the front end.
add_action( 'pre_get_posts', function ( $query ) {
if ( ! is_admin() && $query->is_search() && $query->is_main_query() ) {
$query->set( 'post_type', array( 'post', 'page' ) );
}
} );
Then look at the results template itself. Many themes render search results with no excerpt, no date and no indication of what type each result is, which makes even correct results unusable. Showing a highlighted excerpt does more for perceived quality than any ranking change.
Finally, handle the empty state. "No results found" is a dead end; a page that offers popular content, a category list or a contact link recovers the visit. Empty results are also a signal — see the measurement section below.
Level two: relevance plugins
A relevance plugin builds its own index of your content, with weights: a term in the title counts for more than a term in the body, custom fields and taxonomies can be included, and results come back ranked rather than dated.
What to check before choosing one:
- Does it index the fields your content actually lives in, including custom fields and builder output.
- Does it re-index automatically after imports and bulk edits, or does the index silently go stale — the same trap described in FacetWP.
- What does the index cost in database size and write time on a large site.
- Does it handle WooCommerce products, including SKUs and attributes, if that matters.
Search and filtering are different jobs, incidentally. Search answers a typed question; filtering narrows a known set, which is product filtering territory. Sites often need both and should not expect one plugin to be good at both.
Level three: a hosted engine
An external service holds the index, so queries never touch your database. You get typo tolerance, synonyms, instant as-you-type results and analytics, and you take on a monthly cost, a data transfer to disclose, and a dependency in a user-facing feature.
That trade is worth it for large catalogues, sites where search drives most navigation, and databases already under pressure. It is overkill for a blog, and the failure mode — an outage taking your search box down with it — should be a designed fallback rather than a surprise.
Measuring whether search works
This is the step almost nobody takes, and it is the only way to know.
- Log search terms and result counts. Most relevance plugins do this; a few lines of your own will too.
- Read the zero-result terms weekly. They are a content plan written by your visitors.
- Watch searches that repeat on the same session — that is someone failing to find something you have.
- Check what people search for immediately after landing on a page, which usually means the page did not answer them.
Zero-result terms are the most valuable output. They tell you either that content is missing, or that your content uses different words than your audience does — the same insight that drives the SEO checklist, but sourced from people already on the site.
Common mistakes
- Adding a search plugin without restricting post types, so the ranking is better but the noise remains.
- Indexing everything, including admin-only fields, and wondering why results are strange.
- Leaving the default "no results" page in place.
- Assuming search results are indexed by Google — search result URLs should generally not be, and are a common source of thin pages in the index.
- Never looking at the search log, and so never learning what the site is missing.
Verify
Search for a term you know appears in a page title, and confirm that page is first. Search for a plural, a typo and a two-word phrase. Search for a value that lives in a custom field. Then check the empty state by searching for nonsense — if that page offers the visitor nothing, fix it before touching anything else.
Frequently asked
- Core search looks at post title, content and excerpt only. Custom fields, taxonomy terms, product attributes and anything stored by a page builder in its own format are invisible to it, which is why builder-heavy sites often return nothing.
- Effectively no. Results come back ordered by date, so a passing mention published yesterday outranks the definitive page from last year. That single behaviour is the biggest reason default search feels broken.
- Only at scale or with heavy traffic. A relevance plugin is enough for most sites up to a few thousand posts. A hosted engine earns its cost when the catalogue is large, search is used constantly, or the database is already under pressure.