Is Your Website Under Bot Attack? What Our Edge Saw on a Small Plumbing Site in Five Days

01 / 07

How much of a website's traffic is bots?

More than half of all internet traffic. The 2026 Thales Bad Bot Report, covering 2025, puts bots at 53% of internet traffic, humans at 47% and bad bots at 40% (Thales, 2026). A small business site is not too small to be in that 40% (Thales, 2026). Bots do not choose targets by size. They work through lists.

This is the fourth guide in our series on hacked websites. The first three covered hidden malware, the signs of a hack and what cleanups miss. Most of those hacks started with automated traffic, so this one looks at the bots themselves, using numbers from a real small business site.

The headline figures come from Thales, which publishes an annual bad bot report. Its 2026 edition, based on full-year 2025 activity, says bots make up 53% of internet traffic and bad bots 40% (Thales, 2026). We read those figures from the report's public page; the full report sits behind a form.

Those are global averages. What matters to an owner is what actually reaches their own site, so here is one site's data.

02 / 07

What hit a small plumbing company's website in its first five days?

From the evening of August 15 to the end of August 20, 2026, the site logged 3,412 trap hits from 1,450 different addresses, and 470 of those addresses were blocked. Our edge made 17,443 decisions about requests in the same window, 8,925 of them blocks or challenges (First-party edge data, 2026).

The site belongs to the plumbing company from our cleanup guide. Its old WordPress site had been hacked repeatedly. We rebuilt it as a static site on Cloudflare and put our edge in front of it, with traps: addresses no real visitor would ever request, such as a WordPress login page on a site that no longer runs WordPress.

Two honest caveats. First, our logs counted hard blocks and challenges together in that 8,925, so it is not a count of blocks alone. Second, there is no "before" to compare with: in the days before launch, 747 of the 1,182 trap hits came from our own connection while we tested. These numbers show what arrived, not how much it grew.

The trap mix shows what the bots were after: 1,588 hits on the WordPress login, 672 on old blog addresses, 512 on the WordPress API, 256 on the old spam pages, 163 hunting configuration files, 39 probing known plugin weaknesses, 27 testing upload folders and 12 looking for web shells.

03 / 07

What were the bots actually looking for?

Ways in. Login guessing, which OWASP defines as "mass log in attempts used to verify the validity of stolen username/password pairs" (OWASP, 2026), was the biggest group. Next came scanners hunting known plugin weaknesses and leaked configuration files. Across the sites we protect, the most-tripped traps were requests for .env and .git/config files.

OWASP, the open web security project, keeps a list of automated threats. Two of them describe most of what the plumbing site saw. Credential stuffing is "mass log in attempts used to verify the validity of stolen username/password pairs" (OWASP, 2026). Vulnerability scanning is "crawl and fuzz application to identify weaknesses and possible vulnerabilities" (OWASP vulnerability scanning, 2026).

The login requests are the clearest example. Of the 1,588 requests for the WordPress login page, 1,504 just loaded it and 84 tried to sign in. They came from 920 different addresses. The site had no WordPress login to find; the requests reached a decoy. On the old WordPress site, every one of them would have reached a real login form.

Configuration files are the other big target. A .env file often holds database passwords and API keys, and a .git folder can hold a site's entire code history. Across all the sites we protect, as of August 18, 2026, the most-tripped traps were requests for .env (1,150) and .git/config (811) out of 4,602 trap hits (First-party edge data, 2026). Those are network-wide figures, not the plumbing site's alone.

04 / 07

Did the old spammers come back?

Something did. Between August 17 and 19, 18 requests from 18 different addresses, one each, from a script rather than a browser, checked only a handful of the old casino spam pages. All 18 were blocked. In the same window, 137 hits on those spam pages were real Googlebot, recrawling addresses it remembered.

After a hack, the spam pages live on in other people's systems: the attacker's list, and Google's memory. Both came back to check.

The 18 requests stood out because of their shape. Each came from a different address, each made exactly one request, each used the same Node.js script rather than a browser, and each asked only for the spammer's own old pages. That is someone checking whether their pages were still up. We cannot prove it was the same group that hacked the site, and we do not claim it.

Googlebot, meanwhile, made 137 requests for those same spam addresses and got told the pages were gone. That is what you want: the spam pages answered as gone, so Google drops them, and the real pages answered normally.

One more pattern: a single path used by a known WordPress backdoor was requested by 9 different hosts over the five days. That is a toolkit checking many sites for a door that might have been left open. We never had the old server's logs, so we do not claim that backdoor was ever on this site.

05 / 07

Why can't you just block bots by their IP address?

Because many bots now use home and mobile internet connections, the same ones real customers use. On a health clinic's website, 108 of 142 blocked visitors came from residential or mobile addresses, spread across 82 different network ranges, and one single bot fingerprint showed up from 44 different addresses (First-party edge data, 2026).

Blocking by address worked when bots ran from a few data centers. It works far less well now. The clinic's calculator page was being hammered by a bot, and when we looked at who we had blocked, most were on the same kinds of connections as real patients.

Blocking those address ranges outright would have locked out real people. Following the bot's behavior instead, how it moved through the page and what it requested, caught it across all 44 addresses it used. The lesson we took from it: track the bot's identity, not its address.

That is also why a list of "bad IPs" from a public database is a weak defense on its own. When we measured it in July 2026, 54.1% of one day's recorded threat events on our own systems were imports from a public abuse database rather than attacks we saw ourselves (First-party edge data, 2026). We now count those separately.

06 / 07

How do you block bots without blocking Google?

Carefully, and by testing. We got this wrong ourselves. In the 30 days to July 15, 2026, our edge was blocking or challenging 640 of 683 visits from Google's networks that did not identify as Googlebot, 94%, including a Google service that loads pages for real Chrome users (First-party edge data, 2026). Real Googlebot was almost never blocked; the other Google crawlers were.

Google runs more than one crawler. Googlebot indexes pages, but other Google systems check ads, preview links and preload pages for Chrome users. Our rules let Googlebot through: of 1,253 real Googlebot visits in that period, 1 was blocked. But they blocked or challenged most of Google's other traffic, including all 516 requests from the Chrome prefetch service. Meanwhile, 182 of 205 bots pretending to be Googlebot were correctly blocked.

It mattered. A pool company we work with had Google Ads flag its site as compromised. When we traced it, our own edge was challenging Google's ad-checking traffic. That kind of mismatch, where Google sees something different from a normal visitor, looks like a classic hacked-site pattern from Google's side. After we fixed the rules, both ad flags cleared by September 25, 2026. Google never confirmed the cause, so we describe it as the most likely one, not a proven one.

The fix is to treat Google's crawlers as their own class, verify them properly and test any bot rule against them before it goes live. Any bot protection you add should be tested the same way.

07 / 07

What should a small business do about bot attacks?

Put the site behind a proxy such as Cloudflare, turn on its free bot protection and remove the things bots are looking for: an exposed login, old plugins, stray config files. A static site removes most of them at once. For managed rules on top, an edge layer such as RankShield's can help, as long as it is tested against Google.

Start with what is free. Cloudflare describes Bot Fight Mode as "a simple, free product that helps detect and mitigate bot traffic on your domain" (Cloudflare Bot Fight Mode docs, 2026). Know its limits before you switch it on: Cloudflare says it "may challenge API or mobile app traffic", and "you cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules". If your site has an app or connected services, test them after turning it on.

Then remove the targets. Every one of the 1,588 login requests on the plumbing site would have found a real login form on its old WordPress site. On the static rebuild there was no PHP, no database and no login, so nothing the bots asked for existed. Our guide to static sites on Cloudflare Pages explains that trade-off, and our comparison of website builders covers what each platform protects for you.

For more than the free tier, RankShield, our founder's security company, runs an edge layer that RankShield describes as "a managed filtering layer on Cloudflare's global network that sits in front of your whole site". It is $39 a month, added on top of a RankShield plan, and it is the layer that produced the data in this guide. Details are on the RankShield edge page. It is an option we offer, never a condition of working with us.

Whatever you use, test it against Google before you trust it. Our own mistake above is the reason.