Why 404s can spike your hosting bill (and how to calm bot noise)

A “high CPU usage” warning with flat analytics is often not a slow plugin. It is bots hammering random URLs until your server spends real work returning endless 404s.

The fix is usually not a week inside WordPress. Confirm the 404 storm in access logs, then reduce that junk earlier with firewall controls and rate limiting, tuned so real visitors still get through.

What 404 hammering looks like

Typical pattern in access logs:

• Long runs of requests to paths that never existed
• Old plugin/theme endpoints, random .php filenames, obvious scanners
• Many IPs probing, or one IP blasting constantly
• Uniform or empty user agents; no cart or content browsing behavior

Analytics stay quiet because these hits never become sessions. Hosting still bills CPU and I/O.

Why a 404 is not free

A “not found” response still costs work. Depending on the stack, the request may hit the web server, rewrite rules, PHP, and a full WordPress bootstrap before the theme returns 404. Multiply that by thousands of junk paths and you get timeouts, elevated CPU, and a site that feels flaky under “no traffic.”

Intent varies: vulnerability scanning, inventory of targets, or warm-up before something louder. Outcome for you is the same: resource burn. At extreme volume it can feel adjacent to DDoS-style noise even when the goal is reconnaissance, not a headline attack.

Stop debugging the wrong layer first

When CPU spikes and orders look normal, open logs before you disable half your plugin list. If 404 volume dominates, optimizing WooCommerce queries will not fix request quality.

Goal: keep automated nonsense away from PHP. That is what a WAF / application firewall is for in this scenario.

Practical response with WP Security Ninja

If you use WP Security Ninja, start with the firewall docs and tighten abusive patterns carefully:

• Firewall documentation
• Cloud Firewall for edge-style blocking and rate controls

A calm workflow:

1. Confirm a 404 storm (not a real campaign spike).
2. Reduce obvious junk with rules / rate limits / bot controls.
3. Watch CPU, response time, and false positives (good bots, payment callbacks, monitoring).
4. Document thresholds so you can reuse them across sites.

Do not aim for “zero bots.” Aim for stable hosting while noise stays background noise.

Quick checklist

1. Confirm it is a 404 storm in access logs: junk paths, repeated probes, weak session signals.
2. Cut junk earlier with firewall and rate limits before WordPress boots. Start at /docs/firewall/.
3. Tune conservatively and write down what changed so you can undo or clone it.

WordPress performance work still matters for real traffic. When the pressure is request volume from scanners, firewall controls are the right first move.