---
title: GA4 Traffic Spike on WordPress From a Crawler That Runs JavaScript
url: https://ilogr.com/ga4-traffic-spike-wordpress-crawler/
published: 2026-10-30
updated: 2026-10-30
author: iLogr
categories: WordPress
reading_time: 10 min
description: A GA4 spike of one-view, one-user archive rows, all Direct in one hour, most likely means an automated browser ran your tag. GA4 has no bot-filter switch.
---

# GA4 Traffic Spike on WordPress From a Crawler That Runs JavaScript

**In short:** A GA4 spike of archive rows with one view and one user each, all Direct and packed into an hour, most likely means an automated browser ran your analytics tag. GA4 has no bot-filter switch, so confirm the pattern and compare your figures with and without those rows.

When GA4's home screen says views have more than doubled, readers are not always the cause. On one WordPress site, a large part of such a rise appears to have been automated traffic that GA4 reported as 75 active users. This guide shows how to recognise that pattern in GA4, why GA4 may count it, why the "bot filtering" setting so often recommended does not exist in GA4, and how to report around it.

## How do you tell whether a GA4 spike is a crawler?

Work in Reports, Engagement, Pages and screens, with the date range set around the spike. The table search and secondary dimensions only change what you see; they do not change your property.

1. **Find the odd rows.** Type a fragment into the table search that matches pages people rarely read: `/page/` for paginated archives, or `/20` for WordPress date archives such as `/2018/06/12/`. Automated traffic often shows as a long run of rows with exactly one view and one active user each, a few seconds of engagement and the same event count.
2. **Add Date + hour as a secondary dimension** (the plus sign beside the dimension heading). Readers spread out over days; automation can pack dozens of pages into one hour.
3. **Switch the secondary dimension** to Browser, Operating system, Screen resolution and Town/City in turn. One value on every row, especially an unusual screen size, suggests one configured client rather than many readers.
4. **Check Session source/medium.** `(direct) / (none)`, the Direct channel [1], means GA4 has no clear referral source for the traffic [2]. It is not evidence that a person typed the address.
5. **Check Event name.** A `first_visit` and a `session_start` on every page mean GA4 saw a new user and a new session on every page [3], consistent with a client that keeps no analytics cookie between pages.
6. **Rule out your own visits.** If the rows do not share one client, the spike may be you or your team checking pages after publishing, which needs a different fix.

When most of these line up, treat the rows as suspected automation. GA4 reports will not tell you who it was: GA4 does not log or store IP addresses [4]. Server or CDN request logs from the same hour may help identify the client, but user-agent strings and addresses do not prove who operated it.

![The crawler signature in GA4, with a Quick check ribbon in the top right. The pattern in one WordPress site's Pages and screens report, with an example path. One row, enlarged, with a Typical row sticker: page /2018/06/12/page/2/, Views 1, Active users 1, Engagement 4 s, Events 5. Five events on a typical row: page_view, first_visit, session_start, scroll and user_engagement; first_visit and session_start mean a new user and a new session for each page, with a 5 events sticker. The same on every row: Chrome on Macintosh, 1366x1366, (direct) / (none). A big number, 72 of 75 views in one hour, beside a grid of 75 dots, 72 solid and 3 pale, and the note 3 more, four days later. A band at the foot with a Heads up sticker says: One signal proves nothing alone. Treat rows as automated only when several checks agree.](https://ilogr.com/wp-content/uploads/2026/10/ga4-crawler-signature.webp)

*The pattern in one WordPress site’s report: single-view archive rows, a new user on each page, the same browser and screen size on every row, and most views inside one hour. The path is an example.*

## Why does a crawler appear in GA4 at all?

The GA4 tag is JavaScript. A crawler that only downloads HTML does not execute the page's Google tag. A headless browser can. Chrome's headless mode runs the browser "without any visible UI", and Google says all its other functions are "available with no limitations" [5]. The page loads, the Google tag runs and GA4 receives a page view like any other. Events can also reach GA4 as plain HTTP requests, without any page loading, as the Measurement Protocol shows [6], so event names alone do not prove that a browser ran the tag.

GA4 does try to keep bots out. Traffic from known bots and spiders is "automatically excluded", identified "using a combination of Google research and the International Spiders and Bots List" [7]. Three limits follow:

- **It covers known bots.** Google does not publish its full identification rules, so a Chrome label on a row does not tell you whether that traffic should have been excluded. In the field note below, the suspect traffic reported Chrome and accounted for 75 views.
- **You cannot see what it removed.** Google's help page says you "cannot disable known bot traffic exclusion or see how much known bot traffic was excluded" [7].
- **You cannot check the list yourself.** Access to the full current IAB list needs a paid subscription and a signed data agreement [8], so you cannot freely check whether a given crawler is on it.

## Is there a bot-filtering setting in GA4?

No. "Bot Filtering" was a view setting in Universal Analytics: "Select this option to exclude sessions from known bots and spiders" [9]. Standard Universal Analytics properties stopped processing hits from 1 July 2023 [10]. GA4 has no views, and its counterpart is the automatic exclusion above, which is always on and has no switch.

GA4's data filters are a different tool. There are three types: developer traffic, internal traffic by IP address, and web hostname traffic [11]. None is a general bot detector: a hostname filter can drop data sent for other hostnames, but cannot tell a crawler from a reader on your own hostname. They also work only forwards: Analytics evaluates them "from the point of creation forward", they "do not affect historical data", and once an exclude filter is applied its effect "is permanent" [11]. A data filter cannot clean up a spike that has already happened, and a careless one throws good data away for good.

So if a checklist, a guide or a colleague tells you to "enable bot filtering in GA4", the advice comes from Universal Analytics.

## How do you report around crawler traffic you cannot filter?

Leave the property's data alone and change how you read it. Google's data filter page itself points to report filters for hiding data "without permanently filtering out the data" [11].

- **Compare with and without the suspect rows.** Use a report filter or a comparison that excludes the specific suspect paths in the affected period, and keep the original figures beside it. Write down the rule and any real traffic it also removes: a broad pattern such as `/page/` also hides genuine paginated views. Report filters work only in detail reports and with compatible dimensions [12], and hiding page rows does not give you a property-wide count of human users or sessions.
- **Read user counts from the total row.** Traffic that starts afresh on every page adds one active user and one new user per page; in the field note it was 38% of active users over four weeks. When you filter to suspect rows, take active users from the table's total row rather than adding up the rows. Active users counts unique users [13], and one person who reads several pages appears in each of those pages' rows, so a sum can overstate them.
- **Check engaged sessions, but do not assume they are clean.** A session counts as engaged if it lasts longer than 10 seconds, has a key event, or has two or more page views [14]. A short, single-page session without a qualifying key event will not count as engaged. Check the suspect traffic's engaged sessions and your key-event set-up before treating this metric as less affected. The site in the field note had no key events set up.
- **Do not quote the home screen's percentage cards** for a window that contains the crawl. Pick a window either side of it, or report the affected period alongside a clearly defined exclusion.

Stopping the crawler is a separate job, and it starts with a record of the requests. Sources include your host's raw access logs, a CDN or firewall service with its own analytics, and some WordPress security plugins. Cloudflare's Security Analytics, for example, shows all traffic on every plan, but keeps up to 31 days on the free plan and uses sampled logs by default [15]. Choose by what you already run, how long a source keeps data, and whether it records every request or a sample. If the client is a crawler loading your server, our guide to AI crawler traffic and Cloudflare 524 errors covers robots.txt, caching and rate limits [16].

## What did a crawler spike look like on a WordPress site? (field note)

**Field note.** On a WordPress site with a few dozen posts, GA4's home screen showed views up 125.7% over 28 days. Direct was 88.1% of sessions, and only about a third of views were articles. The Pages and screens report had dozens of date-archive rows with one view, one user and a few seconds each. Reading the same four weeks again, one secondary dimension at a time, showed this:

- **75 views on 74 date-archive URLs, from 75 active users** in the table's total row. That is 38% of the property's 197 active users and 31% of its events in those four weeks.
- **72 of the 75 views fell within one hour.** The other three came four days later, for a day archive created after that first pass.
- **Every view reported Chrome on Macintosh at 1366×1366,** a square screen size, and every view was located in Singapore.
- **On the three paths of one day archive that we checked by event name,** each recorded one `page_view`, `first_visit`, `session_start`, `scroll` and `user_engagement` event. GA4 sends `scroll` when 90% of the page height becomes visible [17], and `user_engagement` carries the time the page was in focus [18]. Most of the 74 rows had five events; five had three or four, and the one row with two views had nine. The city breakdown also held rows with no views and two events each, located in other cities from Brazzaville to Bristol to Mexico City or with no city recorded; we read the first 100 of its 145 rows.
- **All 74 path rows showed `(direct) / (none)`** in the Session source/medium breakdown.
- **49 of the 75 views were page 2 or 3 of day archives that hold one to four posts.** With 12 posts to a page, those pages had nothing to list. We found no links to them in the archive pages or home page we checked; how their URLs were obtained is unknown.

Our inference is that browser automation visited a list of 26 of the site's 45 day archives, plus empty paginated paths for most of them, with a fresh analytics identity on each page. The matching browser attributes and user counts support that reading, but do not establish one browser, clean profiles or rotating addresses. We had no request logs from that hour, so we cannot name the crawler or say who ran it, and we do not know whether it was an AI crawler, an SEO tool or something else.

## What mistakes are easy to make when reading a spike like this?

- **Following advice written for the old product.** "Turn on bot filtering" is a Universal Analytics instruction [9]. Before acting on any setting from a guide or checklist, find it in your own GA4 Admin screens and in Google's current help pages.
- **Reading a column of ones as one visitor.** A long run of rows with one user each looks like one visitor walking the archive. In the field note, the total row for those rows said otherwise: 75 active users across 75 views. One visitor would barely have moved active users; these rows made up 38% of them.
- **Calling it automation on one signal.** An odd page title or a burst of Direct sessions proves nothing alone. Exclude rows from your reporting only when several of the checks at the top of this guide agree, and write down which ones did.

**Next step:** Open the Pages and screens report for your last spike, search for /page/ or /20, add Date + hour as a secondary dimension and count how many rows fall inside one hour.

## References

1. [Google Analytics Help: Default channel group (Direct)](https://support.google.com/analytics/answer/9756891). Used for: what counts as the Direct channel: source (direct) and medium (none).
2. [Google Analytics Help: Understand (direct) / (none) traffic](https://support.google.com/analytics/answer/15258820). Used for: why (direct) / (none) means no clear referral source and not proof of a typed address.
3. [Google Analytics Help: Automatically collected events (first_visit, session_start)](https://support.google.com/analytics/answer/9234069). Used for: what first_visit and session_start record: a new user and a new session.
4. [Google Analytics Help: IP masking in Universal Analytics (GA4 does not log or store IP addresses)](https://support.google.com/analytics/answer/2763052). Used for: that GA4 does not log or store IP addresses.
5. [Chrome for Developers: Chrome Headless mode](https://developer.chrome.com/docs/chromium/headless). Used for: that headless Chrome runs without a visible window but keeps all other functions.
6. [Google for Developers: Measurement Protocol (Google Analytics 4)](https://developers.google.com/analytics/devguides/collection/protocol/ga4). Used for: that events can reach GA4 as plain HTTP requests, without a page loading.
7. [Google Analytics Help: Known bot-traffic exclusion](https://support.google.com/analytics/answer/9888366). Used for: that exclusion is automatic and fixed, how bots are identified, and that its volume is hidden.
8. [IAB: IAB/ABC International Spiders and Bots List (access and subscription)](https://www.iab.com/guidelines/iab-abc-international-spiders-bots-list/). Used for: that the full IAB bot list needs a paid subscription and a signed agreement.
9. [Google Analytics Help: Edit view settings, Universal Analytics (Bot Filtering)](https://support.google.com/analytics/answer/1010249). Used for: that Bot Filtering was a Universal Analytics view setting.
10. [Google Analytics Help: Google Analytics 4 has replaced Universal Analytics](https://support.google.com/analytics/answer/11583528). Used for: when Universal Analytics stopped processing hits: 1 July 2023 for standard properties.
11. [Google Analytics Help: Data filters](https://support.google.com/analytics/answer/13296761). Used for: the three GA4 data filter types, that they work forwards only and that exclusions are permanent.
12. [Google Analytics Help: Apply filters to detail reports](https://support.google.com/analytics/answer/11377859). Used for: that report filters work only in detail reports and with compatible dimensions.
13. [Google Analytics Help: Understand user metrics](https://support.google.com/analytics/answer/12253918). Used for: that active users counts unique users, which is why rows should not be added.
14. [Google Analytics Help: Engagement rate and bounce rate](https://support.google.com/analytics/answer/12195621). Used for: the three ways a session counts as engaged.
15. [Cloudflare Docs: Security Analytics](https://developers.cloudflare.com/waf/analytics/security-analytics/). Used for: that Security Analytics shows all traffic on every plan, with limited history and sampled logs.
16. [iLogr: AI Crawler Traffic and Cloudflare 524 Errors on WordPress: robots.txt, Cache Rules and Rate Limits](https://ilogr.com/ai-crawlers-cloudflare-524-wordpress/). Used for: the edge-side guide to crawler load, caching and rate limits.
17. [Google Analytics Help: Enhanced measurement events (scroll)](https://support.google.com/analytics/answer/9216061). Used for: that scroll fires when 90% of the page height is visible.
18. [Google Analytics Help: User engagement](https://support.google.com/analytics/answer/11109416). Used for: that user_engagement carries the time the page was in focus.