Your New Website Is Already Being Attacked

I have a small website behind Cloudflare. It gets about 15 real visitors a day. In the last 24 hours, Cloudflare blocked 1,170 malicious requests against it.

That’s 78 blocked attacks for every human being who visited. Roughly one every 75 seconds, all day and all night.

Nobody has heard of this site. It has no customer database, no payment processing, no traffic worth hijacking, no competitor who would benefit from taking it down. It is, by any reasonable measure, not worth attacking.

It gets attacked constantly anyway. So does yours.

What the Pattern Actually Looks Like

The shape of the traffic tells you more than the total does.

It arrives in bursts. A spike of 180 requests, then almost nothing for an hour, then another 100, then quiet again. Each burst is a different automated sweep arriving, working through its list, and moving on.

The largest spike of the day landed at midnight. The quietest stretch was between nine in the morning and noon.

That inversion is the tell. Real visitors show up during business hours. These don’t, because nobody is awake for them. There’s no person deciding to try your site. There’s a program working through an address list, and your domain is on it for no reason other than existing.

You are not a target. You are an address.

”Why Would Anyone Attack Us?”

This is the single most common thing I hear, and it’s completely reasonable. It also contains the mistaken assumption that somebody made a decision.

Nobody sat down and evaluated your business. Scanning the entire internet costs almost nothing now. A program that tries 10,000 domains an hour doesn’t need a hit rate worth mentioning, because the cost of the 9,900 failures is close to zero. It doesn’t read your About page. It doesn’t know whether you’re a law firm or a bakery or a nonprofit serving people with disabilities. It knows your server answered.

And the economics keep getting worse. Spinning up a fleet of bots across compromised servers used to take real skill. Now it takes very little of either skill or money, and AI tooling has made writing and adapting the scanning code faster than it has ever been. The volume goes up every year. None of it is aimed at you.

What They’re Knocking On

Automated sweeps are looking for a short list of very specific things, and almost all of it is WordPress-shaped:

• /wp-admin and /wp-login.php, to try credentials against the login form
• xmlrpc.php, an old WordPress feature that lets an attacker attempt hundreds of passwords in a single request
• Specific plugin folders under /wp-content/plugins/, checking version numbers against a list of known vulnerabilities
• Configuration and environment files that sometimes get left in a public directory, containing database passwords and API keys
• Backup files and exposed version control directories, which frequently contain the whole site including its credentials

Notice what all of those have in common. Every one of them assumes a server that runs code, stores configuration, and has somewhere to log in. The scans are so heavily WordPress-oriented because WordPress is the highest-probability guess on the internet. If you’re picking one thing to check for on an unknown domain, that’s the one.

This is the part where being small genuinely doesn’t help. A small WordPress site and a large WordPress site expose the same doors. The large one probably has someone watching them.

The Part That Doesn’t End

You can handle all of this. Put the site behind Cloudflare or CrowdSec, block aggressively, add exceptions later when something breaks, keep everything updated, keep the plugin count low. That works. It’s the right thing to do, and if you’re staying on WordPress it’s the whole job.

What it isn’t is finished. It’s a standing obligation, renewed monthly, forever, and it gets slightly harder every year as the automation gets cheaper. Nothing you do makes the traffic stop. You’re just choosing to stay ahead of it indefinitely.

That’s a legitimate choice. Plenty of sites should make it. But it’s worth seeing clearly, because most people paying for WordPress maintenance have never been told they’re buying a subscription to a permanent condition rather than a fix.

Where the Attack Surface Goes Away

Here’s the thing I find genuinely interesting about that 1,170 number.

If that site were static files, nearly all of those requests would be meaningless. Not blocked. Not defended against. Meaningless. There’s no /wp-admin to find, no login form to guess at, no xmlrpc.php, no plugin directory with version numbers in it, no database to inject, no code executing on the server to hijack. The scan runs, gets a 404 for everything on its list, and moves on.

The attacks don’t stop. The internet is still the internet. They just stop mattering, because there’s nothing on the other end of them.

That’s the actual argument for static sites, and it’s a different argument from “static sites are more secure.” More secure implies a stronger version of the same thing. This is a site with almost nothing to attack, hosted for free, that also happens to load faster than anything you can get WordPress to do.

If your site has already been through this, the recovery steps are in what to do when your WordPress site gets hacked. For the broader accounting of what all this overhead costs, I broke that down in the true cost of running WordPress.