“Restrict search results” describes two unrelated jobs. One is controlling what your site’s internal search box returns to visitors. The other is controlling what Google shows in its results. They use different mechanisms, they do not affect each other, and conflating them is the single most common reason this task goes wrong. This guide separates them, gives working code for the WordPress side, and covers what neither approach actually protects.
Restricting search results means two different things. To exclude posts from WordPress internal search, filter the query with
pre_get_postsor use a search plugin. To keep pages out of Google, apply a noindex meta tag. Neither hides content from anyone holding the direct URL.
Table of Contents
Two Different Searches, Two Different Tools
Your site has an internal search box. Google has an index. These are separate systems, and no setting affects both.
| What you want | Mechanism | What it does NOT do |
|---|---|---|
| Hide a post from your site’s search box | pre_get_posts filter, or a search plugin | Nothing to Google. The page still ranks |
| Keep a page out of Google | noindex meta tag via your SEO plugin | Nothing to internal search. Still appears in your search box |
| Both | Apply both, independently | Neither blocks direct URL access |
| Genuinely restrict access | Password protection, private status, or membership plugin | This is the only option that actually restricts |
noindex does not affect WordPress internal search. It is a directive to external crawlers, written into the page’s HTML head. WordPress’s own search runs a database query that never reads that tag. A post marked noindex will still appear in your site’s search results tomorrow.
Get clear on which problem you have before touching anything. The rest of this guide is organized around that split.
Restricting WordPress Internal Search
WordPress internal search is a database query, so restricting it means modifying that query. The pre_get_posts action hook runs before the query executes and lets you change it. Three checks matter in every snippet: only run on the front end, only on search queries, and only on the main query.
Exclude a category from search
php
add_action( 'pre_get_posts', function ( $query ) {
if ( is_admin() || ! $query->is_search() || ! $query->is_main_query() ) {
return;
}
// Replace 12 with your category ID. The minus sign excludes it.
$query->set( 'cat', '-12' );
} );Find a category ID by opening it under Posts, then Categories, and reading the tag_ID value in the URL.
Exclude a post type from search
php
add_action( 'pre_get_posts', function ( $query ) {
if ( is_admin() || ! $query->is_search() || ! $query->is_main_query() ) {
return;
}
// Only these post types will appear in search results.
$query->set( 'post_type', array( 'post', 'page' ) );
} );For a custom post type you control, the cleaner fix is registering it with 'exclude_from_search' => true rather than filtering afterward.
Exclude specific posts
php
add_action( 'pre_get_posts', function ( $query ) {
if ( is_admin() || ! $query->is_search() || ! $query->is_main_query() ) {
return;
}
// Post IDs to keep out of search results.
$query->set( 'post__not_in', array( 42, 87, 156 ) );
} );Those three guard conditions are not optional. Drop is_admin() and you break search inside the WordPress dashboard. Drop is_main_query() and you affect every secondary query on the page, including related-posts widgets and sliders.
Where to put this code
Not in Appearance, then Theme Editor. The article you may have read that says otherwise is giving you advice with two failure modes: your changes disappear on the next theme update, and a syntax error there can lock you out of your own admin with a white screen.
Three better options, in order of preference for most sites:
- A code snippets plugin. Survives theme changes, and most will catch a fatal error before it takes the site down. Easiest choice for non-developers.
- A child theme’s
functions.php. Survives parent theme updates. Reasonable if you already run one. - A small custom plugin. A single PHP file in
wp-content/plugins/. Most portable, and independent of themes entirely.
Whichever you pick, have a way to reach your files if something breaks. FTP or your host’s file manager will get you back in when the admin will not load. The same discipline applies to any custom code, which our guide to building a WordPress post template covers in the theming context.
Plugins for WordPress Search Control
If you would rather not write code, several plugins handle this through settings. Two are search engines that replace WordPress’s weak default, and one is a visibility toggle.
| Plugin | Cost (2026) | Best for |
|---|---|---|
| Relevanssi | Free version. Premium roughly $99 to $130 per year, lifetime option higher | Most sites. The free tier already covers relevance ranking and exclusions |
| SearchWP | Premium only, from about $99 per year, agency tiers $299 to $399 | WooCommerce and custom-field-heavy sites wanting a polished interface |
| WP Hide Post | Free, with a Pro tier | Simple per-post visibility toggles across homepage, archives, search, and feeds |
Pricing compiled from multiple 2026 comparisons, checked August 2026. Published figures vary by offer and currency, so check the vendor page before buying.
Three things worth knowing before you install any of them.
Check which “WP Hide Post” you are installing. Two plugins share that name. One has not been updated since 2015 and targets WordPress 4.2. The other is actively maintained and adds WooCommerce product visibility. Search results and directory listings do not always make the distinction obvious, so check the last-updated date before activating.
Relevanssi builds its own index table. Its documentation suggests estimating roughly three times the size of your wp_posts table. On constrained shared hosting, that matters.
Replacing search changes how everything behaves. These plugins do not just add exclusions, they replace the search engine. Relevance ranking, partial matching, and result ordering all change. That is usually an improvement, but test your search page rather than assuming.
Evaluating plugin maintenance is a general skill worth having, and the same reasoning we apply in our breakdown of Google Reviews WordPress plugins applies here: last-updated date first, feature list second.
Keeping Pages Out of Google
This is the other job entirely, and it uses different tools. To keep a page out of Google’s results, apply a noindex meta tag. Every major SEO plugin exposes this as a per-post toggle, usually labeled something like “Allow search engines to show this page in search results.”
The tag itself looks like this in the page head:
html
<meta name="robots" content="noindex, follow">Two mistakes are worth naming because they are near-universal.
Do not use robots.txt to hide a page you have also set to noindex. Blocking a URL in robots.txt prevents crawling, which means Google never reads the noindex tag. A page blocked in robots.txt but linked from elsewhere can still appear in results, typically with no description. If you want a page out of the index, allow crawling and let the noindex be seen.
Removal is not instant. The page has to be recrawled before the tag takes effect, which can take days or weeks. Google Search Console’s removal tool provides a faster temporary suppression while the permanent change propagates.
For content you want gone entirely rather than just hidden, deleting and redirecting is cleaner than a permanent noindex. Our guide to deleting a site in WordPress covers the visibility and removal options at the site level.
Hiding From Search Is Not Access Control
This section exists because the previous version of this article got it wrong, and the error is common enough to be worth stating directly.
Excluding content from search results does not protect it. Every method above changes what appears in a list. None of them changes who can open the page. Content excluded from search remains fully accessible to anyone with the URL, and that URL can still reach people through:
- Direct links, shared or bookmarked
- Your XML sitemap, unless separately excluded
- RSS feeds, unless separately excluded
- The WordPress REST API, which returns published posts by default
- Archive pages, category listings, and related-post widgets
- Internal links from other pages on the site
Even plugins built for this are explicit about it. WP Hide Post’s own documentation notes that a hidden post remains visible when accessed through its permalink, because that is precisely what the plugin is for.
If content is genuinely sensitive, use a mechanism that restricts access:
| Need | Use |
|---|---|
| Keep a page from public view entirely | WordPress Private visibility. Only logged-in editors and admins can view |
| Share with specific people outside your site | Password protected visibility |
| Restrict by user role or membership tier | A membership or content-restriction plugin |
| Protect customer or personal data | Not a CMS visibility setting. This belongs behind authentication, in a system built for it |
The distinction matters more than it sounds. A page excluded from search but publicly reachable will eventually be found, indexed from an external link, or discovered by a scanner. Treating search exclusion as a privacy control is how confidential documents end up in public search results.
Restricting Search on Other Platforms
The same split applies everywhere: the platform’s internal search and the search engine’s index are separate concerns. What changes is the mechanism.
Joomla. Smart Search is the built-in indexed search component. Content that should not be searchable is controlled through access levels and by excluding content types from the Smart Search index in the plugin configuration. Menu item settings and access levels do most of the work.
Drupal. The Search API module builds configurable indexes, letting you choose exactly which content types, fields, and taxonomies get indexed. Combined with Views, you can build search pages scoped to a defined subset. Drupal’s permission system is genuinely granular here, so unlike WordPress, access control and search visibility can align cleanly.
Magento and Adobe Commerce. Product-level settings control catalog search behavior. The Visibility attribute determines whether a product appears in catalog listings, search, both, or neither, and per-attribute settings control whether an attribute is searchable at all. For catalogs of any size this is configuration rather than code.
Shopify. Search is handled by the platform, with template-level control through Liquid in the search results template. Apps in the Shopify App Store add filtering and product exclusion. Note that Shopify’s search behavior has changed over the years, so verify against current documentation rather than older tutorials.
One consistent caveat across all four: as in WordPress, excluding an item from search does not make its URL inaccessible.
Frequently Asked Questions
Common questions about restricting search results, covering both internal site search and search engine visibility.
How do I exclude a post from WordPress search results?
Filter the search query with pre_get_posts and post__not_in, passing the post IDs to exclude. Guard the filter with is_admin(), is_search(), and is_main_query() so it only affects front-end search. Alternatively, a plugin like WP Hide Post provides a per-post checkbox with no code.
Does noindex remove a page from my site’s internal search?
No. noindex is a directive to external search engine crawlers, written into the page’s HTML head. WordPress internal search runs a database query that never reads that tag. A noindexed page still appears in your own search box unless you separately filter the query.
What is the difference between internal search and search engine indexing?
Internal search is your site’s own search box, powered by a database query you control. Search engine indexing is Google or Bing storing your page in their index. They are separate systems with separate controls, and changing one has no effect on the other.
Does hiding a post from search make it private?
No. Excluding a post from search changes what appears in a list of results. The post stays fully accessible at its URL and may still appear in sitemaps, RSS feeds, the REST API, and archive pages. For actual restriction, use Private visibility, password protection, or a membership plugin.
Where should I add custom search filter code?
Use a code snippets plugin, a child theme’s functions.php, or a small custom plugin. Avoid Appearance then Theme Editor: changes are lost on theme update, and a syntax error there can white-screen your site with no admin access to fix it.
Can I restrict search results to a specific category?
Yes. Set the cat parameter in pre_get_posts to the category ID for inclusion, or prefix it with a minus sign to exclude. You can also pass an array of IDs. Find a category’s ID in the tag_ID parameter of its edit URL.
Can I exclude media files from search results?
Yes. Restrict the post_type parameter to the types you want, typically post and page, which excludes attachment automatically. WordPress excludes attachments from the default search on most configurations, but plugins that replace search may index them, so check your settings.
Is it possible to restrict search results by user role?
Yes, though not with WordPress core alone. Check the current user’s role inside your pre_get_posts filter with current_user_can() and set query parameters conditionally, or use a membership plugin that handles content restriction across queries. The second is more reliable, since it also covers archives and feeds.
Can I restrict search results based on user location?
Only with additional tooling. WordPress has no built-in geolocation, so this requires a plugin or a custom integration with a geolocation service, then conditional query filtering. Caching complicates it further, since a cached page may serve one visitor’s location-specific results to another.
How do I stop Google from indexing a page?
Set the page to noindex through your SEO plugin, which adds the meta robots tag. Do not also block it in robots.txt, because blocking crawling prevents Google from reading the noindex tag. Removal takes effect on the next crawl, so use Search Console’s removal tool for faster temporary suppression.
Restricting Search Results Without Breaking Anything
Start by naming which of the two problems you actually have. If visitors are finding the wrong things in your search box, that is a query filter or a search plugin. If a page is turning up in Google, that is a noindex tag. Applying the wrong one produces exactly the situation from the top of this article, where the setting is correct and the symptom persists.
Then be honest about the third case. If the reason you want something out of search is that it should not be seen, no exclusion method covers that. Search filtering tidies a list. Private visibility, password protection, and membership plugins restrict access. Only the second group actually keeps anyone out.
The rest is straightforward. Guard your pre_get_posts filter with all three conditions, keep the code somewhere a theme update will not eat it, and check the last-updated date on any plugin before it goes near a live site. Which of the two searches were you actually trying to fix?
