Bot Traffic Now Outnumbers Your Customers, and It Is Not Free

I will start with the part that sounds like scaremongering, because it is not. It is just what the traffic logs say. On a normal week, most of the visitors your website records are not people.

During this morning's operations review I pulled the request numbers across the sites we run, and the split was close to what it has been all year: a little over half machine, a little under half human. That is not a sign your site has been singled out. It is the ordinary weather of the web in 2026, and it has quietly become the majority.

Imperva, in its 2025 Bad Bot Report, put automated traffic at roughly 51% of everything online, the first time in about a decade that machines outnumbered people ^[1]. Cloudflare, looking at its own vast slice of the internet, put bots closer to 57% of requests ^[2]. Somewhere between half and three in five, then. The two numbers disagree because they measure different networks in different ways, which is worth remembering every time someone quotes you a single tidy percentage. Call it "most" and move on.

None of this would matter if bots just looked and left. They do not. They consume your server's resources, they distort the numbers you make decisions on, and a real share of them are actively testing your site for a way in. On a small business website, each of those three costs you something you can measure.

Half the Web Is Machines Now

A bot is simply software that visits websites with no person driving it. Some of it is essential. A good chunk is useful but greedy. And some of it is hostile. Treating all of it as one lump called "traffic" is the mistake that leads owners astray.

The essential category is the one you actually want. Search engine crawlers, uptime monitors, the services that make the web work. Cloudflare found that Googlebot alone accounted for more than a quarter of all verified bot activity, and close to 5% of every HTML request it saw ^[2]. That is traffic you depend on. Block it by accident and you fall out of Google, which for most small businesses is much the same as locking your own front door.

Then there is a newer, greyer category that has grown fast: AI crawlers gathering text to train and feed large language models. Cloudflare measured their share of requests swinging between roughly 2% and 6% across last year, and found that the great majority of AI crawling was training-related rather than answering a live question ^[2]. Whether you want those bots reading your site is a genuine business decision, not really a security one.

The last category is the one with bad intent. Imperva put bad bots specifically at around 37% of all traffic, up from about a third the year before ^[1]. These are not browsing. They are working: scraping your content, testing stolen passwords, and hunting for a known weakness to exploit.

The practical upshot is plain. The visitor count in your analytics is a blend of customers, Google, robots feeding an AI, and software looking for an unlocked door. Read that single figure as "demand" and you will talk yourself into decisions the real data would never support.

What the Bad Ones Actually Do to a Small Site

The tempting assumption is that this is an enterprise problem. Big brand, big target. In operations we see the opposite pattern more often. Small sites get hit precisely because they are small: little maintenance, predictable software, nobody watching the logs. Automated tools do not pick targets the way a human would. They scan millions of addresses for the same fingerprints, a login page at the usual address, an exposed version number, a known-vulnerable plugin, and they knock on every door that matches.

First, they eat your capacity. Every bot request is work your server has to do, even when the answer is "no". On a properly resourced platform you never notice. On an oversold shared server, where hundreds of sites compete for the same processor, a burst of aggressive scraping arrives at the worst possible moment and your pages slow to a crawl for the actual customer trying to read your opening hours. The bot does not care about the delay. Your customer, already half-deciding to try somewhere else, very much does.

Second, they attack. The most constant form of hostile traffic on any WordPress site is the automated assault on the login page: thousands of guessed passwords a day, run by software that never tires. Wordfence, which runs a firewall across millions of WordPress sites, reports blocking billions of these brute-force attempts every month across its network, and notes the volumes have climbed as attackers wire AI into the process ^[3]. I have written before about the automated attacks constantly hitting your login page. The short version is that it is happening to your site right now, whether or not anything has broken yet.

Third, they lie to you. Spam bots fill contact forms, newsletter signups, and booking enquiries with junk, and each one lands in your inbox or your database looking exactly like a lead. We see this pattern more than you would expect. Take a veterinary practice in Cavan that adds online appointment booking and spends a fortnight sure that business is booming, until someone notices the new bookings are nonsense names on disposable email addresses and the phone has gone quiet. The traffic was up. The customers were not. Sifting the real enquiries out of the noise cost staff hours during the exact week the new system was meant to give time back.

Why Cheap Shared Hosting Loses This Fight

You might reasonably expect your host to handle all of this for you. The good ones do. A large part of the hosting market simply is not built to.

On budget shared hosting the economics only work by packing as many sites onto a server as possible. Security tends to be one generic firewall rule set and a hope. There is rarely anyone watching traffic patterns as they happen, and rate limiting, the practice of throttling a source that is hammering your site, is often not tuned to your site at all. So you become the monitoring system. You discover you have a bot problem when the site falls over or the fake bookings pile up, which is the most expensive possible moment to find out.

I will be straight about where this does not matter much. If you run a small brochure site, a few pages, no customer logins, no bookings, no payments, sitting on very little traffic, the bot noise is genuinely just noise. The default protections on a basic host will soak it up and you will never feel the difference, and paying for managed infrastructure to fend off bots you cannot perceive would be a waste of your money. The sum changes the moment your website starts doing something: taking bookings, holding logins, processing payments, storing customer records. Then automated traffic stops being background hum and turns into a business risk.

What Actually Keeps the Bad Traffic Out

A platform that handles this well does a short, unglamorous list of things, consistently.

It bans repeat offenders automatically. When one source fails to log in fifty times in a minute, it should be rate limited or blocked without anyone lifting a finger, and it should stay blocked. It hardens the obvious targets, so the login page, the API, and the fingerprints bots hunt for are defended at the server level rather than left to a plugin. It keeps the good bots and drops the bad ones, so Google still crawls you while the credential-stuffer does not. It scans for the malware a successful attack leaves behind, because planting something is usually the whole point of those login attempts. And there is an operations team watching, so a shift in traffic pattern is noticed by a person rather than merely logged for you to find later.

That is the standard we build to. Web60 runs server-level security hardening and fail2ban, which does exactly that automatic ban-the-repeat-offender job, across every site on the platform, with automatic malware scanning behind it and a real Irish operations team watching the infrastructure instead of a ticket queue waiting for you to report a fire. It all runs on enterprise-grade infrastructure that absorbs this traffic before it reaches your site, on sovereign Irish cloud, for a flat sixty euro a year with the security included as standard rather than sold back to you later as an add-on. If the honest answer from your current host is a shrug, that gap is worth a look. For the wider picture of how these parts fit together, we keep a complete guide to WordPress security and backups that goes well beyond bot traffic alone.

In plain terms, this is the difference between your customer finishing a booking on a fast page, and abandoning it on a slow one because a scraper on a neighbouring site is eating the server. Boring infrastructure. Boring is the entire goal.

The Honest Limits of Blocking Bots

I would not trust anyone who tells you they block every bad bot and nothing else. That is not how it works, and pretending otherwise is how you get burned.

No filter is perfect. Push bot blocking too hard and you start catching real people, because customers on shared office connections, mobile networks, and VPNs can briefly look like one suspicious source. We learned that the careful way early on. A rate-limit rule we had tuned a shade too tight locked out a whole office, a legitimate customer whose entire team shares a single external address, all trying to log in at the same moment. Nobody was attacking anything. We loosened the rule and added a verification step before it triggers. The lesson held: security that blocks your own customers is not security, it is a slower kind of downtime.

There is a second limit worth knowing. The robots.txt file, the standard way a site asks crawlers to stay out of certain areas, is a request, not a wall. Well-behaved bots like Googlebot honour it. The hostile ones read it as a map of where you did not want them looking, and go straight there. So robots.txt is useful for managing good bots and close to useless against bad ones. Do not mistake it for a defence.

And the specifics depend entirely on your provider. Rate limiting, automatic banning, and server-level hardening only protect you if your host actually runs them, and on many plans they are off by default or not offered at all. It is a fair question to put to any host directly: what happens, automatically, when one source starts hammering a page on my site? If the answer is vague, that is your answer.

The Number That Matters

Go back to the traffic figure you started the month feeling good about. It is not fake, exactly. It is mixed. Some of it is customers. Google makes up a slice, doing its job. Another slice is software feeding an AI. And some of it is quietly trying the handle on your login page to see if it turns.

The point is not to panic about any of that. Most of it is handled, out of sight, by infrastructure you never think about, provided you are on infrastructure that bothers to. The point is to stop reading one visitor number as though it were a queue of customers at the door, and to know which kinds of traffic your setup actually keeps out. Put the direct question to your host. If you take bookings, logins, or payments, the answer matters more than the monthly price.

You do not need to become a security expert to run a website in 2026. You do need to know that the web filled up with machines while you were busy running your business, and to make sure the ones with bad intent are somebody's job to stop. Ideally somebody who is already awake when they arrive.

Frequently Asked Questions

Is most of my website traffic really bots?

Across the web as a whole, yes. Independent measurements from Imperva and Cloudflare put automated traffic somewhere between roughly half and just under 60% of all activity in 2025. Your own site will vary. A busy, well-known shop may see a higher share of real humans, while a small, quiet site can be dominated by crawlers and scanners simply because bots visit everything and your human audience is still growing.

Do bots hurt my Google rankings?

Some do, indirectly. Good bots like Googlebot are how you get ranked in the first place, so you never want to block those. Bad bots hurt you sideways: by slowing your site during traffic bursts, which affects the page experience Google measures, and by attacking your site until something breaks. The traffic itself is not a manual penalty, but its side effects reach your rankings.

How can I tell if my visitors are bots or real people?

Watch for the tells. A sudden spike in visits with almost no time on page, no scrolling, and no enquiries or sales is a classic bot signature. Contact forms filling with gibberish or disposable email addresses is another. Your server logs and a good analytics tool can separate much of it, and a managed host will usually filter the worst offenders before they ever reach your stats.

Can I just block every bot?

No, and you would not want to. Blocking all bots means blocking Googlebot, which removes you from search results. Aggressive blanket rules also catch real customers who happen to share an office network or use a VPN. The goal is selective: keep the useful bots, turn away the hostile ones, and avoid catching people in the process.

Are AI crawlers like GPTBot a security threat?

Not usually. Most AI crawlers are gathering text to train language models, not attacking your site, so the question is commercial rather than technical: do you want your content used that way? Well-behaved AI crawlers honour a robots.txt instruction to stay out. The genuinely dangerous automated traffic is the scanning and password-guessing kind, which ignores robots.txt entirely.

What can a small business do about bad bots on a tight budget?

Start with your hosting. The most cost-effective defence is a host that runs server-level rate limiting, automatic banning of repeat offenders, and malware scanning as standard, so you are not paying extra or maintaining it yourself. Keep WordPress and its plugins updated so the fingerprints bots hunt for are not there to find, and treat any security plugin as a supplement to that, never the whole plan.

Sources