When you publish a new website, the first thing it receives isn't human visitors. It's bots. Dozens, sometimes hundreds per day, probing routes that don't exist — /wp-admin, /.env, /phpmyadmin, /admin/login.php — to see if anything lands on something known.
It's not because your site is important. It's not because someone has you in their sights. It's because the entire public internet is being swept 24 hours a day, every day, by automated processes that don't distinguish between a photographer's blog and a listed company's admin panel. They're looking for the same thing on all of them: a door someone forgot to close.
The barrier to attacking has never been lower
Ten years ago, attacking a website required knowledge. Today, anyone can download in seconds a toolkit that automates the work: nmap, nikto, sqlmap, wpscan, dirb… lists of thousands of known routes, pre-made scripts for every WordPress vulnerability of the last ten years, brute-force templates.
And with the latest wave of large language models, the piece that was missing — interpreting the results, deciding what to try next — is now also within reach of someone who can't code. What used to require a technical profile can now be done by anyone with curiosity and a free afternoon.
The result is direct: there are more potential attackers, attacking faster, against more targets. And the targets, for the most part, still haven't noticed.
What that hostile traffic is actually looking for
If you look at the logs of an exposed server for 24 hours, what shows up is fairly repetitive:
- WordPress routes — even if your site doesn't use it.
/wp-login.php,/xmlrpc.php,/wp-admin/admin-ajax.php. Bots try because it's cheap, and because the world is full of poorly maintained WordPress installations. - Forgotten sensitive files —
.env,.git/config,backup.sql,config.bak,database.zip. A single hit and the attacker gets credentials, source code, or the entire database. - Default admin panels —
/admin,/administrator,/manager,/phpmyadmin. If the panel responds, brute force follows. - Blind injections — parameters like
?id=1' OR '1'='1against any form. They don't know which CMS you use, they try generic payloads. - Technology fingerprinting —
Serverheaders, typical static files, revealing 500 errors. Any data helps decide which exploits to apply.
None of this requires your site to be well known. It only requires it to be online.
The asymmetry of the problem
The attacker automates. They run a script against ten thousand domains and if one responds, they win. The cost per attempt is essentially zero.
The defender, on the other hand, rarely automates. If you manage a site without outside help, the most likely scenario is that you don't even look at the server logs — and if you do, you find thousands of lines mixing legitimate requests with automated junk. Separating signal from noise by hand doesn't scale.
That's the asymmetry: one side operates at machine speed, the other at the speed of a human reading text. As long as that imbalance holds, time always plays in the attacker's favor.
What you can actually do (without becoming a sysadmin)
The solution isn't to study security. The solution is to put the defender on equal footing: also automate. Recognize hostile requests, block known user-agents, ban IPs that repeat attack patterns, and limit damage before it reaches your code.
It doesn't have to be expensive. It doesn't have to be complex either. The basic pieces are:
- An entry filter that rejects obviously malicious requests before they touch your application.
- A traffic log that separates humans, verified bots (Google, Bing) and suspicious requests — in a view you can read in 30 seconds.
- A blocklist of IPs already identified as hostile, maintained automatically.
- Some kind of alert when something out of the ordinary appears — so you don't have to log into the panel every day.
With that you've solved most of the problem. The rest are targeted attacks, which are a different conversation and, honestly, far less frequent than the continuous background noise.
Conclusion
If your site is online, it's being scanned. That's not going to change — it's the new normal of the public web. What can change is what happens when that traffic arrives: whether it enters your code unfiltered or stays at the door.
The difference between a compromised site and a secure one rarely is the attacker's skill. It almost always is whether the defender bothered to close the door before going to sleep.