How to Keep Bot Traffic Out of GA4 and Your CAPI Reports on Magento 2

TL;DR

Three releases built the behavior a Magento 2 store gets today, and knowing which one you are on decides what you can configure. A fixed server-side exclusion has been there since early 2024. A frontend flag arrived in May 2026 for a different problem and was pulled in September 2026, because Full Page Cache turned one crawler hit into suppressed tracking for every real shopper served that cached page. What remains is a per-request server filter you can edit, one exception that protects your revenue numbers, and a limitation worth understanding before you start adding patterns: the list catches crawlers that say who they are.

Key Takeaways

• Measurement Protocol bot exclusion is not new. v1.12.17, January 12, 2024, excluded the most common bots and crawlers from being tracked through the Measurement Protocol [1].
• v1.17.0, May 18, 2026, added frontend bot detection against Googlebot and AdsBot crawls that caused CPU load and lower-quality data [1].
• v1.17.4, September 1, 2026, removed that client-side flag and added server-side bot filtering with a merchant-editable list of user-agent patterns, keeping crawler traffic out of Conversions API reports [1].
• The flag was removed because it was rendered into the page and stored in Full Page Cache, so a single crawler could suppress tracking for every real shopper later served that cached page. Filtering is now evaluated per request on the server [1].
• Order events are always sent, since a completed order is a real conversion regardless of the user agent [1]. This filter can never be the cause of a missing purchase.
• The pattern list is shared across every Conversions API addon in the bundle [7], and the addon change logs describe it as stopping self-identifying crawlers [2]. A crawler that disguises its user agent is outside its reach.
• GA4 runs its own known-bot exclusion using Google research plus the International Spiders and Bots List maintained by the Interactive Advertising Bureau, and Google states that you cannot disable it or see how much known bot traffic was excluded [3].

The three releases behind today's behavior

Most write-ups on this feature start in September 2026, which gets the story backwards and leaves a reader thinking nothing was filtered before. Here is the actual sequence.

The middle row addressed a different problem. The 2024 change was about data quality in the server-side stream. The 2026 frontend flag was about crawlers making the store work harder and leaving low-quality data behind. They overlapped in subject and not in purpose.

The practical upshot: on any release from v1.12.17 forward, some server-side bot exclusion has been running the whole time, on a fixed list you never saw. Only from v1.17.4 do you get a list you can edit. Getting to that release on a store with patches in flight is its own project, covered in our guide to upgrading Magento 2.4.x without breaking your analytics.

Why did the client-side flag have to go?

This is the part of the story worth reading twice, because the mechanism is specific to how Magento serves pages and it is documented in plain terms.

The flag was rendered into the page. Magento caches rendered pages in Full Page Cache. So the first visitor to a given page could be a crawler, the flag would be written into the HTML that got cached, and every real shopper later served that cached page inherited it. One crawler hit, tracking suppressed for everyone downstream. The change log states the consequence and the fix together: filtering is now evaluated per request on the server [1].

Nothing about that failure is visible in a report. Traffic would simply be lower on the cached pages, in a pattern that looks like seasonality or a Googlebot-shaped dent in one template. If you ran v1.17.0 through v1.17.3 with the frontend flag enabled and you have an unexplained tracking dip in that window, you now have a candidate explanation and a date range to check it against. Anything conditional that gets rendered into cacheable HTML is a decision made once and served many times, which is worth remembering past this one feature.

Which crawlers belong on the list?

Start from Google's own published tokens rather than a list you found on a forum, because Google updates theirs and forums do not.

The common crawlers include Googlebot, Googlebot-Image, Googlebot-Video, Googlebot-News, Storebot-Google, Google-InspectionTool and GoogleOther [5]. Storebot-Google is the one ecommerce operators overlook, and on a store it is the crawler most likely to be walking product and checkout paths.

The special-case crawlers matter more, and for a reason that surprises people. AdsBot-Google, AdsBot-Google-Mobile, Mediapartners-Google and APIs-Google all ignore the global robots.txt * wildcard, and Google-Safety ignores robots.txt rules altogether. AdsBot exists to check the quality of your ad landing pages [6]. So the crawler class most likely to hammer the exact pages you paid to send traffic to is also the class a blanket robots.txt rule does not keep off your store.

Put those two facts side by side and the value of an editable pattern list becomes concrete. The list is the lever precisely where robots.txt is not. If you run search ads to product pages, AdsBot-Google and AdsBot-Google-Mobile are the first two patterns to consider, and no robots.txt edit substitutes for them.

One limit to hold onto while you build the list. Google documents three identification signals for its crawlers, the user-agent header, the source IP and the reverse DNS hostname, and its published verification procedure is built on reverse DNS and IP ranges [4]. The extension's list works on user agents, which the addon change logs describe as stopping self-identifying crawlers [2]. A bot that lies about its user agent is not in scope for this feature, and no pattern you add changes that.

What this filter does not touch

GA4 runs its own exclusion before you configure anything. It automatically excludes traffic from known bots and spiders, identified by a combination of Google research and the International Spiders and Bots List maintained by the Interactive Advertising Bureau [3]. Two consequences follow, and both are Google's own words: you cannot disable known bot traffic exclusion, and you cannot see how much known bot traffic was excluded [3].

That second clause is the honest reason you cannot reconcile the two layers. There is no number to compare against. The extension's filter operates on your server, before a request goes out. GA4's exclusion operates inside GA4. Joining them into a single accounting is not something the documentation on either side supports, so resist the urge to try.

What the extension's filter does give you is control over what leaves your infrastructure in the first place, which is the only layer where a Conversions API report can be protected.

Can bot filtering explain a missing purchase?

No, and this is the cleanest thing about the feature. Order events are always sent, since a completed order is a real conversion regardless of the user agent [1].

That exception is worth more than it looks. Revenue-gap investigations on Magento 2 are long, because there are many places an order event can be lost. This filter is not one of them, so you can rule it out in one sentence and spend your time on the causes that are real. The configuration those causes live in is mapped in the complete server-side setup guide.

The mirror problem is traffic you lost, which is a different investigation with different levers. Our article on ad blockers and what server-side actually recovers is the one for that side, including its refusal to attach a recovery percentage to it.

What to do this week

1. Check your version. Below v1.17.4 there is no editable list, and the frontend flag from v1.17.0 may still be in play on cached pages [1].
2. Look at your sessions by user agent or your access logs for the tokens above, with Storebot-Google and the two AdsBot variants first.
3. Add patterns for the crawlers you can actually see hitting the store, not the full published list. A pattern for a crawler that never visits you is noise in a config screen.
4. Confirm what reaches GA4 afterwards rather than assuming. DebugView, the log file and the order grid column are covered in our guide to verifying GA4 events on Magento 2.
5. Re-read your robots.txt with step three in mind, knowing the AdsBot crawlers ignore the global wildcard [6].

FAQ

Does this replace GA4's own bot filtering?

No. GA4's known-bot exclusion runs automatically inside GA4, cannot be disabled, and does not report how much it excluded [3]. The extension's filter runs on your server before events are sent. They are two layers at different points in the path.

Will filtering bots reduce my server load?

That was the stated purpose of the v1.17.0 frontend flag, aimed at crawls causing CPU load [1], and that flag is gone. The v1.17.4 change log describes the server filter in terms of keeping crawler traffic out of Conversions API reports [1]. Treat it as a data-quality control.

What happens if a bot completes a checkout?

The order event is sent. Order events are always sent, since a completed order is a real conversion regardless of the user agent [1]. If you are seeing fraudulent orders, that is a fraud problem rather than a tracking one.

Can I catch crawlers that hide what they are?

Not with this. The addon change log describes the list as stopping self-identifying crawlers [2], so anything disguising its user agent needs a different tool.

I am on v1.17.2 and I see a tracking dip. Is this it?

It is a candidate. The client-side flag was rendered into the page and stored in Full Page Cache, so a single crawler could suppress tracking for every real shopper later served that cached page [1]. Compare the dip's start against your cache lifetime and your crawl logs, then get to v1.17.4 or later.

Server-side bot filtering with an editable pattern list is part of the server-side layer in the Magento 2 Google Analytics 4 extension, a PRO capability, currently v1.17.5, released September 16, 2026 [1]. The September 2026 release notes cover what else shipped in that version.

Before you add a single pattern, open your access logs and find out which crawlers are actually there. Most stores are filtering a list copied from somewhere else, aimed at bots that have never visited them.

Sources

1. WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
2. WeltPixel Pinterest Addon User Guide and Change Log, v1.17.4, September 1, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/PinterestAddon/User-Guide-WeltPixel-Pinterest-Addon.html
3. Known bot-traffic exclusion, Google Analytics Help, retrieved September 21, 2026, https://support.google.com/analytics/answer/9888366
4. Overview of Google crawlers and fetchers, Google Search Central, page last updated June 12, 2026, retrieved September 21, 2026, https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
5. Google common crawlers, Google Search Central, page last updated July 14, 2026, retrieved September 21, 2026, https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers
6. Google special-case crawlers, Google Search Central, page last updated September 17, 2026, retrieved September 21, 2026, https://developers.google.com/search/docs/crawling-indexing/google-special-case-crawlers
7. WeltPixel Suite PRO User Guide and Change Log, v1.17.4, September 1, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/SuitePro/User-Guide-WeltPixel-Suite-Pro.html