The sentence comes up in almost every second first conversation, usually friendly and without defiance. We are two people in a small Swiss town. We sell nothing online. We are not a target, there is nothing here worth taking.
The sentence is true. Nobody is out to get you.
And that is exactly why you get found.
What we measured
On our own sites and those of our clients we record what the server actually sees, before the cookie banner and before JavaScript. Eleven hosts, 30 days, from 11 August to 10 September 2026, 751,386 requests in total.
The split looks different from what most people expect.
| Who is requesting | Requests | Share |
|---|---|---|
| Humans | 269,524 | 36 % |
| Scanners looking for weaknesses | 263,067 | 35 % |
| Tools and services | 142,513 | 19 % |
| AI crawlers | 17,290 | 2.3 % |
| Search bots | 7,976 | 1.1 % |
A good third of all traffic is programs hunting for weaknesses. More than AI crawlers and search engines combined, by a factor of fifteen.
The part that contradicts the feeling
The average is not the interesting number. The spread is.
| Site | Scanners | Humans | Ratio |
|---|---|---|---|
| Local IT service | 46,593 | 1,851 | 25 to 1 |
| Personal site of a freelancer | 29,359 | 1,464 | 20 to 1 |
| Online CV | 17,460 | 1,568 | 11 to 1 |
| Our own company site | 80,929 | 24,526 | 3 to 1 |
The smaller and quieter the site, the more clearly the automated requests dominate. On the smallest of these, twenty-five of them arrive per human.
This is not an attack on those sites. It is the background level. Being known does not protect you, and being unknown protects you even less: it merely removes the humans from the denominator who would have made the ratio look friendlier.
What is being looked for
One of our sites sits behind a web application firewall that logs every request. 30 days, to 11 September 2026. The site is a serverless application and does not run on WordPress.
Even so:
- Around 1,900 requests for WordPress paths.
/wp-admin/install.phpalone was requested 776 times. That is the installation page, which only answers on a freshly deployed, not yet configured installation. Whoever catches it takes over the site in a minute. - 426 requests for environment files, in five spellings:
.env,.env.local,.env.backup,.env.old,.env.production. A site that serves such a file usually serves credentials with it. - 237 requests for Git metadata,
/.git/configand/.git/HEAD. Under some conditions that allows the entire source code to be reconstructed.
The WordPress part is the instructive one. The site has no WordPress, never had, and is still asked 776 times for its installation page. These programs do not check first whether the attempt is worth it. An attempt costs a few milliseconds, checking costs more.
Why the feeling persists anyway
Because nothing happens. The requests sit in the log, not in your inbox. Nobody writes to tell you they just asked for your .env. The counter in the browser never shows them, because these programs run no JavaScript and never appear in Google Analytics.
Anyone looking only at analytics sees half the humans and none of these requests. The picture is not wrong, it is incomplete, and the missing half is exactly the one this is about.
What follows from it
Not panic. Most of these requests run into nothing, and that is the normal case.
The useful question is not whether anyone knocks. That is measured and answered. The question is what happens when a door opens.
There are two answers to that, and they differ fundamentally.
One is maintenance. Apply updates promptly, remove plugins instead of deactivating them, limit login attempts, test your backups. That works for as long as someone does it, every week, including in summer and including when something more important comes up.
The other is not having the doors being probed for in the first place. A statically delivered site with no running server, no database and no admin login behind it knows neither /wp-admin/install.php nor .env. The sweep continues, it simply no longer finds what it is looking for. This variant needs no discipline, because there is nothing to maintain.
We build the second variant, not because maintenance is wrong, but because it depends on a person who eventually goes on holiday.
What else is in the same logs
The same recording answers a second question, one asked more often lately than the one about security: are the AI systems reaching my site?
Across the same eleven hosts in the same window there were 17,290 verified requests from AI crawlers, against 7,976 from classic search bots. The answer engines now come more than twice as often as Google and Bing. That too appears in no browser counter.
One log file, two answers. That is the actual reason we measure server-side.
How to look for yourself
You do not need a service provider for this. If you can reach your access logs, search for three strings:
/wp-admin
/.env
/.git/configIf the counts run into the hundreds and your site does not even know those paths, you are looking at the background level. After that you know that people knock, and the question shifts to what sits behind the door.
If you cannot reach the logs, that is a finding in itself.
Frequently asked questions
Do small company websites even get attacked?
Yes, and measured by request volume, harder than large ones. Across eleven sites, 35 percent of all requests come from programs looking for weaknesses. On a small site with a few dozen visitors a day, twenty to twenty-five such requests arrive per human one. The reason is that nobody is aiming at you specifically: address ranges are worked through wholesale, and a small site is not a smaller target, just one address among many.
What are those automated requests looking for?
Known open doors. In 30 days on one of our sites: around 1,900 requests for WordPress paths, 776 of them for /wp-admin/install.php alone, plus 426 requests for environment files in five spellings from .env to .env.production and 237 for Git metadata. The site does not run on WordPress and never has. It gets probed anyway, because trying is cheaper than checking.
What helps besides patching continuously?
Removing the door instead of locking it. A site with no running server, no database and no admin login behind it does not have the paths being probed, so the sweep finds nothing. Maintenance keeps doors shut for as long as someone maintains them. An architecture without those doors does not need that discipline.
Sources
- Own measurement across eleven hosts, Munot daily cubes, 11 August to 10 September 2026
- Own measurement, WAF logs of scmc.ch, 30 days to 11 September 2026, CloudWatch Logs Insights
- Related terms: Scanner, AI crawler, Verified crawl