Your Website Search Box Is Doing More for Spammers Than Customers

Take the search box off your website. On most small business sites it does more for spammers than it does for customers, and on a ten-page site nobody who pays you money would notice it had gone.

That is not a fringe position. In the episode of Google's Search Off the Record podcast published on 30 July 2026, John Mueller spent half an hour explaining how internal search pages get crawled and abused. At the end, his co-host Martin Splitt said of his own website: "I might just remove the search page because my pages are relatively easy to find" ^[1]. Mueller had made the same point earlier in the conversation. If a site has maybe five pages, he said, "people can just click through to those five pages."

Most business websites sit somewhere close to that. Home, services, about, a gallery, contact. A visitor finds what they need from the menu in two clicks. The search box sits in the header doing very little for them, and a great deal for somebody else.

What a search box actually does

Strip it back to the mechanism. A search box takes whatever is typed into it and turns it into a web address. On WordPress, that address is your domain followed by /?s= and the words. Your site then builds a results page, and most themes print the search words back in a heading at the top: "Search results for" whatever was typed.

Think about what that means from an operations point of view. Anyone, anywhere, can generate a page on your domain that displays words of their choosing. No password, no vulnerability, no break-in. They type, or far more often a script types for them, and your server builds the page on request.

For a customer looking for your opening hours, that is harmless. For someone advertising counterfeit medicine, it is free advertising space on the trusted address of a real business.

How spammers use it, in Google's own words

Mueller described the abuse on the podcast in some detail ^[1]. Spam operations look for common website platforms "that don't have their search results pages blocked." They then link to thousands of sites at once, each link pointing at a search address stuffed with adult or pharmaceutical terms and "a phone number" or "a Telegram address." Nobody is meant to visit your site. The point is a Google result that reads, in effect, call this number, sitting on your domain.

He was equally clear that this is not a hack. Your website is "doing that freely." That distinction matters for how you respond. It does very little for how it looks. Mueller said Google "might flag that as hacked," which means it can surface in the Security issues report in Search Console ^[6]. Google's automatic defences may only catch part of the problem, and "maybe it takes a month."

Consider a composite case, built from a pattern that turns up across small business sites. A piano teacher in Offaly gets a text from a parent. The parent searched the studio's name to find the date lessons restart after the mid-term break, and a few results down was a page on the studio's own web address with a heading about prescription drugs and a Telegram handle. The parent was polite about it. They also asked whether it was safe to pay the term fees through the website. Nobody broke in. The search box let a stranger write a page, and Google read it.

Mueller described almost exactly that moment: during the weeks before Google catches up, an ordinary customer searches, sees your business name beside a spammer's phone number, and as he put it, "that's not great."

Why most WordPress sites are less exposed than they look

Fairness matters here, because a lot of the advice online is out of date. WordPress has dealt with the worst of this for several years. Since version 5.7, WordPress core has included a function that adds a noindex instruction to search results pages, and it is switched on in WordPress's own default settings ^[2]. Noindex tells Google: you may look at this page, but do not show it in your results. Popular SEO plugins do the same thing; Yoast states that its plugin automatically adds noindex to internal search results ^[5].

So on a reasonably standard WordPress site, spam search pages are usually crawled and then left out of Google. They show up as clutter in Search Console rather than as results in front of customers.

The clutter can be heavy. A 2022 article on Yoast's own site described one site with a few thousand genuine articles that had recorded more than 90,000 spam search addresses ^[5]. That is a single site, reported in 2022. Treat it as an illustration of scale, not a benchmark for yours. Clutter still costs you, in two specific ways.

Server work that serves nobody

Mueller made a point on the podcast that most owners never hear: search pages "tend to be something that are not cached" ^[1]. Every search request goes to the database, runs a lookup, works out an order for the results and builds a fresh page. Splitt added that this can make the site slower for everyone else.

A page cache works because thousands of visitors ask for the same handful of pages. Search queries are the opposite. Almost every one is unique. A crawler working through tens of thousands of junk queries is asking your database to do fresh work on every single request, and that work comes out of the same server capacity your real customers depend on.

There is a limit here worth stating plainly, including about our own platform. Page caching cannot rescue you from this. Web60 serves the pages customers actually visit ready-made from cache, which is why they stay quick, but a search query nobody has ever typed before cannot be served from a cache by definition. The only real defences are fewer junk requests reaching the database, or a database that is not already struggling when they arrive.

A Search Console you can no longer read

The second cost is diagnostic. Search Console's Pages report is where you find out that an important page has dropped out of Google. When that report lists tens of thousands of excluded junk addresses, the one service page that genuinely fell out is easy to miss. The Yoast piece made the same observation: the spam is generally not harmful to rankings in itself, but it makes real problems harder to spot ^[5]. If you want the wider picture of what slows a site and what does not, our complete WordPress performance guide for business owners covers the rest of the stack.

The fix every forum recommends can backfire

Search for this problem and the standard advice appears within seconds: block the search address in your robots.txt file. Mueller himself called robots.txt "the easiest way" ^[1]. It stops Google crawling the search pages at all, which solves the server-load problem cleanly.

Now read Google's own documentation. Robots.txt, Google says, "is not a mechanism for keeping a web page out of Google" ^[3]. For noindex to work, the page must not be blocked by robots.txt, because otherwise "the crawler will never see the noindex rule" ^[4]. And a blocked page can still be indexed without ever being visited: "If other pages point to your page with descriptive text, Google could still index the URL" ^[3].

Other pages pointing at your page with descriptive text. That is a precise description of a search spam campaign.

When the block hides the noindex

So consider what happens on a WordPress site where noindex is already working. Somebody adds the robots.txt block on a forum's advice. Google can no longer open the search pages, so it can no longer see they are marked noindex. It is left with thousands of addresses on your domain and the spammers' own link text describing them. Owners who make this change can then find a new status in Search Console, "Indexed, though blocked by robots.txt", sitting against the very addresses they were trying to hide.

Mueller acknowledged the trade-off directly. Noindex, he said, is "almost cleaner because you avoid this potential state of a robotted URL being shown in search," though he considered it "very unlikely" to matter for real searches ^[1]. Pros and cons, in his words.

My position, as the person who has to keep sites stable: where noindex is already working, I would not add a robots.txt block as a first move. I would add it when crawl load is the actual problem, and accept the trade-off knowingly.

Two responses that make things worse

Panic produces two predictable mistakes, and Google addressed both.

• Using the Removals tool in Search Console. It hides addresses from Google's results for a while but does not stop Google crawling them. Splitt's summary on the podcast: "It just hides the symptom" ^[1].
• Returning an error to search requests. Some owners try answering suspicious searches with a server error, on the logic that a broken page cannot be indexed. Mueller was blunt: "What you definitely shouldn't do is serve something like a 500 result code." Google reads it as a struggling server and slows crawling "for the whole website, including all of the pages that are not in your search results pages" ^[1]. Your new service page then waits longer to be found, because of junk you were trying to block.

What I would do, in order

None of this needs a developer. It needs about twenty minutes and a clear order of operations.

1. Decide whether the box earns its place. If your site is a couple of dozen pages with a clear menu, remove the search box from your header or sidebar in the WordPress Site Editor or Widgets screen. If you run a shop with a real catalogue, keep it, and make it genuinely useful, because a search that fails your customers costs you sales in silence. One catch: removing the visible box does not switch off the search address itself. WordPress still answers /?s= requests, so the next step matters either way.
2. Verify the noindex. Open your own site with /?s=test on the end of the address, view the page source (Ctrl+U in most browsers) and look for a robots line containing the word noindex. If it is missing, a theme or plugin conflict has overridden the WordPress default, and that conflict is the thing to fix.
3. Verify what Google already holds. Check the Pages report and the Security issues report in Search Console. A site: search on Google can give a rough look, but Google does not treat it as a complete or diagnostic list.
4. Deploy a robots.txt rule only if load is the problem. If junk crawling is visibly slowing your site, add one clean rule covering the whole search pattern, which is what Mueller recommends: "one clean rule that covers the whole pattern" is easier to maintain ^[1]. Accept the trade-off described above.
5. Rule out a genuine compromise. If the spam text appears on your normal pages, not just on search results addresses, you are not dealing with search box abuse. That is injected content, and it needs a proper clean-up and a security review, not a robots.txt line.

Where your hosting comes into it

Strip out the brand names and the standard a host should meet here is easy to describe. Real pages should be served from cache, so that a crawler hammering uncached search addresses does not drown the visitors who matter. Changes like a robots.txt rule should be testable before they reach production, with a rollback available if something conflicts. And when Search Console flags something alarming, there should be a person you can ask who can read the server logs and tell you whether it is spam traffic or a genuine break-in.

Web60's Irish-hosted Nginx and caching stack is built around that standard. Pages are served through Nginx with FastCGI page caching and Redis object caching. There is one-click staging for testing changes before you deploy them, a built-in file manager if you need to add a robots.txt file, server-level hardening with automatic malware scanning, and an Irish-based support team made up of real people. If you are starting from scratch, the AI builder gives you a full WordPress site in under a minute, which means you can decide on day one whether a search box belongs on it at all.

To be fair to the other side of this: if search is the centre of your business, say a catalogue running to tens of thousands of products where customers expect instant, typo-tolerant results, enterprise e-commerce platforms with dedicated search infrastructure and a team tuning it genuinely suit that workload better than any standard WordPress search. That is a small minority of local businesses. For the plumber, the café, the accountant and the piano teacher, the question is far simpler.

The search box is a feature, not a fixture

Every feature on your website should be doing a job for a customer. The search box is one that many small sites inherit from a theme and never question, and Google's own Search Relations team has now said, more or less on the record, that a small site can manage without one.

If customers use yours, keep it, make it good, and verify the noindex is in place. If they do not, take it out and verify the noindex anyway, because the search address still exists. Then type something absurd into your own search page and look at what your website is willing to say on your behalf. That is the page a stranger can make, and now you know how to keep it out of Google.

Frequently Asked Questions

Has my website been hacked if spam pages with my web address appear in Google?

Not necessarily. If the spam words only appear on search results addresses (on WordPress, ones containing /?s=), the most likely explanation is that someone has been feeding spam phrases into your search box and linking to the results. Google's John Mueller described exactly this pattern in July 2026. If the spam appears on your normal pages, or in pages you did not create, treat it as a genuine compromise and get a proper security review.

Does WordPress stop search results pages appearing in Google?

Yes, by default. Current versions of WordPress add a noindex instruction to their own search results pages, telling Google not to show them in results. A theme or plugin can override this, so verify it: open your site with /?s=test on the end of the address, view the page source and look for a robots line containing noindex.

Should I block my search page in robots.txt?

Only if junk crawling is putting real load on your site. Robots.txt stops Google crawling the pages, but Google's documentation says a blocked page can still be indexed if other pages link to it with descriptive text, and Google cannot see a noindex on a page it is not allowed to crawl. Where noindex is already working, it usually keeps spam out of results more cleanly.

Will search box spam hurt my Google rankings?

Google says it does not treat indexable search pages as a spam signal in themselves, and noindexed spam addresses generally do not affect your rankings. The real costs are wasted server work, cluttered Search Console reports and, if any spam pages do get indexed, customers seeing junk next to your business name. If Google flags the site as hacked in Search Console, deal with that promptly.

Can I remove the search box from my WordPress website?

Yes. On most themes the search box is a block or widget, so you can remove it from the header or sidebar in the Site Editor or the Widgets screen. Removing the visible box does not disable the search address itself, so keep the noindex in place and verify it after the change.

Sources