You open the Page indexing report and there they are: dozens of URLs like /?s=cheap+watches, /?s=viagra, /?s=loan+fast. Your site’s internal search results, listed in Search Console, carrying queries nobody on your team ever typed.
Almost every article about this hands you a functions.php snippet. On a WordPress site running any version from the last five years, that snippet does nothing, because core already does it. The interesting question is not how to fix this. It is whether there is anything here to fix.
WordPress already noindexes these
WordPress core has shipped wp_robots_noindex_search() since 5.7, released in March 2021. The function reference states its job plainly: “If a search is being performed then noindex will be output.”
It is not optional and it is not a setting. Core’s default-filters.php hooks it unconditionally, adding wp_robots_noindex_search to the wp_robots filter with no condition around it. That line is in WordPress 7.1 today, in the same place it was in 5.7. So on a stock install, /?s=anything already serves a noindex robots meta tag with no plugin and no code from you.
Both major SEO plugins do the same thing independently. Yoast hardcodes it in its search result page presentation with no interface toggle at all, so there is no setting to check. Rank Math ships “Noindex Search Results” switched on by default at Titles and Meta, Misc Pages, with the explanation “Search results could be considered to be thin content and prone to duplicate content issues.”
So why are they in your report
Because a noindex page is still a URL Google found, and Search Console reports every URL it knows about, indexed or not.
These rows land in the non-indexed section as “Excluded by ‘noindex’ tag”, or as “Crawled - currently not indexed” if Google fetched them before deciding. Neither is an error. Both mean the system worked. I have written up what excluded by noindex tag actually means and the crawled but not indexed status at length, and search result URLs belong in the same bucket as feed URLs: bulk, expected, harmless.
The part worth a minute of attention is where Google found them. Your own site does not link to /?s=loan+fast. Somebody else does. Spam bots hit /?s= with junk queries at volume, and some of those requests originate from crawlable pages elsewhere, which is why the query strings in your report are so often in a language your audience does not read. The row in Search Console is an artefact of somebody else’s behaviour, not a symptom of a WordPress misconfiguration.
The one change that makes it worse
Add Disallow: /?s= to robots.txt and you have created the problem you were trying to solve.
Google’s documentation is unambiguous: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file.” A blocked URL cannot be fetched, so the noindex tag core is already outputting can never be read. The URL then sits in the report as a blocked-but-known URL, and can in some cases surface in results as a bare listing with no snippet, which is the exact outcome the block was supposed to prevent.
This is not a subtle trap. It is the most common recommendation in the articles ranking for this query, and several of them tell you to add the robots.txt rule and the noindex snippet in the same breath. The two do not stack. The full version of that argument is in noindex versus robots.txt, and if you are not sure what your site currently serves, where robots.txt lives on a WordPress site covers finding it when there is no physical file to open.
What about crawl budget
The crawl budget argument gets made confidently and it does not survive contact with the source.
Google’s guidance on managing crawl budget is scoped in its own opening: it is written for very large sites and for sites with large numbers of rapidly changing pages. The same document warns against reaching for noindex as a crawl-budget instrument at all, since “Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response”. Nothing in it names internal search pages, and nothing in it applies to a site with a few hundred URLs.
I checked the spam policies too, since “Google penalises indexed search results” gets repeated as though it were policy. The closest live line sits under doorway abuse: “Creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy.” That is about building your navigation out of search-result pages as a strategy. It is not about your /?s= URLs being crawled.
The nearest thing to an official opinion is John Mueller, in November 2022: “If you have good category pages, there’s usually no need to also have search pages indexed.” Reported speech from a trade publication rather than documentation, and note how mild it is. No need to have them indexed. Not a penalty, not a warning.
What I actually do
On a normal site, nothing. I confirm the noindex is being served, I confirm the rows are sitting in a non-indexed status rather than an indexed one, and I move on. The report is describing URLs a bot invented, and there is no version of this that costs you rankings.
Three checks, in order, each under a minute:
- View source on
/?s=testand look for the robots meta tag. If it says noindex, you are done. If it does not, something has removed the core filter, and that is worth investigating rather than papering over with a snippet. - Check robots.txt for an existing
?s=disallow. If a previous consultant added one, remove it. It is the one thing actively causing harm. - Read the query strings themselves. If they are spam in bulk, that is a bot volume question for your host or your firewall, not an SEO question. If they are real searches from real visitors, that is a site search log worth reading for content ideas, which is worth considerably more than anything the indexing angle offers.
One question I have not settled. Yoast’s Crawl Cleanup offers a search cleanup option that redirects junk search queries to the homepage rather than rendering them, which is a different trade from noindexing. On a site being hammered by bot searches that may genuinely be the better call, and I would decide it on server load rather than on indexing grounds. If your parameter problem is broader than search, meaning filters and sorts generating URLs at scale, that is a different shape of problem and faceted navigation is the piece to read instead.
Sources
- WordPress Developer Resources, wp_robots_noindex_search(), for “If a search is being performed then noindex will be output” and the 5.7.0 introduction, checked 6 September 2026
- WordPress core source, default-filters.php, for the unconditional wp_robots_noindex_search filter in the 7.1 branch, checked 6 September 2026
- Yoast SEO plugin source,
src/presentations/indexable-search-result-page-presentation.phpin version 28.5-RC2, for the hardcoded noindex with no setting, checked 6 September 2026 - Rank Math plugin source,
includes/class-installer.phpandincludes/settings/titles/misc.phpin version 1.0.278-beta, for the default-on Noindex Search Results option and its description, checked 6 September 2026 - Google Search Central, Block search indexing with noindex, for “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file”, checked 6 September 2026
- Google Search Central, Large site owner’s guide to managing crawl budget, for the scope of the guidance and the warning against using noindex to manage crawl budget, checked 6 September 2026
- Google Search Central, Spam policies for Google web search, for the doorway abuse wording, checked 6 September 2026
- Search Engine Roundtable, Google: good category pages mean no need for internal search results pages, 10 November 2022, for the John Mueller quote, checked 6 September 2026. Reported speech, not documentation