WordPress search not working? First check whether the search box fails to submit, the results page breaks, or a specific published page is missing. These are different problems. Adding a search plugin before identifying the failure can leave the original fault in place and add another system to maintain.
For a business site, a useful search should lead a visitor to the right service, answer or product. A results page full of loosely related articles is not enough. This guide separates a repair from a search upgrade and gives you a small test you can use to agree the work with a developer.
This is about the search field inside your website, not your position in Google. A Search Console indexing request cannot repair an internal search form.
Identify which part of WordPress search is failing
Choose a published page that anyone can open without logging in. Search for a distinctive word from its title, using the public search box in a private browser window. Keep the expected page URL beside the result. Avoid common words such as “the” as your first test.
| What you see | What to investigate | Next useful check |
|---|---|---|
| The search field or button is missing | The header, search block or device visibility controls | Compare desktop and mobile on the same page. Confirm which theme or builder owns the field. |
| Typing works, but submitting does nothing | The form action, button behaviour or JavaScript | Try both Enter and the search button. Record whether the address or results change. |
| Suggestions fail, but the full results page works | The live-search component and its request | Keep normal search available while investigating the suggestion layer. |
| A results page opens, but an expected page is absent | Publication status, searchable content types, fields and exclusions | Compare a distinctive title word with the phrase the customer actually uses. |
| The result exists, but the link or layout is wrong | The results template and destination URL | Open the result as a logged-out visitor, then inspect the owning template. |
| Different phrases show the same results | Whether the query reaches the engine and whether an old response is reused | Compare two clearly different searches before changing cache rules. |
This matrix is a way to narrow the investigation, not proof of a particular fault. If the search request returns a server error, preserve its time and error details for your host or developer. Do not repeatedly change unrelated settings until something appears to work.
Separate the search form from the results page
The WordPress Search block provides a search field with label and button options. Your site may instead use a theme field, an Elementor widget or a specialist live-search plugin. Start with the component that actually produces the visible field.
On a conventional WordPress site, opening /?s=distinctiveword after your own domain can help compare the normal search route with a custom header field. Use a harmless word from public content. This is only a comparison: a custom search engine or product-only search may intentionally use another route.
If that comparison returns the expected page but the header search does not, investigate what the header submits. A developer can check whether the phrase reaches the expected endpoint. If both fail, move on to content coverage and the results template. Neither result justifies switching off every plugin on the live site.
Also separate autocomplete from submission. A visitor may get no suggestions while typing but still receive correct results after pressing Enter. Conversely, suggestions can look correct while the final results page uses a different query. Test both paths before calling the repair complete.
Why a published page can be missing from search
A page being visible at its direct address does not establish that your search engine includes it. First confirm its status and visitor access. Drafts, private content, membership restrictions and deliberate exclusions should not be made public just to satisfy a search test.
The core WordPress search implementation normally searches the title, excerpt and content columns. Filters and custom search engines can change the behaviour. A value held only in a custom field is therefore not automatically covered by that default search.
This matters when a service name, model reference or other important phrase appears visually through a custom field or a builder integration. “I can see the words on the page” and “the search engine indexes those words” are different checks. Ask the developer to identify where the text is stored and which fields the active engine searches.
Use two tests on the same page: a distinctive title word and the phrase a customer would use. If the title search works but the customer phrase does not, you may have a coverage or wording problem rather than a broken form. Review the actual content before buying a new search system.
A small Webless check, with a clear limit
On September 11, 2026, we ran a read-only WordPress query for “maintenance” against published Webless content. The five returned records included our maintenance onboarding, SLA and monthly checklist articles. That confirmed that the server-side query could find those records in that test.
It did not verify the public search box, mobile suggestions or the order a customer would prefer. This distinction is useful when someone reports “search works on the server.” Ask for the browser journey as well as the query result.
Check the search results template
A working query still needs a template that displays the right results. WordPress explains this separation in its search results template lesson. On a block theme, the relevant template lives in the Site Editor; classic themes and builders have their own owners.
Have the developer check that the visible loop uses the search request rather than a fixed list of recent posts. Inspect the result title, excerpt and link together. A card showing the expected title but leading to the wrong destination is still a failed search journey.
Do not create a second results template or add broad CSS to hide the symptoms. Back up the exact template, correct its native query or display setting, and compare the before and after result. If the issue affects only a mobile popup or header, use the mobile navigation diagnostic guide to separate interaction problems from missing content.
For WooCommerce, check product search separately
A general site search and a product-only search do not necessarily cover the same records. Test the field your shoppers actually use. Compare a public product name with a service-page title so you can see whether the field is intentionally product-only.
Review the product’s publication state and catalog visibility before changing the search engine. WooCommerce documents product management and visibility through its product management guidance. Visibility extensions and role-based rules can impose further restrictions.
Do not expose a hidden wholesale product or private catalog merely to make it appear in a test. For an SKU or attribute query, verify that the particular search implementation supports that field. Product-name search working does not prove that every SKU, variation or attribute is searchable.
If results are present but the destination is unavailable, verify the product page separately. The acceptance test should end at a usable destination, not at a successful-looking results card.
Agree these five searches before approving a repair
Build a tiny acceptance set from your own business. Write down the exact query, the expected destination and the acceptable result before anyone changes the site. The examples below describe test types; replace them with your real public pages and products.
| Test query | What it proves | Acceptance condition |
|---|---|---|
| A distinctive word in a published title | Basic inclusion of known public content | The expected page appears and its link opens correctly. |
| A customer’s phrase for an important service | Whether customer language reaches the right offer | A useful result appears in the agreed position, or the missing capability is explicitly scoped. |
| A term stored in a required custom field or SKU | The agreed search coverage | The correct item appears if that field is part of the requirement. |
| A deliberately nonexistent phrase | The empty state | A clear no-results message appears, with another useful route and no broken layout. |
| A second, unrelated known title | Whether the query actually changes the results | The second expected destination appears; the first response is not simply repeated. |
Repeat the set on desktop and a narrow mobile screen while logged out. Check Enter, the button, any suggestions, result links and pagination when present. Keyboard focus should remain visible, and the results should not overflow the page. Include intentionally restricted content as a separate negative check if your business uses it.
Finally, repeat the checks on the public optimized version after the relevant cache refresh. Do not disable caching site-wide by default. If stale results are confirmed, correct the responsible cache rule for the actual search route. Our WordPress cache exclusions guide explains why dynamic visitor paths need separate consideration.
Do you need a repair or a better search engine?
Repair the existing setup when the form is misconfigured, a results template ignores the search query, or an unintended exclusion hides public content. These are ownership and configuration problems. Installing another plugin may not correct them.
Consider a search upgrade when the agreed requirement includes fields, relevance control, typo handling or other behaviour the current engine does not provide. Compare possible tools against the five-query acceptance set, not a generic feature list. Confirm indexing requirements, update behaviour and ongoing maintenance before committing.
Get help before making live changes when search supports a large catalog, membership rules or a shared header. Use staging for conflict testing and preserve the current setup. Keep private records, passwords and customer searches containing personal information out of screenshots and general contact messages.
Webless WordPress development services can be a fit for a focused search repair or a better-defined search experience. Start with the expected queries and destinations. That gives both sides a practical way to discuss scope and verify the result without assuming the website needs a redesign.