Evergreen
Bot Traffic vs. Human Audience in Analytics
Analytics cannot perfectly separate bots from people. Combine verified identities, server behavior, browser data, and business actions while keeping an unknown category.
Bot Traffic vs. Human Audience: What Analytics Can Tell You
No common analytics source can perfectly separate bots from people. A defensible system verifies known crawlers where possible, compares server behavior with browser analytics, looks for meaningful business actions, and keeps an unknown category. A user-agent string alone is not identity, and a filtered Analytics session is not proof of a human visitor.
The useful question is rarely "How many requests were human with absolute certainty?" It is "Which activity can we classify well enough for this decision?"
Start with the event, not the label
A server request records an interaction with infrastructure. A pageview records a configured analytics event. A session groups events under the analytics system's rules. A conversion records a defined action. None of these events contains a universal human-or-bot field.
Automation also has different purposes. Search crawlers discover content. Monitoring checks availability. Security scanners test systems. scrapers collect data. User-triggered agents act for a person. Malicious automation probes or abuses. Internal tests can look like external activity.
Treating every bot as fake traffic loses these distinctions.
flowchart TD
A["Incoming request"] --> B{"Deterministic identity evidence?"}
B -->|"Signed, published range, or confirmed DNS"| C["Verified automation"]
B -->|"No"| D{"Declared identity and matching behavior?"}
D -->|"Some evidence"| E["Declared or likely automation"]
D -->|"No clear evidence"| F{"Browser and business signals?"}
F -->|"Consistent signals"| G["Likely human activity"]
F -->|"Mixed or missing"| H["Unknown"]
Why a user agent is not enough
The HTTP user-agent value is supplied by the client. A request can claim to be Googlebot, a browser, or a named AI crawler. The string is useful for policy and investigation, but it can be copied.
Google's current crawler-verification guide recommends matching requests to published IP ranges or using forward-confirmed reverse DNS. The DNS method checks that the request IP resolves to an expected Google domain and that the resulting hostname resolves back to the original IP.
Cloudflare's current verified-bot documentation describes deterministic identification through signed requests, published IP lists with stable user agents, or reverse DNS. It also considers behavior and compliance. A Cloudflare classification is still Cloudflare's determination, not a universal identity ledger.
| Evidence | What it can support | What it cannot establish alone |
|---|---|---|
| User-agent string | Declared client identity and policy group | Authentic identity |
| Published IP match | Request originated from a published network range | Purpose of every request or human involvement |
| Forward-confirmed reverse DNS | Strong identity evidence for documented operators | That the request was desirable |
| Cryptographic request signature | Possession of the corresponding signing authority | That the action was safe or authorized for every resource |
| Request pattern | Likely automation or anomaly | Named identity with certainty |
| Browser interaction events | Client executed measured code and interacted | A natural person performed every event |
| Purchase or verified signup | Activity reached a business outcome | Every preceding request was human |
What Google Analytics filters
Google Analytics says it automatically excludes known bot and spider traffic using Google research and the International Spiders and Bots List. The same page qualifies the result as exclusion to the extent possible.
The operator cannot see how much known-bot traffic was excluded through that control. Unknown automation, new clients, browser-like bots, measurement-protocol misuse, internal automation, and user-triggered agents may not fit a simple known-bot list.
Analytics also misses some real human activity when consent is withheld, JavaScript is blocked, a tag fails, a browser restricts tracking, or implementation is incomplete. A lower Analytics count can mean cleaner filtering, lower human use, less measurement, or some combination.
What server and CDN records add
Server records observe requests that never execute analytics. They can expose user agents, IPs, paths, status codes, timestamps, methods, bytes, referrers, rate patterns, and cache behavior, depending on the system and privacy configuration.
That detail supports classification. A client requesting thousands of pages at regular intervals without assets or browser events is likely automated. A burst against login routes may indicate abuse. A published search crawler range can confirm beneficial indexing activity.
Logs still do not reveal a person directly. Shared networks, proxies, carrier address translation, corporate egress, privacy relays, caches, and user-triggered agents complicate identity. IP addresses and request records can also be personal data under applicable rules, so collection, access, retention, and purpose need review.
What robots.txt means
RFC 9309 standardizes the Robots Exclusion Protocol. It defines how crawlers select rules using product tokens and read robots.txt. The standard explicitly says the rules are not access authorization.
A compliant crawler's product token helps a publisher state preferences. It does not authenticate the crawler, stop a noncompliant client, or replace access controls for private material.
This distinction matters when reporting AI crawler activity. A matching user agent shows a declaration. Verification requires additional evidence where the operator publishes it.
Build a classification policy that admits uncertainty
Use categories that reflect the available evidence.
| Reporting category | Minimum evidence | Appropriate use |
|---|---|---|
| Verified automation | Signed identity, published IP match, or confirmed DNS under a documented method | Named crawler reporting and access policy |
| Declared automation | Recognized user agent without deterministic verification | Operational watchlist with uncertainty |
| Likely automation | Rate, path, timing, client, and interaction pattern strongly indicate automation | Capacity, anomaly, and security analysis |
| Likely human activity | Browser behavior and session pattern consistent with people, without contrary evidence | Audience trend estimates |
| Business-qualified activity | Verified action under the organization's outcome definition | Demand and value reporting |
| Unknown | Mixed, incomplete, or conflicting evidence | Preserve rather than force a label |
Document who owns the rules, which sources feed them, how often they refresh, and how false positives are reviewed. Store the evidence needed for the decision, not an unlimited identity dossier.
Measure audience with outcomes, not clean-looking traffic
The Episode 87 transcript noted implausibly high visit counts and connected them to automated activity. That is a reasonable trigger for investigation, not proof that a specific parameter caused those visits.
Compare Analytics, server records, Search Console, and meaningful actions over the same period. If requests fall while qualified subscriptions hold, the removed activity may not have represented audience value. If Analytics sessions fall because a tag broke while server arrivals and sales hold, the issue is measurement. If every layer and outcome falls, demand or availability deserves attention.
[[How to Diagnose a Sudden Search Analytics Change]] supplies the comparison sequence. [[How to Build SEO Measurement Without One Search Parameter]] assigns each source its proper role.
Human audience is an inference built from several events. Report the inference, its confidence, and the unknowns instead of turning an imperfect filter into certainty.
This page reflects sources reviewed on July 27, 2026. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.
Sources
Follow the evidence.
- support.google.com: 9888366support.google.com
- developers.cloudflare.com: verified botsdevelopers.cloudflare.com
- support.google.com: 17011259support.google.com
- semrush.com: most cited domains aisemrush.com
- developers.google.com: search console startdevelopers.google.com
- developers.google.com: verify google requestsdevelopers.google.com
- developers.google.com: debugging search traffic dropsdevelopers.google.com
- developers.google.com: google analytics search consoledevelopers.google.com
- support.google.com: 96568support.google.com
- developers.google.com: overview google crawlersdevelopers.google.com
- developers.google.com: performance data deep divedevelopers.google.com
- ahrefs.com: blogahrefs.com
- rfc-editor.org: rfc9309rfc-editor.org
- Introducing Search Generative AI performance reportsdevelopers.google.com
- searchengineland.com: google search confirms it does not support the results per page parameter 462244searchengineland.com