How WordPress Searches
Let’s break down this query a little bit.
- First, we are using
wp_poststable. This says, if there were no limit (coming later), how many results would the following query turn up?
- Then we search through the
post_contentcolumns 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:
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.
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 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.
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.