Use Google Analytics to find suspicious traffic patterns, then check those patterns against your site's request logs. A sudden jump in sessions, unusual geography, or low engagement can justify an investigation. None of those observations proves that the visitors are bots.
The useful question is narrower: what changed, which routes were affected, and does the server-side evidence support the same explanation?
Know what GA4 already excludes
Google says GA4 automatically removes traffic identified as known bots and spiders. You cannot disable that exclusion or see how much traffic it removed. The remaining traffic is therefore not a verified count of human visits. See Google's known bot-traffic exclusion documentation.
GA4 is also not an access log. Its reports depend on collection and processing. Google's measurement overview explains how website tags send interaction data for reporting. An HTTP request that never produces an analytics event may still reach your application and consume resources.
Keep that distinction in mind when investigating web scraping: a quiet analytics report does not establish that your content is receiving little automated traffic.
Rule out collection and data-hygiene causes
Before assigning a bot label, check what shipped near the start of the anomaly. Look for a tag added twice, a changed consent flow, a new campaign, a monitoring job, or an event sent from both the browser and the server.
Google's Measurement Protocol can send events over HTTP for server-side and offline interactions. It supplements automatic collection. If your team uses it, inspect those senders as well as the browser tag; an event does not necessarily describe a page load.
Ask who owns internal and test traffic. GA4 supports internal-traffic filters, but an active exclusion permanently removes matching incoming data from processing, including BigQuery export. Test the rule before activating it, following Google's internal-traffic filter guidance. A broad exclusion can hide the evidence you were trying to understand.
Build a diagnostic slice
Choose a fixed time window around the change and compare it with a comparable earlier period. Start with the affected landing routes and traffic sources. Add device or geography only when the dimension helps explain the difference.
Use a worksheet like this rather than a universal bot threshold:
| Observation | Plausible alternative | Next check |
|---|---|---|
| Sessions rose after a release | Duplicate collection or a changed event definition | Compare tag versions and event senders |
| One route has many short visits | A campaign or a page that answers a quick question | Check referrals, campaign changes, and request activity |
| Events arrive at regular intervals | A scheduled internal job | Compare the schedule with monitoring and integration owners |
| Unfamiliar geography dominates | A legitimate audience change or proxy use | Check campaign scope and network evidence; do not block a country from this alone |
| Many events have no plausible page sequence | Direct event submission or instrumentation gaps | Inspect Measurement Protocol sources and collection coverage |
Record what would disprove your first explanation. If the anomaly disappears when duplicate events are removed, you have a measurement issue to fix before considering enforcement.
OWASP's skewing taxonomy describes automation used to manipulate metrics. It is one possible cause, not the default explanation for an unusual chart.
Correlate the slice with request evidence
Compare the same routes and time window in your edge or application logs. Record response codes, request volume, and available session or crawler evidence. Establish whether the requests actually reached the protected application or were answered earlier by a cache or enforcement layer.
Do not match people by geography and timestamp. Those fields can describe many unrelated visits. If you lack an approved shared identifier between the two systems, compare aggregates and call the result a cohort-level comparison. Keep unmatched events and unmatched requests separate.
For a supported identifier already deployed by your team, check how it is created, whether it survives retries, and whether one identifier maps to several events or requests. A successful join still does not establish human identity. Do not add personal data to Analytics to make a join easier.
The browser-automation guide explains the request-side evidence layer. Also distinguish declared crawlers from browser agents using the AI traffic taxonomy; their collection behavior need not be the same.
Run a controlled analytics-to-request comparison
If the collection path remains unclear, test it on a site and analytics property you control. The following is a reader exercise, not a completed experiment or a requirement to accept this diagnostic method.
The optional plan ga4-request-correlation-v1, dated 2026-09-04, uses 20 sessions per cohort: ordinary-browser, known-approved-bot, direct-measurement-protocol, and browser-automation. That is 80 planned sessions, with no measured results reported here.
Use ordinary test browsers, an authorized crawler, your own synthetic event sender, and test-owned browser automation. For each, record whether the request exists, whether the event appears after processing, whether a valid join exists, and what remains unknown. Do not assume an approved crawler appears on Google's undisclosed exclusion inputs, and do not assume every accepted event will appear in every report.
The purpose is to find differences in your measurement paths, not to calculate a universal bot-detection rate.
Separate reporting cleanup from request prevention
Fix a collection error in the measurement setup. Use a reporting comparison or tested filter for a reporting problem. If request evidence shows unwanted automation, apply the relevant access policy where the application receives or serves the request.
An analytics filter cannot stop a client downloading a page. Conversely, a block at the edge can change what reaches both the application and the analytics tag. Keep the change log for those systems together so the next traffic drop has an explanation.
Where Centinel fits
Centinel's bot-management overview describes the request and browser evidence used to evaluate automated traffic. This guide does not assume a built-in GA4 join or a one-click bot cleanup feature. Correlation depends on your instrumentation and the observations available at the integration point.
Once the investigation identifies unwanted collection, use the scraping and crawler use case to review response options. Start with the affected route and retain the evidence behind the decision.