Why My Blog Suddenly Had 70,000 Daily "Visitors"

Cloudflare suddenly reported more than 70,000 daily visitors on my small programming blog. The graph was exciting for about five seconds, then suspicious.

Cloudflare analytics recently gave me a tiny emotional roller coaster.

First thought: "Wait, did one of my posts finally escape into the wild?"

Second thought: "Why does this traffic look like it was scheduled?"

My blog usually sits around 7,000 daily unique visitors, and a fair chunk of that is already bot traffic. Then, over two days, Cloudflare started reporting more than 70,000 unique visitors per day. The hourly numbers were strangely flat, around 3,600 per hour.

That shape mattered more than the total. Big numbers are exciting. Flat numbers usually have something to say.

The pattern that gave it away

The suspicious part was not only the volume. It was how neatly the traffic behaved.

• The jump happened almost instantly instead of building gradually.
• The hourly traffic stayed unusually even.
• Requests and bandwidth moved in a very steady, repeatable pattern.
• Threat detections spiked only occasionally, so much of the traffic still looked valid enough to pass normal filtering.

Real human traffic is messy. It follows time zones, work hours, social links, search spikes, and random attention. It does not usually wake up one night and continue in a straight line.

Once I looked at the graph as a shape instead of a number, the likely explanation became much less glamorous: this was almost certainly automated crawling.

The detail panels made that feeling stronger. They did not show a normal reader profile slowly growing around a few popular articles. They showed a mostly HTML-heavy crawl, a strange client mix, and traffic spread across places that made more sense for infrastructure than for a sudden fan club.

First, the client HTTP version breakdown was very lopsided:

That does not prove anything on its own, but it is another little clue. Modern browsers happily use HTTP/2 or HTTP/3 when they can. A wave dominated by HTTP/1.1 feels more like automated clients, libraries, proxies, or mixed crawler infrastructure.

The content type breakdown was even clearer:

More than 90% of requests were HTML. That is not how a normal browser session feels on a web page with CSS, JavaScript, icons, images, and follow-up navigation. It is exactly what I would expect from something that mostly wants page text.

The top source IPs also showed repeated request volume from individual addresses, but not enough to explain the whole wave by themselves:

That mix points toward distributed activity. Some IPs are clearly busy, but the traffic is not coming from one loud address that can be blamed and blocked with a dramatic flourish.

The operating system view was also odd:

A huge MacOSX share can be real in some audiences, but combined with the other signals it looks more like user-agent shaping than a real room full of Mac users suddenly deciding this blog was the place to be.

The country breakdown had the same feeling:

The spread is not impossible for real traffic, but it fits crawler infrastructure nicely. The United States, Singapore, France, and the Netherlands are all common places to see cloud, proxy, and hosting traffic. Vietnam also makes sense as normal local audience mixed into the noise.

The crawler-specific view had the same energy: AI crawlers were having a very busy day. Meta's external agent alone transferred 135.6 MB across 8.41k allowed requests, with Amazonbot and ClaudeBot also making thousands of allowed requests. That is not enormous internet-wide, but for a small static blog it is a lot of quiet page fetching.

Several entries transferred only a few kilobytes, and some registered no traffic at all, so this was not one single AI bot explaining the whole spike. The important part was the pattern: many automated systems were active on the same day, and the heaviest ones were exactly the kind that want clean HTML text.

Why it did not look like real users

If a real audience surge caused the spike, I would expect at least a few human-looking clues:

• Referral spikes from search, social media, or a forum thread.
• Uneven traffic by hour.
• More variation in browsing depth.
• A few hot pages pulling most of the load.

Instead, the traffic looked rate-controlled. Something appeared to be fetching pages at a fixed pace, with occasional bursts layered on top. That fits crawlers, scrapers, or distributed ingestion jobs much better than people reading blog posts during lunch.

Another important detail: Cloudflare's unique visitor metric does not mean "humans who enjoyed my writing". If bots rotate IPs aggressively, the unique count can grow very quickly while the behavior is still fully automated.

The most likely explanation

The simplest explanation is still the best one: a crawler, or several crawlers, found the site and started sweeping it.

These were the most plausible possibilities:

1. Large-scale bot crawling from search, SEO, or AI-related systems.
2. Content scraping from systems that mirror programming content.
3. Multiple independent crawlers overlapping and re-fetching the same pages.
4. Light probing or scanning mixed into otherwise ordinary scraping traffic.

The site is a good crawler target. It is public, static, easy to parse, and full of structured technical content with headings, code blocks, and predictable URLs. If a system wants clean text without doing much JavaScript work, a site like this is convenient.

Why a 100-page blog can still generate hundreds of thousands of requests

This was the part that made me pause.

My site has roughly 100 pages. A well-behaved crawler should be able to fetch the whole thing in a few hundred requests, maybe a little more if it revisits some pages. Instead, the request count had climbed into the hundreds of thousands.

That only makes sense if the crawlers are not treating each article as one stable URL.

The biggest multiplier is query-string abuse. A page such as /post-1 can quickly turn into a long list of distinct URLs from the crawler's point of view:

/post-1?t=1
/post-1?t=2
/post-1?t=3

If the cache key treats those as separate requests, a small site suddenly becomes a huge URL space. Add multiple crawlers, retries, distributed IPs, and weak deduplication, and the numbers stop looking so mysterious.

The blog was still small. The request space was not.

What actually mattered

The good news: this did not look like a destructive attack.

The more practical risk was cache bypass. If bots keep requesting HTML pages with different query strings and those variations miss cache, the crawler traffic stops being cheap CDN noise and starts creating unnecessary origin work.

That shifted the question from "Who are these visitors?" to "How do I make this traffic boring?"

For a static blog, boring is the goal.

How I would verify the diagnosis

If you see a similar spike on a static site, I would start with these checks in Cloudflare:

1. Bot and human breakdown, if your plan exposes that data.
2. Top countries and ASNs, especially data-center-heavy patterns.
3. Top user agents, including empty or obviously synthetic ones.
4. Whether the same paths keep appearing with many query-string variants.
5. Cache hit ratio for HTML traffic.
6. Whether one page is genuinely hot or the whole site is being crawled evenly.

The cleanest confirmation would be request logs showing repeated fetches of the same paths with changing query strings. At that point, the mystery is mostly over. You are probably not watching a viral moment. You are watching automated traffic manufacture new URLs faster than the site deserves.

What I took away from it

The weirdest part of this episode was how flattering the graph looked before it looked suspicious.

A sudden 10x spike is the sort of thing every personal site owner wants to believe for a moment. But the hourly shape told the real story almost immediately. Perfectly even growth is usually not audience growth. It is workload.

That turned out to be a useful reminder:

• Public technical content attracts crawlers because it is valuable and easy to process.
• "Unique visitors" in analytics can be a very optimistic label.
• For static sites, caching strategy matters more than guessing which bot is having a busy week.

If the origin is protected and HTML caching is configured properly, this kind of traffic is mostly an operational annoyance rather than a crisis.

Annoying is manageable. Exciting would have been nicer, of course, but manageable still wins.