How much traffic hits an unlaunched website? We checked
Our website has been up for 25 days. In that time it's been shared with exactly one person — and it served roughly 14,000 requests. Before you conclude we're famous: not one of those requests was a stranger reading anything. Here's how we proved that without any analytics installed, why it mattered for a launch decision, how we then picked an analytics tool for $0 with no cookie banner — and the configuration trap we found that was quietly reporting the wrong numbers the whole time.
Reading traffic when you have no analytics
We never installed analytics on the new site — pre-launch, it wasn't a priority. But a launch-prep question forced the issue: has anyone actually found this thing? The answer had to come from somewhere, and it turns out most hosting platforms will tell you, roughly, for free.
Ours runs on Azure App Service, which records a raw request count automatically (about three months of history, no setup). The daily curve told the whole story:
- A flat baseline of 400–650 requests/day. That is the internet's ambient noise: vulnerability scanners probing for WordPress logins, search crawlers, uptime checkers, certificate-transparency followers. Every public site collects this from day one. It means nothing.
- Spikes only on days we touched the site — 2,475 requests on deploy day, ~1,200 on two working days, 1,152 the day we published a blog post and verified it repeatedly ourselves.
The interpretive key: one human page view generates 10–40 requests once styles, scripts, and images load. Real readership shows up as sustained bumps above the bot floor — dozens of visits would be visibly obvious. Our curve had none. Flat baseline plus self-inflicted spikes equals nobody's here — a heuristic that works on any host that counts requests.
What we did with the answer
We'd been weighing whether to replace two blog posts before launch — one that published wrong benchmark numbers, and the follow-up that corrected them publicly. With a verified audience of approximately zero, a clean slate would have cost nothing. We kept both anyway: for a firm selling AI governance, a demonstrated error-correction loop is worth more than a spotless-looking archive. The traffic data didn't make that decision, but it made it an informed one instead of a guess.
Picking analytics: what $0 actually buys
Flying blind stops being acceptable at launch, so we surveyed the field — and verified every price and limit on the vendors' live pages, because pricing blogs are reliably stale. The short version:
| Option | Cost | The catch |
|---|---|---|
| Cloudflare Web Analytics | $0 | No campaign/UTM tracking, ~6 months of history |
| Plausible | $9/mo | Recurring cost from day one; 30-day trial, no card |
| Fathom | $15/mo | 7-day trial requires a card and auto-bills |
| GoatCounter | $0 | One-maintainer project, deliberately spartan |
| Umami (self-host) | ~$12/mo | Needs a Postgres database — the DB costs more than the app |
| Google Analytics 4 | "$0" | Mandatory EU consent banner, and its data thresholds hide low-traffic rows — worst fit for a small site |
We chose the Cloudflare beacon: free with no paid tier, one script tag, cookieless — which means no consent banner, because there's nothing to consent to. The limits we accepted are real (no UTM attribution, limited history), so we wrote down the upgrade trigger the day we shipped it: when launch marketing needs campaign attribution, trial Plausible. Deciding the revisit condition up front beats re-litigating the choice every quarter.
The trap: analytics that measured the wrong thing
Here's the part that earns this post its keep. When we went to set up Cloudflare Web Analytics, we discovered a site entry already existed — auto-created weeks earlier when the domain was added, in "Automatic setup" mode, dutifully showing page views and visits.
Those numbers were fiction — or rather, they were true numbers about the wrong thing. Automatic setup injects the measurement script only on traffic that passes through Cloudflare's proxy. Our website doesn't (a certificate constraint keeps it DNS-only); the only proxied hostnames on the domain are internal tools. So the dashboard was reporting our own Grafana usage as "website analytics" while the actual website had zero coverage. A dashboard that's almost configured is worse than no dashboard: it answers confidently, and wrongly.
Two lessons from digging out:
- Verify what your analytics actually measures. One deliberate page view, then check it appears — and check where it came from. We only caught the proxied-vs-direct split because the numbers couldn't be reconciled with the request-count baseline from earlier.
- Know your tool's management path before you script it. We burned real time trying to automate the setup with a scoped API token before verifying that this product has no API token permission at all — it's dashboard-only. Ten minutes of checking the permissions reference would have saved thirty of token surgery.
The fix took one settings change (manual-snippet mode, which also stopped the internal tools polluting the counts) and one script tag in the site layout. Total spend: $0. Total cookies: zero. The first visit on the clean dashboard was, fittingly, our own.
The honest scorecard
Request-count forensics is a blunt instrument — it bounds human traffic, it doesn't measure it. Beacon-based analytics undercounts ad-blocker users, and always will. And our "verified pricing" table is verified as of this week; vendors change tiers, which is exactly why we checked their live pages instead of trusting a comparison post — including this one. Check ours too.
Launching something and want the visibility question sorted?
Whether it's picking privacy-respecting analytics, reading the traffic you already have, or deciding what your stack should cost before revenue shows up — this is the kind of question we work through in a free 45-minute AI Opportunity Briefing. Bring your launch checklist; we'll bring the baselines.