WordPress site search overloading the database — detecting ?s= abuse and unbounded queries

1. Problem

Your WordPress site is crawling. TTFB is up to 4–8 seconds. The dashboard feels sluggish, but PHP isn't crashing and Uptime Robot is green. The hosting provider emails you: "MySQL CPU at 95% sustained for the last 40 minutes."

You open the access log and start scrolling. Almost every other request looks like this:

"GET /?s=cheap+watches+for+sale HTTP/1.1" 200 18234
"GET /?s=%E5%A5%BD%E8%B5%B7%E6%9D%A5 HTTP/1.1" 200 17981
"GET /?s=viagra+online HTTP/1.1" 200 18102
"GET /?s=order+by+1-- HTTP/1.1" 200 18012

Different IPs. Different user-agents. Same shape. This is the WordPress site slow because of search problem — and it is almost always either a competitor scraper, a low-effort SEO spam probe, or a botnet hammering /?s= because they know exactly what it costs you. You're seeing a wordpress search query overloading the database, and a wordpress ?s= attack high cpu pattern that the WordPress dashboard will never warn you about.

2. Impact

Native WordPress search is the most expensive public endpoint your site exposes. A homepage hit is cached. A category page is cached. A ?s= query bypasses page cache by default, runs a LIKE '%term%' against wp_posts.post_content, and forces a full table scan. With a 50,000-post site and 30 concurrent search requests, you can saturate a 4-vCPU MySQL instance in under a minute.

Concrete consequences:

• Checkout and login pages slow to a crawl because the DB connection pool is exhausted.
• Googlebot starts seeing 5xx responses; rankings begin to slip within 24–48 hours.
• Your shared host throttles you or threatens suspension for "abusive resource usage."
• You scale up the DB to survive — the attacker keeps going, and now you're paying for it monthly.
• The attack is cheap: a single $5 VPS can sustain enough ?s= traffic to take down most unhardened WordPress sites.

The economics are entirely on the attacker's side. One HTTP request from them costs them nothing. The same request costs you a full sequential scan of wp_posts.

3. Why It’s Hard to Spot

WordPress has no built-in surface for this. The admin dashboard shows comments and updates, not query counts. wp-admin's "Site Health" tool will not flag elevated search traffic. Jetpack stats lump search hits into "page views" with everything else.

Uptime monitoring fails the same way: the site returns HTTP 200, just slowly. Pingdom from us-east-1 hits a cached homepage and reports green. New Relic, if you have it, will show elevated DB time but won't tell you it's all LIKE queries on wp_posts unless you read the slow query log line by line.

The native WP search itself has no rate limit. There's no wp_login.php-style lockout. No CAPTCHA. No referer check. No POST/CSRF requirement — it's a GET. Any anonymous client can run as many of them as they want, and from WordPress's point of view it's just "users searching the site."

So you only find out when the database starts dying, or your host emails you, or PHP starts hitting wp_request_peak_memory_mb near WP_MEMORY_LIMIT because every request now waits longer for DB responses while holding the full PHP stack in memory.

4. Cause

The wp_search_requests_total signal is a per-entity counter incremented every time WordPress handles a request where is_search() is true — meaning a request to /?s=... or any URL that triggers WP_Query with a non-empty s parameter. The Logystera plugin emits this from the parse_query hook after WordPress has resolved the query type, so it captures both pretty-permalink searches and raw query-string searches.

Internally, when WordPress sees ?s=foo, it builds a SQL statement that looks roughly like this:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE 1=1
  AND (((wp_posts.post_title LIKE '%foo%')
    OR (wp_posts.post_excerpt LIKE '%foo%')
    OR (wp_posts.post_content LIKE '%foo%')))
  AND wp_posts.post_status = 'publish'
ORDER BY wp_posts.post_title LIKE '%foo%' DESC, wp_posts.post_date DESC
LIMIT 0, 10;

Three problems compound here:

1. Leading-wildcard LIKE '%foo%' cannot use any index. MySQL has to read every published row.
2. SQL_CALC_FOUND_ROWS forces the engine to count all matches even though only 10 rows are returned — it doubles the work.
3. Object cache miss: search results are not cached by default in WP_Query. Each unique ?s= term re-runs the full scan. Attackers exploit this by appending random tokens (?s=foo123, ?s=foo124, …) so even a configured page cache like LiteSpeed or W3TC creates a new cache entry per request — which then never gets reused.

A healthy WordPress site sees wp_search_requests_total at maybe 0.1–2 per minute per entity. During an abuse event we routinely see it climb to 30–300 per minute, sustained for hours. The rate, not the absolute count, is what matters.

5. Solution

5.1 Diagnose (logs first)

Start at the access log. This is the wordpress search query overloading the database fingerprint and you can confirm it in 30 seconds.

# Count search requests per minute over the last hour
grep -E '\?s=|&s=' /var/log/nginx/access.log | \
  awk '{print $4}' | cut -c2-18 | sort | uniq -c | sort -rn | head -20

If you see lines like 412 27/Apr/2026:14:23 (412 search requests in one minute), you are under load. A baseline is single digits.

Then check who is doing it:

# Top IPs hitting /?s=
grep -E '\?s=|&s=' /var/log/nginx/access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Three patterns confirm abuse rather than a viral inbound link:

• Many IPs from the same /24 or ASN — botnet or cheap proxy pool.
• Same user-agent string across 50+ IPs — python-requests/2.31, Go-http-client/1.1, or a spoofed Chrome version with no Accept-Language header.
• Search terms that aren't your content — viagra, CJK character bursts, SQL fragments like ' OR 1=1--, or random alphanumerics.

Now correlate to PHP. The same window will show wp_request_peak_memory_mb climbing because each request holds the full WordPress bootstrap while waiting on DB I/O:

grep -i "memory" /var/log/php-fpm/error.log | tail -50
grep -i "max_execution_time" /var/log/php-fpm/error.log | tail -50

Lines like PHP Fatal error: Allowed memory size of 268435456 bytes exhausted during a search burst are the secondary failure: PHP didn't run out because of a leak, it ran out because 40 PHP-FPM workers are all blocked on the same slow MySQL connection.

In MySQL itself, enable the slow query log if it isn't already and grep for the search pattern:

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

# then
grep -B1 "post_content LIKE" /var/log/mysql/slow.log | head -100

Each diagnostic above maps cleanly to a Logystera signal:

• Spike in /?s= access log lines → wp_search_requests_total rate.
• PHP memory pressure during the same window → wp_request_peak_memory_mb p95.
• Bot user-agent dominance → wp_bot_requests_total rising in lockstep.
• Slow WP_Query execution → perf.hook_timing on parse_query and the_posts exceeds 500ms.

When you see all four moving together in a 15-minute window, you have confirmed ?s= abuse, not a slow-plugin or slow-DB issue. The combination is what makes the diagnosis specific.

5.2 Root Causes

(see root causes inline in 5.3 Fix)

5.3 Fix

There is no single fix. Ranked by how much load each one removes, in priority order:

1. Block the abusive traffic at the edge.

If most requests come from a handful of ASNs or a clear bot user-agent, drop them before they hit PHP. In Cloudflare, add a WAF rule:

(http.request.uri.query contains "s=") and
(cf.client.bot eq false) and
(ip.geoip.asnum in {14061 16509 ...})

Or, in nginx:

if ($args ~* "(^|&)s=") {
    set $is_search 1;
}
limit_req_zone $binary_remote_addr zone=search:10m rate=10r/m;

location / {
    if ($is_search) {
        limit_req zone=search burst=5 nodelay;
    }
    ...
}

This is cause: scraper or botnet → maps to a continued spike in wp_search_requests_total from a small IP set.

2. Replace native search.

Native LIKE search on wp_posts is unfit for any site over ~5,000 posts. Two paths:

• ElasticPress + self-hosted Elasticsearch / OpenSearch — search runs against an index, not wp_posts. Each query is sub-50ms regardless of post count.
• Algolia / Meilisearch / Typesense — managed or lightweight self-hosted; search bypasses MySQL entirely.

Either one decouples search latency from MySQL CPU. The wp_search_requests_total rate does not change, but each request now costs ~1% of what it used to.

This is cause: unbounded LIKE query → maps to perf.hook_timing on parse_query returning to <50ms p95.

3. Cache search results.

If you can't add a search engine, force search results into the page cache with a strict TTL and a parameter normalizer:

add_filter('posts_pre_query', function($posts, $query) {
    if (!$query->is_search() || is_admin()) return $posts;
    $term = sanitize_text_field($query->get('s'));
    if (strlen($term) < 3 || strlen($term) > 60) return [];
    $cache_key = 'search_' . md5(strtolower(trim($term)));
    $cached = wp_cache_get($cache_key, 'search_results');
    if ($cached !== false) return $cached;
    return $posts;
}, 10, 2);

Combine with rejecting empty/short/over-long search terms — most attack payloads are either single characters or 100+ char SQL fragments.

This is cause: cache bypass on every unique ?s= value → maps to wp_search_requests_total flat-lining while your cache hit ratio rises in your CDN dashboard.

4. Rate-limit at the application layer.

If you can't touch nginx or Cloudflare, use a plugin (or 30 lines of PHP):

add_action('parse_query', function($query) {
    if (!$query->is_search() || is_admin()) return;
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = 'search_rl_' . md5($ip);
    $count = (int) get_transient($key);
    if ($count >= 20) {
        status_header(429);
        exit('Too many search requests');
    }
    set_transient($key, $count + 1, 60);
});

20 searches per IP per minute is generous for humans and lethal for bots.

This is cause: per-IP volumetric abuse → maps to wp_search_requests_total dropping while wp_bot_requests_total continues elevated (bots now see 429s).

5. Disable native search entirely if you don't actually use it. Many product sites, marketing sites, and documentation sites never need ?s=:

add_action('parse_query', function($query) {
    if ($query->is_search() && !is_admin()) {
        $query->is_search = false;
        $query->query_vars['s'] = false;
        $query->query['s'] = false;
        status_header(404);
    }
});

5.4 Verify

You're looking for wp_search_requests_total to drop back to a baseline rate within 10–30 minutes after applying the mitigation. If you blocked at the edge, the drop is immediate. If you replaced native search, the rate may stay similar but perf.hook_timing on parse_query should fall to <50ms p95 within one full traffic cycle.

Healthy looks like:

• wp_search_requests_total rate: 0.1–2 per minute per entity (varies by traffic; the shape matters more than the number).
• wp_request_peak_memory_mb p95 below 75% of WP_MEMORY_LIMIT.
• wp_bot_requests_total not dominating total requests (bots should be <30% in most cases).
• perf.hook_timing on parse_query and posts_pre_query under 100ms p95.

Confirm in logs:

# Search requests per minute right now
grep -E '\?s=|&s=' /var/log/nginx/access.log | \
  awk -v d="$(date -d '10 minutes ago' +'%d/%b/%Y:%H:%M')" '$4 > "["d' | wc -l

A number under 20 over 10 minutes on a normal-traffic site means you're back to baseline. If wp_search_requests_total has not dropped within 30 minutes of applying mitigation, your block isn't matching — go back to the access log and find which user-agent or IP range you missed.

6. How to Catch This Early

Fixing it is straightforward once you know the cause. The hard part is knowing it happened at all.

This issue surfaces as wp_search_requests_total.

The ugly truth about ?s= abuse: by the time MySQL is at 95% CPU, you're already 30+ minutes into the incident. The attack starts slow, ramps over 10–20 minutes, and only becomes visible when something else breaks downstream (DB CPU, PHP memory, 5xx rate). WordPress will not warn you. Your CDN will not warn you. Uptime monitoring will not warn you, because the site is technically still up.

This is exactly the failure shape Logystera is built for. The wp_search_requests_total signal makes the rate of is_search() requests a first-class metric per entity — visible the moment it deviates from baseline, not when MySQL starts dying. A simple rule on wp_search_requests_total rate-of-change (e.g. >10x baseline over a 5-minute window) catches scraper and botnet activity in the first minute, before PHP workers exhaust and before wp_request_peak_memory_mb starts climbing.

The same signal also gives you a clean attribution path. Correlated with wp_bot_requests_total, it tells you whether you're seeing a viral inbound (humans, varied user-agents, varied terms) or abuse (bots, narrow user-agent set, machine-shape terms). The decision to block, throttle, or replace search becomes data-driven instead of guesswork at 2am.

wp_search_requests_total is the one number that turns "the site feels slow" into "search traffic is 47x baseline, started 4 minutes ago, 80% from one ASN." That difference is the entire job.

7. Related Silent Failures

• wp_bot_requests_total spike without page-cache hit-ratio drop — credential-stuffing or REST API enumeration; same shape, different endpoint.
• wp_request_peak_memory_mb near limit + php.fatal ("Allowed memory size exhausted") — downstream symptom of ?s= abuse, or of an unrelated plugin leak; check whether wp_search_requests_total is also elevated.
• perf.hook_timing on init or wp_loaded over 1s — slow plugin bootstrap; not search-related but identical user-visible TTFB symptom.
• wp.cron type=missed_schedule — when ?s= floods exhaust workers, scheduled jobs miss their windows; check after any sustained search abuse incident.
• auth.attempt rate spike — bot operators who hit /?s= often probe /wp-login.php from the same IP pool minutes later; treat them as one incident.