25% of Requests to Our New Site Probed for Software and Files We Do Not Have
We logged 30,644 requests to a static site over 28 days. 7,567 of them asked for WordPress, .env files and PHP shells that have never existed here.
Put a server on the public internet and something will knock on it within the hour. Everyone knows this in the abstract. We had the chance to put a number on it: this site is new, unlinked, and static — no PHP, no database, no admin panel — so anything asking for those is unambiguously a probe.
Over 28 days this domain received 30,644 requests. 7,567 of them — about 25% — were for paths that have never existed here. Below is what they wanted, how often, and what a small site should actually do about it.
The short version
Of 30,644 requests over 28 days, 7,567 (25%) targeted software this static site does not run — 1,818 distinct paths from 382 addresses, about 270 a day. 61% arrived with no user agent. Nothing here needs a fix beyond keeping .env and .git out of the web root.
What we measured, and how
This is a static site: pre-rendered HTML files served by nginx. There is no PHP interpreter, no database, no CMS, no admin login. That turns the access log into a clean instrument — every request for a .php file is, by definition, someone probing for software that is not here.
We took every log line for this domain from 2026-07-19 to 2026-08-15 (28 days) — 30,644 requests — and kept the ones where nginx parsed a path and answered not-here (404, plus 403 and 410). From those we removed requests for paths the site does publish — a handful of articles were retired and still get followed: 126 requests. Malformed requests that nginx rejected with a 400 before any path was parsed are excluded too, and reported separately further down. What remains is 7,567 requests for things that never existed here.
Nothing here is a vulnerability report. We are publishing what arrived, not what worked — a static site has almost no attack surface for any of it, which is rather the point of showing it.
25% of all traffic was looking for software we do not run
7,567 of 30,644 requests — about 25% — went to paths that have never existed on this domain. That is roughly 270 per day, spread across 1,818 distinct paths from 382 addresses.
The largest single family was uploaded php shells: 3,934 requests across 814 paths.
This site has no inbound links to speak of and one page in Google's index. Nobody knows it exists. The scanning found it anyway, because scanning does not work by knowing — it works by walking address space and trying everything on everything.
What it was looking for
| What it was looking for | In plain terms | Requests | Distinct paths |
|---|---|---|---|
| Uploaded PHP shells | Filenames from earlier break-ins elsewhere | 3,934 | 814 |
| Everything else | Assorted one-off paths | 1,537 | 503 |
| WordPress | A CMS this site does not run | 1,084 | 219 |
| Secrets and config files | Leaked keys, tokens, repository internals | 861 | 244 |
| Admin panels | Database and server consoles | 67 | 8 |
| Remote code execution | Known RCE paths in web frameworks | 61 | 20 |
| Backups and dumps | Whole-site archives left in web roots | 23 | 10 |
Every request to this domain between 2026-07-19 and 2026-08-15 (28 days) that was answered 404, 403 or 410, excluding paths this site actually publishes. Classification is a fixed set of path patterns applied identically to every request; a path matches the first family it fits.
The most-requested things that are not here
| Requested path | Requests |
|---|---|
/wp-admin/install.php | 145 |
/wp-content/plugins/hellopress/wp_filemanager.php | 59 |
/this_is_a_new_hello_world.php | 57 |
/1.php | 44 |
/classwithtostring.php | 43 |
/222.php | 43 |
/.env | 40 |
/images.php | 36 |
/.git/config | 35 |
/media.php | 34 |
/admin.php | 34 |
/8.php | 34 |
/mac.php | 32 |
/BDKR28WP.php | 31 |
/mgrr.php | 30 |
The most-requested paths that do not exist here. None of this software runs on this domain — the site is static HTML behind nginx.
Two patterns are worth naming. The WordPress paths are the obvious ones — install scripts, login pages, plugin files — and they arrive whether or not you run WordPress, because guessing is cheaper than checking. The random-looking .php filenames are the more interesting group: those are the names of web shells uploaded during other people's breaches. Scanners try them everywhere on the chance that a host was compromised earlier and the back door is still sitting there.
Then there are the config files. Requests for .env and .git/config are not looking for a way in — they are looking for credentials someone committed by accident. That is a filesystem hygiene problem, not a web-server one, and it is the one item on this list that a static site can still get wrong.
Most of it does not even pretend to be a browser
4,630 of these requests (61%) arrived with no user agent at all. Others carried a user-agent string that was not a user agent — one of the most frequent was a URL, apparently copy-pasted into the wrong field of whatever tool was doing the scanning.
Separately, 3,044 requests were malformed badly enough that nginx answered 400 before any path was parsed — protocol noise, TLS probes, and requests aimed at whatever else might be listening on the port.
None of this is sophisticated, and that is the useful part of the finding. The background traffic of the public internet is not targeted attacks; it is a very large amount of very cheap guessing.
What this changes about running a small site
Do not read 404 counts as a problem with your site. Ours are dominated by software we have never installed. If you set up alerting on 404 rate, you will be alerting on the weather.
The static-site security argument is real, and this is what it looks like. Almost every request above needs an interpreter to be dangerous. There isn't one. That is not cleverness on our part — it is a consequence of the hosting choice, and it is available to anyone.
The exception is files, not code. .env, .git, and stray backups are readable by a static server as happily as any other file. Keeping them out of the web root is the one defence on this list that a static site still has to get right on purpose.
Look before you buy tooling. This measurement cost one log file and an afternoon. Whatever a WAF vendor tells you about your threat profile, your own access log has already recorded the answer.
The practical conclusion is smaller than the numbers suggest. A quarter of our traffic is looking for a way in and almost none of it has any effect, because there is nothing on the other side to execute it. If you are choosing between a static site and a CMS for a small project, this is the security half of that trade-off made concrete.
The part that does deserve attention is the file-based probing. Nobody is going to break into a folder of HTML, but a stray .env in the web root is readable by anyone who asks — and, as the table above shows, they ask constantly.
FAQ
Is any of this dangerous to a static site?
Almost none of it. Requests for PHP files, admin panels and RCE paths need code execution to matter, and a static server has none. The exception is requests for files — .env, .git, backups — which a static server will serve happily if they are in the web root. Keep them out of it.
Why is a site nobody knows about being scanned at all?
Scanners do not work from a list of known sites. They walk IP ranges and certificate transparency logs and try common paths on whatever answers. Obscurity is not a filter — being reachable is the only qualification.
Should I block these requests?
Blocking costs effort and buys little when the requests already return 404 instantly. Rate-limiting is worth it if the volume affects your logs or bandwidth. The higher-value work is making sure nothing sensitive is reachable in the first place.
Do these numbers apply to my site?
The composition probably does; the volume depends on your host and address range. The measurement is three lines of log parsing, so check rather than assume — that is the whole argument of this article.