The AI Summary Said "It's Not a Scam." The Springboard Was Your Site's Search Box

#webdev #security #seo #ai

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).

The mechanism: three steps, no hacking

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:

Anyone can put an arbitrary string in the query parameter
The page reflects that query into its <title> or <h1> ("Search results for 'keyword' | Acme Corp")

The attack:

The attacker composes a search URL on a trusted domain: acme.com/search?q=XX+is+not+a+scam. No need to touch the search box. The URL alone does the job.
They link to that URL from sites they control.
Googlebot follows the link, crawls the results page, and indexes it. From then on, web search can show "XX is not a scam | Acme Corp" under a legitimate domain.

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.

Why the AI summary repeats the lie

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.

The 5-minute self-check

Can your site be used as a springboard? Three checks:

# 1. Are your search result pages indexed? (in Google)
site:example.com inurl:search
site:example.com inurl:"?s="

# 2. Indexed under suspicious phrases?
site:example.com scam
site:example.com refund

# 3. Do your search result pages carry noindex?
curl -sI "https://example.com/search?q=test" | grep -i x-robots-tag

# No header? Check the HTML meta 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.

Defenses

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:

Not chasing SEO traffic on search result pages? noindex all of them. Simplest, most reliable.
Want to keep that traffic? Return noindex on zero-hit queries. Spam phrases like "XX is not a scam" almost always hit zero results, so this alone kills most of the attack.

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;
    # re-declare upper-level add_header lines (security headers etc.) here
    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.

Wrap-up

The "not a scam" poisoning that Japanese police warned about is explained by site-search spam. What's exploited is the spec: reflect the query, allow indexing.
AI summaries are RAG over the search index. Upstream poison becomes the downstream answer. Closing your reflection surface is faster than waiting for AI-side filters.
noindex is the backbone. Never robots.txt-block a URL you want noindexed. Keep search traffic if you want it, but noindex on zero hits.

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"?