If WordPress site search cannot find a published post, establish which search system serves the form and what content it is allowed to search. Native WordPress search, a theme's live-search widget, WooCommerce product search, and an external search plugin can return different results for the same phrase.
This guide concerns search inside your website, not missing Google rankings. Do not submit a sitemap or request Google indexing to repair an internal search query.
Build a small reproducible search set
Choose one publicly readable post with a distinctive phrase in its title and a second published record of the type that is missing. Include a draft or private record as a negative control, but never publish it just to make a test pass.
Record the exact phrase, expected public result, current status, language, and URL. Test as a logged-out visitor and, separately, as an authorized editor. Seeing a record in wp-admin is not proof a visitor should be able to discover it.
Inspect the form's actual request
Submit the public search form with browser Network open. Check the submitted term, route, post-type filter, and language parameters. If the form sends an AJAX request, inspect that response rather than assuming the normal search results template handles it.
A plain public request such as https://example.com/?s=distinctive-word can provide a comparison, but use the same content scope. A product-only widget should not be judged broken because it excludes blog posts.
Follow the result through four layers
| Layer |
Check |
| Record |
Public status and intended visibility |
| Registration |
Search inclusion for the post type |
| Query or index |
Filters, language and indexed fields |
| Template |
Returned results versus rendered results |
The post-type reference includes exclude_from_search. That setting is not the same as permissions or REST exposure. The pre_get_posts reference describes query customization that can also alter search scope.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Repair the layer with evidence
If a custom post type is missing, inspect its registration and the expected audience with the developer. Follow the content-model guide before making a private business record publicly searchable.
If a plugin maintains its own index, compare the record's update time with index status and configured fields. Use that vendor's supported rebuild process after checking resources and scope. Rebuilding an unrelated cache does not recreate a search index, and rebuilding the right index will not fix a deliberate exclusion.
If the response contains the correct record but the interface omits it, inspect the template or widget. Pagination, result limits, missing fields, and frontend JavaScript can hide results that the query already found. Keep the same fixture while testing so a content change does not obscure the cause.
Verify relevance and privacy together
Retest title terms, expected body terms, pagination, and the site's supported languages. Confirm the draft or private control remains inaccessible. Public search must not leak private titles or snippets simply because a record was added to an index.
Document the search provider, indexed content types, refresh method, and test phrases. Request a site-search investigation when several widgets use different backends or a custom filter changes scope. A precise missing-result example makes the repair testable.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.