Last August, a man planning a cruise googled Royal Caribbean's customer service number. Google's AI Overview served him a phone number at the top of the results. He called it, handed over his card details, and the number belonged to scammers. Similar cases hit Southwest Airlines searches. That variant, fake support numbers planted where AI summaries would pick them up, got plenty of coverage.
Last week, Japan's Metropolitan Police announced a quieter variant that I think deserves more attention from developers, because the attack surface sits on legitimate sites: the search box. Possibly the one on yours.
Here's the scene the police described: someone gets invited into an investment group on social media. Before sending money, they do the sensible thing and search the group's name. The results show "XX is not a scam" and "I made money with XX." The AI summary at the top of the page agrees: "XX is not a scam." Reassured, they transfer the money.
The victim's verification habit -- "let me search before I trust this" -- has been folded into the trap.
When I read the report, my first question was: how? I work on LLMO (optimizing sites to get cited by AI search) day to day, so I suspected one of the search-pollution techniques floating around SEO circles. The trail led to something older and dumber than I expected: site-search spam, documented by the Japanese SEO firm JADE back in February 2023.
This post covers the mechanism, why AI summaries repeat the lie, and the defenses you can ship this week (noindex, X-Robots-Tag
, 404-on-zero-hits).
Most sites with a search box return results at a URL like /search?q=keyword
. Two properties of a typical implementation set up the attack:
<title>
or <h1>
("Search results for 'keyword' | Acme Corp")The attack:
acme.com/search?q=XX+is+not+a+scam
. No need to touch the search box. The URL alone does the job.The victimized site was never breached. No malware, no intrusion, no tools. The attacker built a URL and placed a link. When I first understood this, I said "wait, that's it?" out loud. What's being exploited is not a vulnerability. It's a spec.
To the person searching, it looks like Acme Corp's website says "not a scam." The trust the domain spent years earning gets subleased to a stranger's sentence.
AI Overviews and similar features are structurally close to RAG: retrieve pages relevant to the query from the search index, then compose an answer from them. The internals aren't public, but the dependency is observable: the summary is built downstream of the index.
The AI has no way to smell the setup. What it retrieved is, as far as it can tell, text on a trusted domain. It doesn't verify claims; it weighs source authority and cross-source agreement. So if an attacker seeds the same sentence into search URLs on several reputable domains, the AI sees multiple independent authoritative sources agreeing.
That's the ugly part: the more seriously an AI weights authority signals, the better this attack works on it. The diligent ones are the easiest marks.
The pipeline is simple: search index upstream, AI summary downstream. Poison the upstream and the downstream poisons itself. You could wait for AI vendors to filter better (Google said it "took action" on the fake phone numbers; new ones kept popping up), or you could close the reflection surface on your own site, which is faster and actually under your control.
Can your site be used as a springboard? Three checks:
site:example.com inurl:search
site:example.com inurl:"?s="
site:example.com scam
site:example.com refund
curl -sI "https://example.com/search?q=test" | grep -i x-robots-tag
curl -s "https://example.com/search?q=test" | grep -i '<meta name="robots"'
site:
queries are a quick smoke test; Google doesn't guarantee exhaustive results. For a definitive answer, open Search Console and check Indexing > Pages and Performance > Pages for URLs containing /search
or ?s=
.
Also look at your search results template: does it reflect the query into <title>
or <h1>
? Reflection plus indexability is the combination that makes you a target.
One reassurance: client-side search (JS filtering in the browser, common on static sites) doesn't have this attack surface at all, because the server never returns different HTML per query.
Two viable strategies, based on JADE's recommendations:
| Measure | Effect | Caveat |
|---|---|---|
<meta name="robots" content="noindex"> |
||
| Reliably keeps result pages out of the index | Neutralized if robots.txt blocks the page | |
X-Robots-Tag: noindex header |
||
| Same, applied at infra level without touching templates | Same caveat | |
| noindex (or 404) on zero-hit queries | Keeps search-page SEO traffic while blocking spam | 404 can hurt UX for legitimate zero-hit queries |
robots.txt Disallow: /search |
||
| Suppresses crawling | Incomplete alone -- blocked URLs can still get indexed via external links |
Choosing is simple:
There is one trap worth internalizing: noindex only works if the crawler can read the page. Block the URL in robots.txt and the crawler never sees your noindex, which un-neutralizes the whole defense. Google's docs state it outright: for noindex to be effective, the page must not be blocked by robots.txt. Never combine the two on the same URL.
Implementation examples.
WordPress search pages (?s=
) get noindex by default if you run Yoast or similar. On a bare theme, use the wp_robots
filter (WordPress 5.7+, plays nicely with core and plugin output):
// functions.php
add_filter('wp_robots', function ($robots) {
if (is_search()) {
$robots['noindex'] = true;
}
return $robots;
});
Next.js (App Router):
// app/search/page.tsx
export const metadata = {
robots: { index: false, follow: true },
};
At the infra layer, nginx. Two gotchas in this snippet: it matches path-style search URLs (/search
), not query-style (?s=
); for those you'd branch on $arg_s
instead. And nginx's add_header
has inheritance rules that bite: a single add_header
inside a location cancels all headers defined at upper levels, so re-declare your security headers there.
location /search {
add_header X-Robots-Tag "noindex" always;
proxy_pass http://app;
}
Even setting the scam angle aside, noindexing search result pages is standard SEO hygiene: it prevents duplicate-content bloat and crawl budget waste. This is a good excuse to finally do it.
If you run a site, try site:yourdomain inurl:search
today. If anything comes back, the defense section above is your afternoon. Is your search box carrying someone's "it's not a scam"?