How to Improve WordPress Native Search

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
wordpress search


If you have ever worked on a WordPress site with a massive amount of posts and pages, you might have noticed something about the WordPress search: it doesn’t perform well. In this article, we dive into why the default WordPress search doesn’t scale and some ways to make it better.

How WordPress Searches

By default, the native WordPress search performs a query on your database that looks something like this:

wp search query x

Let’s break down this query a little bit.

  • First, we are using SQL_CALC_FOUND_ROWS on the wp_posts table. This says, if there were no limit (coming later), how many results would the following query turn up?
  • Then we search through the post_title, post_excerpt, and post_content columns for the search term (in this example I searched “tech”).
  • And we ensure that the content returned is a post, page, or attachment (media).
  • We check to make sure the status is “public”–not deleted or private (if you are a logged-in user it will also search only your own private posts).
  • We order the results by matching title, descending, or post date, descending.
  • Last, we limit the results to 10, paginating the rest of the results.

That’s a whole lot of checks WordPress runs through just to return search results. And every time you iterate through wp_posts to perform each check, MySQL is processing all rows in wp_posts. When you have hundreds of thousands of rows in the wp_posts table, this query can get ugly really quick. Here are some benchmarks from a few of my sites:

query time posts x

On sites with a very large number of posts, the query took over 20 seconds! This is not a scalable search option for sites with high traffic.

Problem Identification

Knowing what we now know about the default search behavior, it’s important to call out why this might not be ideal for some websites.

  • WordPress only searches the “post_title,” “post_content,” and “post_excerpt” fields for your search terms. It also only presents “post,” “page,” and “attachment” post types. For users with custom post types, custom fields, or plugins like WooCommerce that add different page/post types, this can be problematic: these items will not appear in search results.
  • The query used by WordPress search performs very poorly at over 100,000 posts. For news sites or media sites with more than 100,000 posts, a search could take several seconds to perform.
  • The poor performance on the search query could cause server performance issues if your site receives a fair amount of search traffic.

Improving on WordPress Native Search

So now that we know WordPress native search isn’t an option for many sites, we can explore search solutions. Based on our problem identification above, our qualifications for a search solution include:

  • Search tools that will search all content or customized sets of content, not limited to the post types or post fields defined by default.
  • Search tools that perform well when presented with large data sets.
  • Search tools that will not cause poor server performance when presented with high traffic.

Below we will explore several solutions, including enterprise-grade external services and WordPress plugins.

Algolia Search

Algolia is an enterprise-grade search solution in which your posts and content are indexed offsite and returns results to your users. Its feature set includes fuzzy search, geolocation search, multi-language support, and search with synonyms.

Comparing search performance on a site with thousands of posts, there are some clear benefits with Algolia. Below is the performance of the default WordPress search:

wp search perf x

Notice the search took 7.43 seconds using the default WordPress search. However, after implementing Algolia search the results were nearly instant:

algolia search perf x

The Algolia results were about 15x faster than standard WordPress search! That is a massive improvement in performance. Not to mention, if the site supports a large amount of traffic with concurrent searches, it will not cause strain on the server. Offloading searches to an external service that is specifically optimized for searching is a big win.

Amit Verma

Amit Verma

Amit is a Indian living in Chandigarh. He is currently a Senior Software Engineer for ADSS. At various times, he has been the Social Editor. Prior to his engineering career, he was a Senior Write. You can follow him on Twitter and Facebook.

Leave a Reply

Your email address will not be published. Required fields are marked *

Newsletter Subscribe

Get the Latest Posts & Articles in Your Email


Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on telegram
Share on whatsapp
Share on facebook
Share on twitter
Share on linkedin
Share on telegram
Share on whatsapp
Share on email
Share on skype

Leaving Already, We will Miss You!

Subscribe to us so can keep you update on latest posts