How Safe Is Your Website, Really? A Night in the Server Logs

Most people assume their little local business website is quietly ticking along in the background. I did too, right up until I opened the server logs and watched my “quiet” site get hammered by bots, crawlers, and random nonsense URLs I’d never created. It went from “ah, I’ll just check a couple of errors” to “why are there 37,000 requests from Meta and who the hell is trying to log in from half the planet?”

What I found over a few hours was equal parts reassuring and unsettling. Reassuring, because the site wasn’t hacked, my security was doing more than I thought, and the errors weren’t all the end of the world. Unsettling, because the volume and variety of automated traffic hitting a small website is bloody ridiculous, and most site owners never see it.

You load your homepage, it looks fine, and you assume all is well. Under the bonnet, though, it’s a different story.

Your ‘Quiet’ Website Isn’t Quiet

The first clue was a single, stupid-looking URL in the access log. Then another. Then pages of them. Long, stitched-together paths like:

/events/category/sports/.../business/category/cafe/products/category/meat/...

None of these pages existed. I’d never built them, never linked to them, never even thought of them. Yet the server was being hit with hundreds of these things, seconds apart, from IPs scattered across the globe.

This is the bit most website owners never see.

Your website isn’t just being visited by humans. It’s being prodded, guessed at, and scraped constantly by automated scripts. Some are harmless-ish crawlers looking for generic directory structures. Others are lazy attack bots recycling URL patterns they’ve seen elsewhere, hoping your site happens to use the same /business/.../items-for-sale/... pattern as something they’ve already cracked.

The good news? If your site is configured sensibly, most of these attempts end in 404s and blocks. The bad news? They’re still burning server resources and cluttering your logs while you’re sat there thinking “no one really visits my site anyway.”

When ‘Helpful’ Platforms Start Hammering You

Just as I was getting my head around the random bots, another pattern jumped out: a flood of requests from something calling itself meta-externalagent. Thousands of them. Same domain, different IPv6 addresses, sometimes multiple hits per second. All pointed at my site, all logged in the middle of my quiet evening.

The timing wasn’t a coincidence. I’d added and verified the domain in Meta’s Business tools the day before. That simple, innocent step told Meta “this site is important to me, and I own it” and their crawler responded by doing what crawlers do best: aggressively mapping and analysing the content. In practice, that meant hammering various URLs, poking at WordPress’ admin-ajax.php, and generally behaving like a very enthusiastic robot with a caffeine obsession.

This is where things get messy for a normal site owner. On paper, these are “good” bots, Facebook, Instagram, and Meta’s various systems trying to fetch previews, check links, and (increasingly) feed their AI models. In reality, they can look suspiciously like an attack when you see them slamming the same endpoints tens of thousands of times. And if your security settings push back with 403s on certain paths, you end up in this odd situation where a big platform is both “trusted” and being told to clear off at the same time.

Errors Aren’t Always Disasters (But You Need to Read Them)

You don’t just need to read them, you need to understand them and know what to do about them.

Once you start digging into logs, it’s very easy to spiral. You see “error,” your brain hears “broken,” and before you know it you’re convincing yourself the whole site is on fire. In reality, a lot of what shows up is the server doing exactly what it’s supposed to do, or PHP complaining about code that still works but could be tidier.

A good example: the client denied by server configuration messages I found. On the surface, that sounds awful. In practice, it just means “a request hit this path and your server rules blocked it before WordPress even loaded.” In my case, a bunch of those were bots trying to access things like /business and /items-for-sale directly, and the server quite sensibly told them to get stuffed. No hack, no outage, just a gate doing its job.

Then there are PHP warnings and deprecated notices. They look dramatic in a log, but they sit several notches below a fatal error. One plugin was asking PHP for a bit of data that sometimes wasn’t there. Another was using an older way of tweaking the mailer that newer PHP versions now frown at. The site still ran. Emails still sent. Nothing exploded.

The sensible response wasn’t “rip everything out.” It was: update the plugins, then turn down the volume so production logs focus on real problems instead of endless grumbling.

The Fixes: Small, Boring, and They Actually Work

Once I’d stopped doom-scrolling through the logs, the actual fixes were surprisingly straightforward. I didn’t rewrite WordPress core or install twenty new plugins – I hate adding plugins unnecessarily. I did a handful of sensible, boring things.

I checked robots.txt and the sitemap in a normal browser, to make sure crawlers could see what they needed and nothing obvious was being blocked by accident. I added Wordfence (the free version does the job for this), switched on brute-force protection and rate limiting so login probes and over-eager bots would be throttled instead of allowed to hammer away all night. I let it scan the site, deleted a few suspicious “extra” core files that were clearly just timestamped copies someone had left lying around, and told it to include my custom uploads folder in future scans.

Then I updated the noisy plugins and tweaked wp-config.php so PHP would still log serious errors but stop shouting about every warning and deprecated quirk on a live site.

None of this took more than a couple of hours. None of it cost a penny beyond the time (and understanding what the heck was going on).

What This Means If You Own a ‘Small’ Website

The main thing I took away from all this is simple: being small doesn’t make you invisible to bots, scrapers and dick heads. Your website is on the open web, which means it will be poked, prodded, and crawled whether you have five visitors a day or five thousand. Ignoring that doesn’t make it go away. It just means you find out there’s a problem when something breaks or Google quietly loses trust in your website.

You don’t need to become a security engineer. But you do need a minimum baseline: one decent security plugin with login protection, a robots.txt that makes sense, plugins and core kept up to date, and someone who occasionally looks at the logs and knows the difference between “mild grumble” and “call for help now.”

What About Your Website?

If you’ve never looked at your access logs, never thought about error logs, and the “security” of your website begins and ends with “well, it loads,” you’re not alone. Most people don’t touch this stuff until something breaks.

If you’d rather not spend a late night squinting at logs and swearing at bots, there’s a coffee-fuelled local bloke (yes, that would be me) who actually finds this sort of thing interesting, and will happily dig through it for you, harden things up, and explain what’s going on in plain English.

For a price, of course. Nobody gets to have this much fun for free.

Your Website Security Questions, Answered