2,721 Requests, Zero Valid Page Requests
Three Months of Web Logs Revealed
You put up a website. It could be your company's landing page, a simple contact form, or a small online storefront. You check the analytics occasionally. Page views, bounce rates, time on site. The usual.
But there's another story hiding in your server logs. One that most people never see.
We launched our website in September; it is a simple informational site. Within three months, before the site had any real traffic to speak of, one visitor had already knocked on the door over 2,700 times. Every single request came back empty. Page not found. They weren't looking for content. They were looking for cracks.
The top visitor was an IPv6 address (2a06:98c0:3600[:]103) traced to a Cloudflare network, possibly located in London. In less than three months, this one address made 2,721 requests that appeared to be from Windows 10 hosts using six different versions of the Chrome Browser, and an iPhone 17 using Safari.
Here's what they were asking for: /wp-admin/setup-config.php, /wordpress/wp-admin/setup-config.php, /.git/config
If you're not familiar with these paths, here's what they mean. The WordPress setup pages are what you see when you first install WordPress, before you've set a password or configured the database. If someone finds that page exposed on your site, they can take over the entire installation. The .git/config file is even simpler: it's where developers sometimes accidentally expose credentials or source code when pushing files to a web server.
Our site doesn't run WordPress. It never has. But the scanner doesn't know that and doesn't care. It's checking everyone.
They weren't alone. We observed four other hosts that were slightly above the threshold. Four of the top five trace back to Microsoft Azure infrastructure. The second-place visitor was hunting for PHP files that don't exist on our server. The requests sought simple file names commonly associated with webshells and other malicious scripts. All of these addresses have neutral reputation scores. They're not flagged as malicious by most security tools. They're just active.
Why This Matters
None of this traffic hurt our site. Every request bounced harmlessly off a 404 page. No breach, no compromise, no headline. So why does it matter?
This traffic is automated rather than targeted. These scanners don't know who you are. They don't care what industry you're in or how big your company is. They're casting a wide net, checking thousands of sites an hour for common misconfigurations. They will know if you happen to have an exposed WordPress setup page, an open Git repository, or an outdated plugin with a known flaw. Not in weeks. In hours.
Most business owners never see this traffic. Many can't. If your site runs on a managed platform like Squarespace, Wix, or HubSpot, you don't have access to raw server logs. The platform handles everything behind the scenes, including quietly rejecting thousands of probes you'll never know about. That's not necessarily bad. It's just invisible.
But invisibility cuts both ways. If you can't see what's hitting your infrastructure, you can't learn from it. You can't spot patterns that indicate a more present threat. You can't ask the right questions.
For those who do have access to logs, whether you're self-hosting or using a provider that supplies raw data, the information is there. It's just waiting for someone to look.
Why This Matters
We've been building a small tool to help surface patterns and highlight unusual activity in web logs. Fair warning: this started as a weekend project fueled by curiosity and coffee. We're hunters, not developers.
The code works, even if held together with determination and AI-math. If you're expecting polished software, you'll be disappointed. If you're expecting something that helps you poke around your own logs and ask better questions, you might find it helpful. Note it only works if you have access to raw logs. If you're on a managed platform, this won't help your analysis.
It's on GitHub if you want to take a look, along with a couple of sample reports.
We're biased as Threat hunting is what we do but the principle isn't complicated. You can't respond to what you don't see, and you can't know what you don't look for. The threat is still there, whether you see the traffic or not.
You don't need a massive security team or an enterprise budget to start asking better questions about your own infrastructure. Sometimes it's as simple as opening a log file and looking for what doesn't belong.
The traffic doesn't stop. The only variable is whether anyone's paying attention.