What happened
On Search Off the Record, John Mueller confirmed that blocking internal search-results pages is no longer listed as a requirement in Google Search Essentials. "Nowadays, we don't have that listed in the search policies," he said. The rule it replaces came from the 2007 webmaster guidelines, which treated internal search pages as automatically generated content or "infinite spaces" that needed to be kept out of the index.
Then he recommended blocking them anyway, for reasons that never had anything to do with policy. Crawl budget is the first: search pages are usually uncached, so every fetch triggers a database lookup, and an unbounded set of query URLs can generate more crawlable pages than a site has products. Mueller's illustration was blunt about the scale, imagining "100 million pages that are new" and Googlebot dutifully going off to crawl them. When a server strains under that, Google's response is to reduce crawling across the whole site, not just the search paths.
The second reason is hacked-content spam. An indexable internal search page will happily render whatever an attacker types into it, which is how sites end up with indexed queries for adult terms and phone numbers, and how they end up flagged in Search Console for a compromise that never touched the database.
Method, and the exception
Mueller's preferred method is one broad robots.txt rule, something like "/search/?", rather than a list of enumerated patterns that will not keep pace with however many parameter combinations the site can produce. He noted the trade-off with noindex, which lets Google crawl the page once before it is told not to index it, so it costs crawl budget in a way robots.txt does not. He advised against reaching for Search Console removal tools or serving 500 errors, both of which solve a different problem than the one at hand.
The exception is the part with consequences for ecommerce. Category pages powered by search functionality, Mueller said, warrant indexing for their structural value. That distinction is easy to state and easy to miss in implementation, because on a lot of stores the two things share a URL path. A faceted category listing, a curated collection assembled from a query, or a filtered subcategory can all be generated by the same internal search engine that produces the junk you wanted blocked.
What to do about it
Check what your disallow rule actually catches
Take whatever pattern currently blocks search on your site and run your indexed category and collection URLs against it. If a category page is generated from a search query and sits under the same path prefix, a broad disallow removes it from the index along with the noise. Any robots.txt tester will tell you, and it has to happen before you widen the rule, not after.
If you index internal search today, look for the spam signature
Search your own site in Google with a site: query against the search path. Indexed results for terms you do not sell, or pages carrying phone numbers you do not recognize, are the pattern Mueller described. That is a signal to block first and then work out how those queries got indexed in the first place.