Bots try to hack my website every 52 seconds. I read 97 days of logs to see what they want.

A client forwards me a hosting email about "blocked login attempts" and asks the same question every time: is someone trying to hack my website, or is this just noise? I used to answer from experience. This week I answered it properly — I pulled 97 days of raw access logs off my own server and counted every single request.

453,580 requests reached the server between 14 June and 18 September 2026, from 40,716 different addresses. 159,815 of them were asking for software this site does not have. That is 35% of everything, an average of one probe every 52 seconds, and across 97 days there was not one quiet day. Not one.

That sounds alarming written down. It mostly isn't, and the reason why is the interesting part. This is what the traffic actually consists of, what the bots are really hoping to find, and the one number in my log that changed the way I explain website security to clients.

Is someone actually trying to hack my website?

Yes — constantly, automatically, and not because of anything you did. Automated scanners work through huge ranges of addresses looking for known software with known holes. On my own site that was 159,815 requests in 97 days from 6,352 separate addresses. Almost none of it succeeds, and none of it is personal.

Here is the whole window in one table. "Probe" here means a request for a path this site has never published, matching a known attack target, that got anything other than a 200 back. My own server's cron jobs, my uptime monitor and my own tooling are excluded, because counting yourself as an attacker is how you end up with a scary number and a wrong story.

One honest caveat before anyone quotes the 35%: my HTML sits behind a ten-minute cache, so a repeat page view can be served without touching the server that writes this log. Real human reading is undercounted here; the probe numbers are not, because nobody caches a 404. If anything, the share of my traffic that is junk is lower than 35% and the raw probe count is exactly right.

The other thing that jumps out: 4,486 of those 6,352 addresses asked for exactly one thing and were never seen again. 303 of them tried more than a hundred different paths, and the single busiest address worked its way through 1,820. Two completely different behaviours, and only the second one is a scan in any meaningful sense.

What are the bots actually asking for?

Seven recognisable categories cover almost all of it, and the shape is not what most people expect. The largest group by a wide margin is not a login attempt at all — it is bots guessing filenames, hoping to land on a backdoor script that an earlier attack already installed. Actual password guessing is a distant third.

Look at the bottom three rows. Together they are 2,119 requests out of 159,815 — about 1.3%. The genuinely targeted, thinking-attacker stuff is statistically almost absent. What fills a small-business server log is the cheapest possible automation running the same list of guesses at everybody.

Why are they guessing 5,908 different .php filenames?

Because they are not trying to break in. They are checking whether somebody else already did. A successful attack often leaves a small PHP file behind that lets the attacker back in later, and those files have well-known names. Scanners fire thousands of those names at every site, hoping to inherit a door that is already open.

Over 97 days my server was asked for 5,908 different .php filenames, 90,597 times, and every single one returned a 404. The names are strangely human:

• /1.php, /222.php, /aa.php, /x.php — whatever the last person typed in a hurry
• /alfa.php, /xleet.php, /ioxi-o.php — named after the toolkits that install them
• /adminfuns.php, /ms-edit.php, /wp-conffg.php — deliberate near-misses of real filenames
• /this_is_a_new_hello_world.php, asked for 522 times — somebody's test file that got into a scanner's word list and will now be requested forever

That last one is my favourite thing in the whole dataset, and it is also the clearest illustration of what this traffic is. Nobody chose my site. A list exists, my address is reachable, and the list gets run. The practical consequence for you is the reassuring one: if there is nothing on your server that was not deliberately put there, 90,597 of these requests are 90,597 404s.

Did taking WordPress off the site make the bots go away?

No — and I have an unusually clean measurement of that, because this domain changed underneath the same address mid-window. For the first 25 days it was still answering as a WordPress site. From 9 July it has been hand-written HTML with no CMS at all. Same domain, same server, same content, two completely different stacks.

The knocking did not care.

Read the last three rows together. The number of hostile requests went up. The number that got a useful answer went to zero. XML-RPC is a legitimate WordPress interface that lets one request carry many login attempts, which is exactly why brute-force tools love it — and for 25 days my server was politely replying to all 12,201 of them.

Two honesty notes so nobody over-reads this. The password-guessing collapse is not purely the stack: 1,506 of those 1,748 POSTs arrived in a single burst on 22 June, and scanners generally stop before POSTing once the GET returns a 404. And the jump from 1,242 to 1,789 probes a day is a filename-guessing campaign that ramped through August and faded again in September. It is one campaign passing through, not a trend to extrapolate from.

So should I move off WordPress?

Not on the strength of this. My log says the bots do not check what you run, which means the stack does not change how often you are knocked on. What it changes is how many things you have that are capable of answering. A maintained, updated WordPress with XML-RPC disabled gets most of that benefit without a rebuild.

The honest version of the trade-off is the one I wrote up in detail when I compared custom-coded sites and WordPress: the deciding question is whether you will be editing the site yourself, not security. Security is downstream of one habit — whether somebody keeps the software current. If nobody does, WordPress becomes a liability. If somebody does, it is fine, and an enormous share of the web runs on it without incident.

What I will say plainly: every plugin you install is one more thing that can answer a stranger. My log has 25,244 requests fishing for plugin files specifically, because knowing your exact plugin version tells a scanner which exploit to load. Every plugin you have stopped using but never deleted is still a file on the server that answers, and still a version number a scanner can read.

Which of these requests would actually ruin your day?

The quiet ones. 1,563 requests over 97 days — sixteen a day, a rounding error in the totals — went looking for configuration files that contain passwords in plain text. Those are the requests that do real damage, because they don't need an exploit. If the file is readable, they just read it.

That third row is the one that should make any developer sit up. .vscode/sftp.json is a file your code editor writes, containing the host, username and password of the server you deploy to. It has no business being on the server — but it gets uploaded by accident all the time, because a careless sync copies the project folder instead of the site folder. Forty-eight strangers checked mine for it this quarter.

The rule that covers this whole category: anything sitting in your web root is published, whether or not you link to it. That includes backup.zip, db.sql, index.old.html and the .git folder that got dragged along with a deploy.

How would I know if one of them actually got in?

Not from your hosting's "blocked attacks" email, which counts knocking. The authoritative source is the Security issues report in Google Search Console. Google's own documentation says to rely on that report as the source of truth, precisely because a browser warning may or may not reproduce for you depending on context.

Google groups what it finds into three kinds: hacked content, malware and unwanted software, and social engineering. Beyond the report, these are the signals worth knowing, in the order they usually arrive:

1. A warning label beside your listing in Google results, or a full red interstitial in the browser.
2. Pages you never wrote appearing when you search site:yourdomain.com — usually pharmacy or streaming spam in a language you don't publish in.
3. Your host suspends the account or emails about outbound spam. Hosts notice compromised sites through the mail queue long before you notice through the homepage.
4. The site behaves differently on a phone than on your desktop, or only for visitors arriving from Google. Redirect hacks hide from the logged-in owner on purpose.
5. Your log stops being boring. Probes return 404. A compromised site starts returning 200 to paths you never created — which is why I now read the log instead of guessing.

If one of those is true, the order of operations matters, and it is not "restore the backup". Restoring first destroys the evidence you need — and in Canada, if customer data was reachable, the law has things to say about what you do next, starting with a written record you have to keep for 24 months.

What should I actually do about all this?

Much less than the number 159,815 suggests. My server handled every one of those requests correctly by not having the file, which costs nothing and required no product. The work that matters is unglamorous and mostly free, and it is the same short list whether you run WordPress or hand-written HTML.

1. Take everything out of the web root that isn't the website. Backups, database dumps, .git, editor config, old copies. This is the single highest-value hour in this article.
2. Turn on updates and actually let them run. Core, plugins, theme. An abandoned plugin is a scheduled incident.
3. Delete plugins you don't use — deactivated is not uninstalled, and the files still answer.
4. Disable XML-RPC if nothing you use needs it. That is 18,770 requests a quarter that stop being able to accomplish anything.
5. Unique passwords, and two-factor on hosting, email and the domain. In the cleanups I have been called into, a reused password has been the way in more often than any exploit.
6. Backups stored somewhere other than the server they back up. A backup on the hacked machine is a souvenir.
7. Know who your host is and how to reach them out of hours. Half of a bad day is finding the phone number.
8. Check the other sites on the same hosting account. Shared account, shared blast radius — and the second site is always the one nobody looks at.

If you want a second opinion on what your site is currently exposing, the free audit will flag the obvious ones, and the six security basics guide goes through the defensive side properly. If this is a "I'd rather it was somebody's job" situation, that is what ongoing maintenance is for — patching, updates and off-server backups, which is roughly the whole of this article performed by somebody else.

Frequently asked questions

Sources. The traffic figures are my own: the SSL access log for leadlls.com, 14 June to 18 September 2026, 97 full days, 601,275 raw lines, parsed with my own infrastructure (server cron, uptime monitor, internal tooling) excluded. External sources read on 19 September 2026: Search Console Help — Security issues report for the three issue categories, "rely on the Security Issues report as the source of truth", the partial-fix rule and review timing; web.dev — Help, I think I've been hacked for Google's recovery process; Google Search Central — Malware and unwanted software; Google Safe Browsing site status to check any domain yourself; WordPress Developer Resources — XML-RPC; Hardening WordPress; Canadian Centre for Cyber Security — Baseline cyber security controls for small and medium organizations.