How to Stop Bot Traffic on Your Online Store

Between late July and October 4, 2026, Shero and Littledata tracked bot traffic in the GA4 data of 787 online stores. From our sample, 133 of 687 Shopify stores from Littledata (19%) and 37 of 100 stores from Shero (37%) recorded 5% or more of their sessions from bots.

Every one of those bot sessions got past GA4's own bot filter.

This study measures how much bot traffic reaches GA4, what it does to conversion rate and channel reporting, and recommends what you can do to stop it. The method and six findings come next, then the four steps in detail. A free one-minute bot check for your own GA4 is at the end.

What bot traffic costs a business

The bots in this study almost never placed orders, so orders and revenue don’t change. What changes is every number divided by sessions. For example, take a store with 100,000 sessions in a month, 20% of them bots, and 1,600 orders. GA4 shows a 1.6% conversion rate when real shoppers convert at 2.0%. Additionally, direct will look like a third of the traffic when in reality it’s closer to a fifth.

Since most teams use those numbers to make business and marketing decisions, a falling conversion rate caused by increased bot traffic, leads to a redesign that the store didn’t need. Direct growth gets credited to the brand, and budget is reallocated from the paid channel that was bringing buyers. SEO gets blamed when sessions climb and sales don’t. A/B tests take longer to reach a result.

The same month at the same store: orders don't change, but conversion rate and Direct share do once the bots come out.

To see how far off your own numbers are, divide your GA4 conversion rate by the share of sessions that are real. At 20% bots, that's 1.6% ÷ 0.8 = 2.0%.

The fix is to stop bots before GA4 records them and to filter out the ones already in your reports. Here’s where to start.

What to do first

If you only have an hour this week, do these in order.

Server-side tracking (step 2) is the bigger project. It’s worth doing, but it’s not the first hour.

Why this study exists

GA4 is the tool merchants use to decide where the next dollar goes, and Google's known bot exclusion removes bots it recognizes from its own research and the IAB list. Google doesn’t say how many it removes, and anything it doesn’t recognize is counted as a visitor.

This is the fifth study in the series, and the first four all read data that bots can distort.

The AI referral benchmark compared conversion rates by channel in GA4. A channel report is only as clean as the sessions in it, so this study checks the denominator every other GA4 number depends on.

Methodology

Sample selection

The study uses two groups of stores, one from Littledata and one from Shero. Each group is reported separately and the two are never added together.

Neither group is a random sample of eCommerce. Littledata's group leans toward stores that already invest in tracking, and our group is made up of stores Shero manages.

Data collection

Each store's GA4 data was retrieved through the GA4 Data API as a signature table: one row, or cell, per combination of city, region, channel, operating system and screen size. Every cell carries sessions, engaged sessions, events per session, users and new users. For the Shero stores, every cell the API returned was kept.

Stores with 2,000 or more sessions in the most recent week were measured over 7 days. Stores with fewer were measured over 28 days so their share does not swing on a handful of sessions, and stores under 500 sessions in 28 days were not judged.

How a session is classified as a bot

Both groups were scored with the same rules, Littledata’s GA4 bot classifier, so the numbers are comparable. A cell counts as bot traffic only when an identity rule and a behaviour rule are both true.

Cells under 10 sessions were never classified. Cells with no location, operating system or screen were excluded, because on server-side stores they are webhook and consent pings, not browsing sessions. Server-side events that arrive with a location but no operating system or screen are still counted: orders, subscription renewals, carts and checkouts sent from a tracking provider’s servers, mostly located in Ashburn, Virginia. They were about 2% of bot sessions on Littledata stores.

How to read the numbers

Bot share is bot sessions divided by all sessions in the store's signature table. An affected store has a bot share of 5% or more. That’s a line we picked to sort stores, not a safe limit, and a store at 4% still has bots in its numbers. A signature is the location, operating system and screen size of a group of sessions, written as "Singapore, Windows, 1280x1200".

GA4 already removes the bots that announce themselves before any of this is counted, and it doesn't say how many. So the real bot traffic on every store is higher than the numbers here.

What this study does not measure

The study measured GA4 only. A headless browser fires every client-side tag on a page, so the same traffic very likely reaches Meta, TikTok, Klaviyo and heatmap tools, but this data cannot put a number on it.

Finding 1: One in five stores had 5% or more bot traffic

On the median store the share was small: 0.9% on Littledata stores and 2.5% on Shero stores. The ten worst stores carried 79% of all bot sessions on Littledata stores and 89% on Shero stores.

The red rows are the affected stores: 19% of Littledata stores and 37% of Shero stores.

The table below has the numbers behind the chart for the week ending October 4.

One Littledata store carried 35% of all the bot sessions on Littledata. The share across all sessions describes a handful of stores, so the median and the count of affected stores are the honest summary.

Finding 2: The bot rules don’t affect real buyers

A bot classifier is only useful if it leaves real customers alone. To test that, we matched every real GA4 order on Shero stores to the sessions the bot rules flagged.

Sessions the bot rules flagged had 3.7 orders per 10,000 sessions, against 416.6 for everything else.

The table splits the flagged sessions by how many of the users were new, and that is where the 220 orders came from.

Bots did not place these orders. 219 of the 220 came from flagged groups where fewer than half the users were new. These are real returning buyers whose purchase reached GA4 without a page view, which GA4 files under Unassigned with no engagement. Purchases recorded this way usually come from server-side tracking, which records orders the browser tag never saw, such as subscription renewals and orders from shoppers who block scripts or decline cookies.

Three stores were affected only because of these cells, and with the check applied the count of affected Shero stores is 34 (see the sensitivity table below). This is why the segment in step 3 requires new users: it removes the bots and keeps your returning customers.

Finding 3: GA4 records 95% or more of bot sessions as Direct traffic

Bot traffic arrives with no referrer, so GA4 files them under Direct or Unassigned. On Shero stores the bot sessions were 4% engaged, with 3.3 events per session and 89% new users. Channel is part of the bot rules, so we checked this without it. Using only the data-centre rule, which ignores channel, 95% of the flagged sessions on Shero stores were still Direct, against 56% of all sessions.

Direct is the channel merchants read as brand demand, and it is where GA4 counts the bots.

Because almost all bot sessions are recorded as Direct, they change three numbers most teams look at every week.

On the median store under 5% bot traffic, removing the bots moved conversion rate by less than 1%. If you track AI traffic as its own channel, these bot sessions are still mixed into Direct.

Bots are only part of the conversion gap on affected stores. Before removing bots, affected Littledata stores needed a median 103 sessions per order against 63 for the rest, and they still needed more after the bots were removed, because their human traffic leaned on Direct and organic search while the comparison stores leaned on paid social.

Direct traffic is often treated as a proxy for brand demand (which it can be!), but as this study shows, it’s also a haven for bots. Check for bots before you decide your strategy is wrong just because your conversion rate dropped.

Dana DiTomaso, Principal & Founder, Kick Point

Finding 4: Platform and store size do not protect a store

Affected stores showed up in every size on Littledata stores and on every platform with enough stores to compare on Shero stores.

Only 7 Shero stores were on BigCommerce and 7 on WooCommerce, too few to give a fair percentage, so they’re left out of the table and listed in the dataset. Being on Shopify or Magento, or being a large store, didn’t keep bots out, so the only way to know your number is to check your own store.

Finding 5: The same bot signatures hit both sets of stores and keep changing

Three signatures were common to both sets of stores in the same week. In the week ending October 4, Singapore on Windows at 1280x1200 appeared on 174 Littledata stores and 34 Shero stores, Singapore on Macintosh at 1366x1366 on 165 and 31, and Ashburn, Virginia on Windows at 1800x1125 on 92 and 29.

The Colorado bot at 800x600 dropped from 38 stores to 4 while a Colorado bot on Windows at 1800x1125 grew, then the 800x600 version came back on 22 stores.

The behaviour stayed the same while the signatures changed. A rule built on behaviour plus identity keeps working, and a list of last month's screen sizes does not.

Finding 6: Stores with bot traffic continue to get same traffic week after week

Of the 36 Shero stores at 5% or more on October 4 that were also measured in August and September, 21 were at 5% or more in all three weeks. Another 7 were at 5% or more in two of them. Across the three weeks, 45 of 98 stores crossed 5% at least once.

Most stores with bot traffic in October had it in August and September too.

The bots change their signature from week to week (finding 5), but they keep coming back to the same stores. A store with bot traffic should not expect it to go away without a fix, and a store that looks clean this week can cross 5% the next.

How do bots get into your analytics?

Bots reach GA4 by two routes, and each needs its own fix. The four steps below follow from the six findings.

Server-side tracking helps with both routes, because the server can check each event before it reaches GA4 (step 2). However, it does not stop a headless browser from loading the page and firing your browser tags. Every Littledata store in this study tracks server-side, and 19% of them still had 5% or more bot traffic. That is why the steps start in the tag manager.

How to stop bot traffic in four steps

Steps 1 and 2 stop bots from being recorded, step 3 removes what still gets through, and step 4 protects the store itself.

Step 1. Block headless browsers before any tag fires

In Google Tag Manager, create a Custom JavaScript variable that returns true for four clear automation signals, then add it as a blocking trigger on every tag. The bot blocker file has the variable and trigger ready to import. Puppeteer opens pages in an 800x600 default viewport, and bots built on it often report an 800x600 screen too, which is the screen size GA4 recorded for the Colorado bot in finding 5. Automation tools set navigator.webdriver to true, and almost no phone or monitor in use has a square screen. The fourth catches bots dressed up as phones: a desktop browser pretending to be an iPhone or Android phone still reports a desktop platform to the page, such as MacIntel, which no real phone does.

The check happens inside GTM before a tag fires, so a real shopper never notices it.

function() {
  try {
    var w = screen.width, h = screen.height;
    var ua = navigator.userAgent || '', p = navigator.platform || '';
    if (navigator.webdriver === true) return true;
    if (w === h) return true;
    if (w === 800 && h === 600) return true;
    if (/iPhone|iPod/.test(ua) && !/iPhone|iPod/.test(p)) return true;
    if (/Android/.test(ua) && /Win|Mac|x86_64|i686/.test(p)) return true;
    return false;
  } catch (e) { return false; }
}

IMPORTANT: before you publish the trigger, open GA4 and check for engaged sessions at 800x600 on your own store. Leave 1920x1080 and 1280x720 alone, because real people use them. The same goes for 375x812, which is a real iPhone mini screen. The blocker never blocks that size on its own, only a phone that reports a computer platform.

Installing it takes about 15 minutes for a store with 10 tags:

1. Download the bot blocker file.
2. In GTM, open Admin, then Import Container, and choose the file.
3. Choose a new workspace, so nothing goes live until you publish.
4. Pick Merge, then Rename conflicting tags, triggers and variables. Do not pick Overwrite. GTM selects it by default, and it replaces every tag you already have with the two items in the file.

Merge adds the variable and the trigger next to your existing tags. Overwrite would delete them.

5. Open each tag that sends data, such as GA4, Meta, TikTok, Klaviyo, HubSpot and heatmap tools. Under Triggering, click Add Exception and pick Block - Automated browser (Shero).

The same GA4 tag before and after. The firing trigger stays the same, and the exception is the only change.

6. Click Preview, open your store, and check that your tags still fire for you.
7. Submit and publish the workspace.

We installed it on sherocommerce.com on October 16, 2026, then sent four headless browser visits to the live site. The normal looking visit was tracked as before. The three bot visits loaded GTM, but no tag fired for any of them.

Within a day, the bot traffic changed disguise. On our own site, sessions at 800x600 and on square screens dropped to zero from October 17, and the bots came back as fake iPhones at 375x812, with 66 sessions on October 18. That is why the variable now has a fourth check, and why the segment in step 3 needs a weekly review.

We tested the fourth check with Playwright in stealth mode on October 19. An emulated iPhone X and an emulated Pixel 5 were blocked. Normal desktop Chrome and an emulated iPad still fired the tags, and real iPhone and Android phones on our team still showed up in GA4.

Because the block is on the tags, it keeps these bots out of GA4, Meta, TikTok, Klaviyo onsite tracking and heatmap tools at once. It only stops the tags. The bots still load your pages, and stopping them at the door is step 4. Do a pixel health check afterward to confirm real purchases still fire every tag.

One limit: pixels that Shopify apps install, or that you add in Shopify's Customer Events, do not load through GTM, so the blocker does not cover them. On many stores that includes Meta, TikTok and Klaviyo. Check where each pixel loads before you count on it.

The same goes for tracking that doesn’t load through GTM, such as Littledata’s script. Littledata plans to build similar bot checks into its new tracking script, due in January 2027. Either way, the checks need a weekly look, because the bots change their disguise often (finding 5).

Step 2. Move your tracking server-side so you can filter bots

Server-side tracking changes who talks to Google. Your pages send events to a server you control, or to your tracking app’s server, and that server passes them on to GA4. Because the server sees every event before GA4 does, it can check each one against your real orders and customers and drop the ones that look like bots.

On Shopify there are three common ways to set it up:

1. A server-side tracking app such as Littledata. Turn on Bot filtering for the GA4 destination, which drops fake cart and checkout events from bots before they reach GA4.
2. Server-side Google Tag Manager, hosted on Stape or Google Cloud. Stape's Bot Detection adds a bot score to each request, and you can use it to stop the GA4 tag from firing.
3. A Cloudflare Worker, if you have your own Cloudflare account (which I highly recommend).

“A browser tag has to judge each visitor on its own, from one device on one page, and a well-built bot looks just like a shopper there. A server sees the same event in context: the store’s own orders and customers, every other session arriving at the same moment and, for a tracking provider, the same fingerprint landing on hundreds of other stores, which is how this study caught many of these bots. Server-side tracking doesn’t filter bots by itself, but it is the only place where filtering them reliably becomes possible.”

Ed Upton, Founder and CEO, Littledata

There is one more thing to check. Anyone who copies the measurement ID from your page source can send fake events to your GA4 without ever visiting the site. To see whether yours is showing, open your store, view the page source and search for “G-”. Most server-side apps, Littledata included, still send the page view from the browser, so the ID stays in the page. Only a setup built to keep the ID on the server, like a Cloudflare Worker that adds it on the way to Google, takes it out.

If you do take it out, your current ID is still known to the bots that collected it. Once the server-side setup is recording traffic properly, create a new web data stream whose ID only lives on the server. Rename the old stream DO NOT USE rather than deleting it right away, and delete it once the new stream has been recording data for a few weeks, because hits sent to the old ID still will show in your property until it is gone.

Step 3. Exclude what still gets in at report time

Build a GA4 segment for sessions where all four of these conditions hold, then exclude it from conversion rate, channel and engagement reporting:

• The channel is Direct, Unassigned or (not set).
• The screen is an automation size (800x600, 1024x768, 1280x720, 1280x1200, 1800x1125, 2000x2000) or square.
• The session has 4 events or fewer and no engagement.
• The user is new, which keeps returning buyers out of the segment (finding 2).

GA4's segment builder takes three of these conditions: the channel, the screen size, and Session number exactly 1, which is the same as a new user. Events per session and engagement rate are easier to apply as filters on the exploration itself: events per session 4 or fewer and engagement rate 5% or lower. GA4 also has no way to match every square screen, so list the square sizes you see in your own screen resolution report. The study scored groups of sessions and the segment works on single sessions, so your numbers won’t match ours exactly. Keep your normal reports next to the segment, so you can tell whether a change came from the bots or from real shoppers.

The segment on our own GA4 property. The screen list is 800x600, 1024x768, 1280x720, 1280x1200, 1800x1125, 2000x2000 and the square sizes from 1024x1024 to 1920x1920.

GA4 has no way to remove these sessions from standard reports once they are collected. Its data filters cover internal traffic, developer traffic and unwanted hostnames, and none of them work on past data, so a segment in Explorations or Looker Studio is the only cleanup inside GA4 for sessions already recorded. Review it every week, because the signatures change (finding 5). The weekly bot report in the last section shows the same groups for your own property, with the rows that match the behaviour rule in red.

Two GA4 settings help from here on. The unwanted referrals list, under Admin, Data streams, Configure tag settings, stops fake referrers from showing up as traffic sources, but the sessions themselves stay in your reports. If you would rather keep bot data out of GA4 than stop the tags, have the step 1 variable set a traffic_type value instead and exclude that value with an internal traffic data filter. Leave the filter in Testing first, because data a filter excludes cannot be recovered.

Step 4. Challenge by behaviour at the edge and allow the crawlers you want

Use your CDN's bot management or a managed challenge on the worst data-centre networks, and explicitly allow Googlebot, Bingbot, OAI-SearchBot, GPTBot, ClaudeBot and PerplexityBot. Data-centre towns led the bot traffic on only 5 of the 37 affected Shero stores, so IP and country rules would have missed the other 32.

Every Shopify store already uses Shopify's own Cloudflare protection, but merchants cannot add their own rules to it. The custom rules below need your own Cloudflare account in front of the store, which is how we set up our own website and many of our clients. Setting that up means moving your DNS to Cloudflare and turning the proxy on for the store’s records, so the store’s traffic goes through it. It is a one-time change, but it takes some care, and some services will set it up for a fee. Cloudflare documents this setup for Shopify, but Shopify doesn’t support it. Shopify says it can break at any time and that problems it causes are outside Shopify Support’s scope, so weigh that before you switch it on. If your store is not set up that way, steps 1 to 3 still apply.

If you would rather not write rules, Cloudflare's Bot Fight Mode on the free plan, or Super Bot Fight Mode on paid plans, challenges likely bots across the whole site. Bot Fight Mode cannot be skipped for a single path or tool, so check Security Events after you turn it on.

Before you turn on a challenge, check who already reaches your store from cloud networks. In Cloudflare, open Security, then Analytics, and filter by source ASN. When we did this, most of the Amazon traffic to our site came from tools we use.

HubSpot and Pingdom are on Cloudflare's verified bot list, so the rule lets them through. Amazon's AI assistant is not, so we added an exception for it.

On Cloudflare, add these two custom rules under Security > WAF > Custom rules. Put the first one above the second.

Rule 1, action Skip (all remaining custom rules):
(cf.verified_bot_category in {"Search Engine Crawler" "AI Crawler" "AI Search" "AI Assistant"})

Rule 2, action Managed Challenge:
(ip.src.asnum in {14061 16509 14618 396982 8075 24940 16276 63949 20473 203020 207990 133499 204287 396356}) and not cf.client.bot and http.host in {"yourstore.com" "www.yourstore.com"}

The numbers in rule 2 are the networks of DigitalOcean, Amazon Web Services, Google Cloud, Microsoft Azure, Hetzner, OVH, Akamai Linode and Vultr, plus the four networks of the HostRoyale proxy service and Latitude.sh, which we added after finding them in our own GA4 hits. Check your own Security Events before you turn it on, because some B2B buyers and payment callbacks come from cloud networks. Swap yourstore.com for your own storefront domains, so the rule leaves a help desk or other subdomain alone.

Rule 2 as we first set it up on our own site, before we added HostRoyale and Latitude.sh. We limited it to the storefront hostnames, so a help desk or other subdomain is left alone, and added the exception for Amazon's AI assistant.

To find the networks behind your own bot traffic, look at who sends your GA4 hits. In Cloudflare, open Security, then Analytics, set the last 24 hours, filter to the path your GA4 hits use, and group by source ASN. That path is your Google tag gateway path, or /g/collect if your tags send through your own domain. If your GA4 hits go straight to Google, Cloudflare never sees them, so group your page requests by ASN instead. Any hosting or proxy network near the top that is not a home or mobile internet provider is a candidate for rule 2.

We did this on October 19, after the bots changed disguise for the second time in three days. A proxy network called HostRoyale sent 919 of about 2,400 GA4 hits in 24 hours, more than Google's crawlers (483) or Facebook's (422). Its visits rotated realistic phone identities, from older and newer iPhones to an Oppo and a Pixel 9, with screens and platforms that matched, so no check inside the browser could catch them. We added HostRoyale's four networks and Latitude.sh to rule 2, and the challenges started within minutes.

GA4 hits on our site by network over 24 hours. HostRoyale sent more than Google or Facebook, while the largest home internet providers sent 30 to 50 each.

We left M247 out of the rule, because consumer VPNs use it. That is also why rule 2 challenges instead of blocking: most real people on a VPN or a cloud network pass a managed challenge, and most bots don’t.

Despite all the above, no single step is enough on its own, and our own site showed why in one week. The bots changed disguise twice, from 800x600 and square screens, to fake iPhones at 375x812, to realistic phones on a proxy network. The GTM blocker in step 1 caught the cheap tells within a day, and the network rule in step 4 caught what GTM could not.

Country blocks cost us more than they saved. The blocks we set against the Singapore traffic also blocked Google and AI crawlers, Perplexity stopped updating its index of our site, and our favicon disappeared from Google results for weeks until we removed them on August 19. If you want to drop/block a country, do it in your tracking, not in Cloudflare, so Google and the AI crawlers can still reach the site. It also drops any real visitors from that country, so only do it if you don’t sell there.

What does not work?

Shopify does block some bots before they reach a store. Every store uses default Cloudflare firewall and DDoS protection, hCaptcha guards contact, comment and account forms by default, and Shopify Plus stores can turn on bot protection for checkout during sales. Shopify Analytics also labels every session as human or bot and, since its September 2026 update, leaves bot sessions out of its session reports by default. However, that filter only cleans Shopify's own reports: Shopify's help page says it filters bots instead of blocking them, and that it leans toward missing a bot over mislabelling a customer. The bots in this study got past all of it. 57 of the Shero stores and all 687 Littledata stores are on Shopify, and the bots still loaded their pages and fired their GA4 tags.

How reliable are these results?

The results stayed consistent across weeks and across reasonable changes to the rules. The median Shero store came in at 2.4%, 1.8% and 2.5% in the three weeks. Whereas the stores with the most bot traffic in September were mostly the same stores in October.

Each row below changes one rule and keeps the rest. The events per session cutoff has the largest effect, and the study keeps 4 because a page load with no interaction fires page_view, session_start and first_visit plus at most one more event.

The 5% line for an affected store is a choice too. At 3% the count is 194 Littledata stores (28%) and 43 Shero stores, and at 10% it is 64 (9%) and 22.

A blind spot we found after the study

The 4 events cutoff assumes a standard GA4 setup. Some stores send extra events on every page, and on those stores a bot that loads one page fires five to eight events and slips past the rule. A large bot sitting right at the line slips past it too: the Singapore bot on Macintosh at 1366x1366 averaged 4.1 to 4.2 events per session on two Shero stores in the week ending October 4 and was missed on both, about 425,000 sessions between them. The sensitivity table points the same way, with the count of affected stores rising from 37 to 55 when the cutoff moves to 5 events.

We also tested a revised rule that also treats a group as bot-like when it sees one page per visit, plus one identity rule for a single place and device sending at least 1% of a store's traffic without engaging. On the same 100 stores it found 48 affected stores instead of 37, and after the new-user check 4 of 456,346 orders fell in the flagged groups, against 1 for the study rules.

The study used the original rules on both sets of stores, so they are measured the same way. On stores like the two above, the study rules undercount the bots. The free bot check further down uses the revised rules, which also catch bots that fake extra events.

Check your own store in a minute

We turned the study's classifier into a free bot check at sherocommerce.com/pages/seo-tools/ga4-bot-check. It takes two steps:

1. In GA4, go to Admin > Property access management > Add users, paste the email shown on the page and choose Viewer.
2. Paste your GA4 Property ID (Admin > Property details) and click Check my store.

The free GA4 Bot Traffic Check. Give it read-only access, paste your Property ID, and the result comes back in about a minute.

You get one number, the share of your last 7 days of sessions that look like bots, and one verdict: Looks clean (under 1%), Keep an eye on it (1% to 5%) or Fix this now (5% or more). Below it you see where the bots come from and the two or three fixes that apply to your store. The check only reads your own data, leaves returning buyers out (finding 2), and you can remove the email as soon as you are done.

The fixes come with two ready made tools:

• Bot blocker for Google Tag Manager. The step 1 variable and blocking trigger in one bot blocker file. We tested it in a separate container: the stand-in GA4 tag fired for a normal Chrome visit and stayed blocked for default headless Chrome, a stealth bot at 800x600 a stealth bot on a square 1366x1366 screen, and stealth bots dressed up as an iPhone X and a Pixel 5. It covers tags installed through Tag Manager, so if GA4 comes from a Shopify app instead, the server-side move in step 2 is the fix that applies.
• Weekly bot report for Looker Studio. If the above is too tedious, I have built a Looker Studio Bot Traffic Report: open it, pick your GA4 property and look at the red rows. It uses your own Google login, so nobody else sees your numbers.

Explore the dataset

The full dataset is here in the downloadable workbook. It has the summary for both sets of stores, every Shero store as an anonymized row for all three weeks, the distribution and size cuts, the signature table, the false positive check, the sensitivity and stability tables, and a glossary.

The Summary tab of the workbook, with both sets of stores side by side.

Filter it, pivot it and publish your own cut. If you use it, please credit Shero Commerce and link back to this article.

Conclusion

Bot traffic in GA4 has a mechanism, and each route has a fix. Block headless browsers in the tag manager, keep the measurement ID on the server, exclude the rest with a segment that requires new users and gets a weekly review, and leave the crawlers you want alone.

On the median store the bots are a rounding error. On the 19% to 37% of stores above 5%, they change the conversion rate, the channel mix and the engagement numbers your team reads every Monday.

To remediate this issue, start with the bot check. If it says Fix this now and you want help with the fixes, reach out through our contact page and we will tell you which of the four steps to start with.

Frequently asked questions