Sagentica research · self-published

3.6 million requests, a handful of humans

In one week Cloudflare logged 3,636,443 requests across our 2,596 domains. On four guide sites we could measure end to end, Cloudflare's AI assistant first called the traffic about 4,000 unique human visitors; real browsers loaded those pages 26 times. Embarrassing, but instructive: this is what the bot takeover looks like from the inside.

By Jeff Johnson, founder, Sagentica · Published 2026-10-14 · Data: Cloudflare analytics for howtosellmydomain.com, howtotradedomains.com, domainnamebundles.com and domainnamebundlesforsale.com

Key findings

Across all 2,596 domains in our Cloudflare account, Cloudflare logged 3,636,443 requests, 293,616 "visits" and 37.5 GB of traffic from October 7 to 13, 2026. Browser analytics, which runs on 271 of those domains, recorded 1,240 real page loads in the same week, and only 37 domains had any at all.
Cloudflare's seven-day view for our Pages project showed 146,146 requests. About half were Cloudflare counting the same request twice internally; 72,768 requests actually reached our 16 domains from October 7 to 13, 2026.
Asked for unique human traffic, Cloudflare's dashboard AI assistant answered: about 72,000 requests from about 4,000 unique visitors. Asked again later in more detail, it estimated two to five humans a week.
Cloudflare Web Analytics, which only counts browsers that actually load and run a page, recorded 26 page loads that week: roughly one for every 2,800 requests.
In one 24-hour window, 3,300 of 7,515 requests (44%) asked for PHP or WordPress files on sites that use neither: automated exploit scanners.
An 18% timeout rate that looked like an outage was four hourly bursts of scanner traffic; the sites' own code logged zero errors in 9,295 runs.
Separately, 204 of the 2,596 domains in our Cloudflare account (about 8%) had Cloudflare's "Block AI bots" setting on, locking AI search crawlers out. We turned it off.

Why we looked

Sagentica runs four free guide sites about selling and trading domain names, each reachable on four domain extensions. They link to Domain Dumpster Dive, our marketplace. The traffic looked healthy, yet the marketplace had no sign-ups from it.

So we asked the AI assistant built into our Cloudflare dashboard, specifically, for unique human traffic. It answered that real human traffic was about 72,000 requests from about 4,000 unique visitors over seven days. Four thousand people and zero sign-ups meant either the sign-up form was broken or the people were not there. We tested the sign-up; it worked. Asked again later with a more detailed breakdown, the same assistant put its estimate at two to five humans a week. We went to the browser data to settle it.

The portfolio-wide picture

Across all 2,596 domains in our Cloudflare account, Cloudflare logged 3,636,443 requests, 293,616 "visits" and 317,965 "page views" from October 7 to 13, and served 37.5 GB. Browser analytics runs on 271 of those domains; it recorded 1,240 real page loads that week, most of them on a handful of active sites, and only 37 domains had any at all. Because browser analytics does not cover every domain, those two figures are not a like-for-like ratio. The four guide sites below are covered end to end, so that is where we did the exact comparison.

What the dashboards said vs. what browsers did (16 guide-site domains)

Measure (Oct 7–13, 2026)	Value	What it actually counts
Requests, all 16 domains	72,768	Every request reaching the domains, from anything
Requests, four main .com sites	42,983	Same, main sites only
"Page views", four main sites	35,455	HTML responses served, to bots and people alike
Unique visitors, four main sites (sum of daily counts)	3,626	Distinct IP addresses per day, not people
Real browser page loads (Web Analytics), all sites	26	Browsers that actually loaded and ran the page

Browser-based analytics undercount somewhat, because some people block them. Even if the real number were several times higher, the gap would still be more than a hundredfold. The lesson is not that one tool is wrong; it is that "visitors" means different things in different systems, and an AI summary can pass along the wrong one with confidence.

Who the "visitors" were

In the 24 hours from 19:00 UTC on October 13, 3,300 of 7,515 requests (44%) asked for files such as /wp-admin/…, /xmrlpc.php or /info.php. None of the four sites runs WordPress or PHP. These are automated scanners looking for vulnerable websites. They are not prospective customers, and they find new sites on their own, typically soon after a domain gets a new security certificate.

The "outage" that wasn't

About 18% of requests in the same period ended in a 504 timeout, which looked like a reliability problem. Broken down by hour, it was not: on the busiest site, 961 of 963 timeouts came in four hourly bursts (02:00, 05:00, 06:00 and 07:00 UTC) when scanners sent hundreds of requests in minutes. The sites' own code recorded 0 errors in 9,295 runs, and the same paths answered in under 0.2 seconds when tested outside a burst.

What we changed

One firewall rule on each of the sites' 16 domains: block any request whose path contains .php or /wp-. The sites use neither, so no real visitor is affected. Probe requests now get a 403 from Cloudflare instead of reaching the site.
Tracking that measures people: every link to the marketplace now carries a source tag, so sign-ups can be traced to the page that sent them.
Content for people and answer engines: the four single-page sites became 23 pages of guides with structured data, a full sitemap and an llms.txt file. Unknown addresses now return a real 404 instead of a page that tells crawlers nothing.

A second finding: AI crawlers were locked out

While checking bot settings, we audited all 2,596 domains in our Cloudflare account. On 204 of them (about 8%), Cloudflare's "Block AI bots" setting was on, and on those sites Cloudflare also managed the robots.txt file, which tells AI crawlers to stay away. For sites meant to be found through AI search and answer engines, that setting works against the goal. We turned it off and removed the managed robots.txt on all 204 domains.

What other site owners can take from this

Do not treat "unique visitors" or "page views" in edge or server analytics as people. Compare them with browser-based analytics before making decisions.
Break error rates down by hour and path before calling it an outage.
If your site has no PHP, blocking .php paths is a low-risk way to cut scanner noise.
If you want to appear in AI answers, check your CDN's AI-crawler settings and the robots.txt it serves, not just the one you wrote.

Method and limits

Figures come from Cloudflare zone analytics (daily rollups for requests, page views and uniques; sampled hourly data for the 24-hour path and status breakdowns), Cloudflare Web Analytics for browser page loads, and Cloudflare Pages Functions metrics for code errors. Sampled figures are estimates. The sites are small and new, so these results describe this setup, not the web at large. Sagentica owns the sites and the marketplace they link to.

Questions or data requests: press@sagentica.com.