You type a search term into the WordPress search bar on your site and get no results — even for content you know exists. Or the search returns completely unrelated posts. Or it was working last week and stopped after a plugin update. Or it returns results but excludes an entire post type. WordPress search not working is especially disorienting because WordPress does have a built-in search function — it just tends to be fragile and limited, breaking easily when plugins modify the query or when custom post types are not explicitly included. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
WordPress Search Not Working — Identify the Failure Type
The fix for WordPress search not working depends entirely on which of three distinct failure modes applies. Each looks similar from the front-end but has a completely different root cause.
Mode 1: Zero results for every query. The search form submits correctly (URL changes to ?s=query) but returns “Nothing found.” This is almost always a query modification by a plugin or theme that is either filtering out all results or targeting the wrong table/fields. The search itself is executing but returning an empty result set.
Mode 2: Search form does nothing or redirects incorrectly. Submitting a search query either redirects to the homepage, produces a 404, or returns to the search form with no URL change. This is a form configuration problem — the action attribute on the search form is pointing to the wrong URL, or the search parameter name is incorrect. This is common after domain changes, permalink restructuring, or when a theme uses a non-standard search form. Mode 3: Missing post types. Search returns results, but only from default post types — posts and pages — while products, portfolio items, events, or other custom post types are completely excluded. WordPress’s default search query does not include custom post types unless they are registered with 'publicly_queryable' => true and explicitly added to the search query. Identifying which mode applies before starting any fix for WordPress search not working determines the correct five-minute solution.
Restoring Basic WordPress Search Functionality
For Mode 1 failures where WordPress search not working returns zero results, two quick fixes resolve the majority of cases without any code changes or plugin installations.
First fix for WordPress search not working: resave permalinks via Settings → Permalinks → Save Changes. WordPress search uses query variables that depend on the rewrite rules, and corrupted or stale rules can prevent search queries from resolving correctly. The resave flushes and regenerates all rewrite rules, restoring the query variable routing that powers the search system. Test the search immediately after saving — if results now appear, the permalink flush resolved a stale rewrite rule that was intercepting or misrouting the search query.
Second, test with all plugins disabled to isolate plugin-caused WordPress search not working using Health Check & Troubleshooting → Troubleshooting Mode. With all plugins off, test the WordPress default search on a couple of known post titles. If results appear, a plugin was filtering or overriding the search query in a way that produced zero results. Re-enable plugins one at a time → test search after each → the plugin that triggers the zero-result failure after activation is the conflict. Common culprits for WordPress search not working include SEO plugins that modify query variables (Yoast, RankMath), security plugins with query sanitisation settings, and custom search plugins that partially replace the default search rather than fully overriding it. Our guide on fixing WordPress plugin conflicts covers the complete isolation process that applies whenever a plugin is the suspected cause.
Including Custom Post Types in WordPress Search
The most frequent WordPress search not working complaint from site owners with custom content — “search finds blog posts but not my products / events / portfolio items” — is caused by WordPress’s default search query explicitly limiting results to post types where exclude_from_search is false. Custom post types are excluded from search by default unless configured otherwise at registration.
If you control the post type registration code and need to fix post-type WordPress search not working (in functions.php or a custom plugin), ensure 'publicly_queryable' => true and 'exclude_from_search' => false are set in the register_post_type() arguments array. If the custom post type is registered by a plugin you cannot modify, hook into pre_get_posts to add the post type to the search query:
add_action('pre_get_posts', function($query) {
if ($query->is_search() && $query->is_main_query() && !is_admin()) {
$query->set('post_type', ['post', 'page', 'product', 'your_custom_type']);
}
});Add this to the child theme’s functions.php. List every post type that should appear in search results. After adding the hook, test the search — the previously excluded post types now appear in results. The is_main_query() check prevents the hook from modifying admin queries or secondary queries on the page, which would cause performance and display problems unrelated to WordPress search not working. According to the WordPress developer documentation, the default WordPress search query respects the exclude_from_search flag set during post type registration, making this flag the primary control point for whether a custom post type appears in search results.
Fixing WordPress Search With SearchWP or Relevanssi
The native WordPress search has fundamental limitations beyond WordPress search not working outright: it searches only post title and content fields, ignores custom fields and taxonomy terms, and ranks results by date rather than relevance. For sites where search quality matters — WooCommerce stores, knowledge bases, documentation sites — a search plugin provides both reliability and dramatically better results.
SearchWP and Relevanssi are the two leading search replacement plugins. Both replace WordPress’s default search query with their own indexed search system. SearchWP (paid, $99/year) provides the most comprehensive replacement — it indexes custom fields, PDF content, WooCommerce attributes, and taxonomy terms with configurable relevance weights per field. Relevanssi (free tier available) provides full-text search with stemming support, fuzzy matching, and custom field indexing. Both resolve all three WordPress search not working failure modes simultaneously because they bypass the default WP_Query search mechanism entirely and use their own indexed search tables.
Install Relevanssi (free version) → Relevanssi → Indexing → Build Index. The indexing process scans all posts and custom fields, creating a searchable index in the WordPress database. After indexing (takes seconds to minutes depending on content volume), test search — results are now ranked by relevance rather than date, include content from custom fields, and respect the post types configured in Relevanssi’s settings. Enable fuzzy search in Relevanssi → Search → Fuzzy Matching to handle typos and partial word matches. This single change often resolves a WordPress search not working complaint where users were getting zero results because their search term was a substring of a longer word or contained a minor spelling variation. Our guide on optimising WordPress performance covers database indexing strategies that complement the search index Relevanssi creates for fast query execution on large content libraries.
Search Form and URL Configuration Issues
Mode 2 failures — where WordPress search not working means the form does not submit correctly — are theme or URL configuration problems rather than query problems. The search results page exists and would work, but the form is not reaching it correctly.
Inspect the search form HTML: right-click the search form on the front-end → Inspect Element → find the <form> tag. Check the action attribute — it should point to the site’s home URL (e.g., action="https://yoursite.com/"). If it shows an old domain, an HTTP URL on an HTTPS site, or a completely incorrect path, the form is submitting to the wrong destination. Fix by updating the search form template in the theme (search in the theme files for get_search_form() or searchform.php) or by using a plugin that outputs a corrected search form. Also verify the <input type="hidden" name="s"> or <input type="search" name="s"> exists within the form — the name attribute must be exactly s for WordPress to recognise the search parameter. A theme that changed this attribute name to anything else (like query or search) causes WordPress search not working because WordPress’s search router only listens for the s parameter.
After a domain migration, the search form action URL sometimes retains the old domain because it was hard-coded in the theme template rather than generated dynamically via home_url('/'). Run the Better Search Replace plugin to update the hard-coded domain in the database — but also check the theme files directly for any hard-coded URLs, which are not in the database and would be missed by a database search-replace. Hard-coded URLs in theme files require direct file editing via FTP or a child theme override. After fixing the form action URL, test by submitting a search — the URL in the browser address bar should change to https://correctdomain.com/?s=yourquery, confirming the form now submits to the correct endpoint and resolving the WordPress search not working form configuration issue. Reviews from the WordPress support forums confirm that plugin query modifications and missing custom post type inclusion together explain the majority of WordPress search not working reports across all recent WordPress versions.
AJAX-powered live search widgets — where results appear as the user types without a full page reload — introduce a different category of WordPress search not working failures. The visual widget appears, typing shows a spinner, but no results load. This is almost always a JavaScript error in the AJAX handler or a REST API permission issue. Open the browser console (F12) → type a search query in the live search widget → look for red error entries in the console. A 403 or 401 error in the Network tab means the AJAX search request is blocked by a security plugin or authentication requirement. A JavaScript error in the console names the specific script that failed. Live search plugins typically require the REST API to be fully functional — check that yoursite.com/wp-json/ returns JSON data rather than an error or redirect.
Search indexing lag causes WordPress search not working for recently published content on sites using Relevanssi, SearchWP, or ElasticSearch-based search. These plugins maintain their own index that is updated when content changes, but some configurations only reindex on a schedule rather than immediately on publish. If a post published five minutes ago does not appear in search results, check the search plugin’s indexing status and either trigger a manual reindex or adjust the indexing frequency. Relevanssi → Indexing → Index Status shows how many posts are indexed and highlights any unindexed content. Running “Index missing content” from this page catches any posts that were published while the indexer was paused or encountered an error, restoring complete search coverage. Our guide on fixing WordPress admin dashboard slow performance covers the database and query optimisation that also affects search index query speed on large sites.
The WordPress search results page uses the search.php template file in the active theme, and a broken or missing search.php causes WordPress search not working visually — search queries submit correctly and URLs change to ?s=query — but the results page shows completely wrong content or an error. Check whether your theme has a search.php file: via FTP, look in the active theme folder. If missing, WordPress falls back to index.php, which may not handle search results correctly depending on the theme’s code. Create a basic search.php in the child theme folder using WordPress’s standard search template structure, or copy one from a default WordPress theme. A functional search.php that correctly uses have_posts(), the_loop(), and displays the get_search_query() value ensures WordPress search results display reliably regardless of the main theme’s template structure.
Password-protected posts and private posts are intentionally excluded from WordPress search not working diagnostics — WordPress does not include private or password-protected content in search results for non-administrators by default, which users sometimes interpret as a search failure when they cannot find their own private drafts. Confirm that the content you are searching for is actually published publicly, not set to Private or Password Protected in the post status. Administrators can find private posts via the admin post list (Posts → All Posts → filter by Private), but these will never appear in front-end search results for regular users without custom code that explicitly includes private post statuses in the search query.
Multisite WordPress installations require additional consideration for WordPress search not working because search is scoped to the current subsite by default — a search on site2.network.com only searches that subsite’s content, not the entire network. For a network-wide search that spans all subsites, a dedicated plugin like Search Everything or ElasticPress with multisite support is required. These plugins extend WordPress’s search query to join multiple site database tables, returning results from all subsites in a single merged result set. For smaller networks where cross-site search is needed only occasionally, a custom WP_Query that loops through all registered sites using get_sites() and runs a search on each one provides a simpler solution than a full network search plugin, though it is less performant on large networks.
