Bot Form Fills Are Counting as Conversions in GA4. Here's Why You Can't Filter Them Out.

A contact form lead just came in. The name is gibberish, the message is a wall of links to a site you've never heard of, and the email bounces on the first reply. Annoying, but harmless. Except it isn't harmless, because that same submission just ticked your conversion count up by one.

You marked form_submit as a Key Event, so GA4 wrote that bot a conversion. And once GA4 counts a conversion, no setting un-counts it. Not a filter, not the referral list, not even a data deletion request. Here's why, and what stops the junk before it counts.

A quick note on who I am and what I'm not selling you. I build Clickport, a privacy-first analytics tool. It helps with this exact problem by scoring the visitor before the event is allowed to count, so obvious automated form spam never becomes a conversion in the first place. It's not a CAPTCHA, it's not a firewall, and it can't fix a conversion that's already sitting in GA4. No tool can. I'll be straight about that line the whole way down. Think of this as the numerator companion to a piece I wrote on clicks but no conversions, which is about the denominator, the paid clicks that never convert. This one is the opposite problem: the fake conversions that do.

How a bot form fill becomes a permanent conversion in your count

A form submission becomes a conversion the moment you mark form_submit as a Key Event. GA4 then counts it every time it fires, with no check for whether a human or a bot sent it. The bot's submission and the buyer's submission land in the same total.

You create the conversion yourself. In GA4 you toggle "Mark as key event" on an event, and from that point GA4 counts every firing of that event as a key event, which is GA4's conversion metric and the action you feed to Google Ads for bidding. The default counting method is "once per event", which counts a key event every time it's triggered. Google's own example: five triggers in a session count as five. So a bot that hammers your form five times doesn't get deduplicated. It writes five conversions.

Here's the part that does the damage. GA4 attaches no real-versus-bot score to the event before it counts. There's no field on the form_submit that says "this came from a headless browser in a data center." The bot's event and the buyer's event are written into the same conversion number, and from that moment they're indistinguishable.

This isn't a traffic problem. It's a conversion problem. The junk doesn't just pad a sessions chart. It lands in the top of your conversion-rate fraction and in the exact number your ads optimize against.

That gap is real, and people hit it constantly. One Contact Form 7 site owner reported Google Ads showing more than 100 conversions a day while genuine enquiries were a couple a week. The plugin fired form_submit on every submission, real or not.

None of this is about how you set form tracking up. If you want that, I wrote a separate guide to tracking form submissions. This is about what happens after the setup is correct and a bot uses it against you.

Why one fake conversion is worse than one fake visit: it trains your ads

A fake visit pads a chart. A fake conversion changes what your ads do next. Smart Bidding uses Google's AI to optimize for conversions in every single auction, and it requires conversion tracking to work. Your conversion count is the training input. Feed it junk and it learns from the junk.

Google says the bidding models learn from your conversion data and refine as more of it accrues. There's no separate path for fake conversions. The model treats a bot's form_submit the same way it treats a buyer's, because to GA4 they're the same.

Search Engine Journal put the consequence well in a piece on primary versus secondary conversions: every primary conversion teaches the algorithm what an ideal customer looks like, and mixing low-intent or junk actions into the primary pool means it "cannot distinguish a buyer's pattern from a browser's pattern."

Put another way: Smart Bidding sees a user who converted cheaply, then goes hunting for more users who behave like that one. If the user was a bot, it goes hunting for more bots. The spam doesn't just sit in a report. It becomes your targeting.

Now the obvious question. If the bot is in the count, why not just take it back out? Let's walk through every repair you'll reach for, in the order most people try them.

Repair 1: reCAPTCHA or a honeypot. Why it doesn't clean the count

reCAPTCHA v3 never blocks a submission. Google's own documentation says it "will never interrupt your users" and instead returns a score from 0.0 to 1.0 that you have to act on in your own backend. By the time that score comes back, the form_submit has already fired and the conversion is already counted.

Real teams run into this. In an Adobe Marketo community thread, bots that reCAPTCHA scored as suspicious still showed up as successful form fills, and the vendor confirmed v3 is passive scoring, not blocking. A honeypot has the opposite weakness: it's a hidden field that's invisible to humans and zero-friction, but advanced bots detect and skip it, and if the honeypot passes, the conversion fires anyway. These are UI-layer fixes, not count fixes.

There's a nastier failure in the other direction. reCAPTCHA relies on the _grecaptcha cookie, and privacy browsers, ad blockers, and consent tools block it, so real visitors silently fail to submit and their genuine conversion never gets reported. So the CAPTCHA route can both miss bots and suppress humans.

Repair 2: Google Ads invalid-traffic credits. Why the fix never reaches GA4

Google does detect some invalid traffic, and it will credit you for it. But read the wording carefully: invalid traffic results in credits and adjustments, not a refund. Those credits show up as "Invalid Activity" line items in your Google Ads billing. Every bit of it happens inside Google Ads. The GA4 conversion count is never touched.

So you can be made whole on the wasted spend and still have an inflated analytics number quietly training Smart Bidding off the same junk. This is the mirror of the clicks-but-no-conversions problem, where the invalid-click figure is stuck in Ads billing. Here it's the invalid-conversion that Ads credits never remove from GA4.

There's one Ads-side move that gets closer, and I want to be fair about it. You can upload a list of GCLIDs to exclude, which removes the optimization data tied to them and scrubs those conversions from the bidding signal. That genuinely cleans the training pool. But it's reactive and per-lead: you identify each spam GCLID after it converted and after it spent, then upload it, by hand, forever. And even when it works, it only touches Google Ads. The GA4 conversion count that the rest of your reporting and your conversion rate run on never changes.

Repair 3: GA4 filters and the unwanted-referrals list. Why they're forward-only

GA4 data filters only act on data going forward. Google's documentation says filters are evaluated from the point of creation onward and do not affect historical data, and that excluded data is never processed and never recoverable. The bot conversion you already have sits there untouched.

The unwanted-referrals list works the same way. Google's own worked example shows a session that happened before you added a domain stays attributed to that domain. Adding to the list only changes future events. GTM exception triggers are the same shape: they stop a tag from firing next time, not retroactively.

So every tool in this bucket is a future-tense fix sitting in front of a past-tense problem. And they only help at all if you can match the bot in advance, by its user-agent or its referrer. The disguised ones, the headless browsers wearing a normal Chrome user-agent, give you nothing to match on.

Repair 4: GA4 data deletion. It strips the text, not the count

A data deletion request is the most aggressive cleanup GA4 offers, and it still can't remove a conversion. The documentation is blunt about it. When you delete data, "the specific text data will be erased and replaced with (data deleted), but the event will still be counted in the overall metrics in your reports."

Read that again. GA4's nuclear option removes the gibberish name and email the bot typed, and leaves the conversion. The number is permanent.

This is the same lesson I ran into when I tested GA4 against 1,000 bots: what matters is blocking before storage, because filtering after storage can't reclaim the count. By the time a bot's event is in GA4, the only honest thing left to do is stop the next one.

So that's the whole toolbox. The CAPTCHA fires too late or breaks real conversions. The Ads credit never reaches GA4. The filter is forward-only. The deletion strips the text, not the count. Four tools, and the bot conversion is still sitting in your report.

The real reason none of it works: GA4 has no bot score on the event

Every repair fails for the same reason. GA4 never asks whether the visitor behind an event is a bot before it counts the event. Its only built-in defense is a list of known bots.

GA4 identifies known bots using a combination of Google research and the IAB International Spiders and Bots List. You can't turn it off, and you can't see how much it excluded. More to the point, it's a list, not a behavioral score. The IAB list is matched mostly on the user-agent string a bot declares, so it only catches bots that honestly announce themselves. A headless Chrome bot sending a normal Chrome user-agent isn't on the list, and its form_submit counts like anyone else's.

Independent write-ups say the same thing: GA4's filter doesn't catch sophisticated invalid traffic that mimics humans, rotates IPs, or uses residential proxies, so the bot share GA4 shows you is an undercount. The number you see is the floor, not the ceiling.

This is the whole story in one line. Because there's no real-versus-bot score attached to the event at the moment it's counted, every after-the-fact control is structurally too late. The only place to fix it is before the count, at ingestion. For more on how that filter works, I went deep in is my website traffic real or bots and how bot detection works.

What scoring the visitor before it counts looks like, and what it can't do

The fix has to happen before the event is counted, not after. That means scoring the request when it arrives and dropping the obvious bots before they ever become an event. This is where a cookieless tool like Clickport works differently from GA4.

Clickport scores the request server-side at ingestion, and blocked events never reach the database. So an obvious automated form fill is rejected before it can ever become a counted conversion. It's a gate in front of the count, not a filter behind it. The signals it checks are exactly the ones GA4's user-agent list never sees: the WebDriver automation flag, a software-GPU render fingerprint (the SwiftShader and llvmpipe renderers that headless Chrome falls back to), missing browser languages, instant execution timing, and datacenter IP ranges.

Here is what that looks like in the dashboard. Because the bot submissions never became events, the contact form goal counts only the humans.

That contact form goal shows 38 real conversions. GA4's Key events report showed 312 for the same form the same week. The other 274 were bot submissions, scored and dropped before they could become events, so they never counted here.

The bots that would have filled that gap show up on the other side, in Bot Protection, where they were stopped and sorted by the signal that caught them.

Now the honest part, because I promised it. This is not a CAPTCHA and it's not a firewall. It won't block every bot. A sophisticated bot on a residential proxy that scrolls, waits, and clicks like a person still gets through, the same way it gets past everyone, because it doesn't look automated. And it can't un-count anything already sitting in GA4. No tool can. The edge is narrower than "we stop all the bots," and more useful: the obvious automated form spam never becomes a counted conversion, and you can see the real-versus-bot split on your form submissions instead of guessing at it.

How much GA4 actually misses

So how much of this does GA4 wave through? Across the sites we measure, the median site has 80.3 percent of the bots we block caught by signals GA4's user-agent list never checks: the render fingerprint, the datacenter IP, the execution timing. Put another way: on a typical site, roughly four out of five of the bots we stop would have counted as real visitors in GA4. It ranges from 31 percent to 99 percent depending on the site.

Headless Chrome is the single biggest category, a median of 57.6 percent of what we block. That matters here because headless Chrome is exactly the profile that wears a normal Chrome user-agent and fills out forms while looking like a person to GA4.

For the wider backdrop, the Imperva 2025 Bad Bot Report found that, for the first time in a decade, automated traffic passed human traffic in 2024, at 51 percent of the web. And the fraud-detection vendor Anura estimates that one in every four dollars spent on leads is lost to fraud, with global ad fraud forecast to pass 200 billion dollars by 2028. Treat those as vendor estimates, not measurements. My own number is narrower and I'll keep it that way: it's the share of the bots we catch, not a claim about every bot online, and the stealthy residential-proxy tail is in neither figure.

Common questions

Can you exclude bot form submissions from GA4 conversions after the fact?

No. GA4 data filters and the unwanted-referrals list only act on data going forward, and a data deletion request strips the event's text while leaving it counted in your report metrics. Once a form_submit is marked as a Key Event and fires, that conversion is permanent. You can reduce future spam, but you can't remove a conversion already counted.

Does reCAPTCHA stop GA4 from counting bot conversions?

Not reliably. reCAPTCHA v3 only returns a score and never blocks the submission, so the form_submit and its conversion tag fire before any score-based action runs. It can also block real visitors when privacy tools strip the cookie it depends on, which suppresses genuine conversions. It's a UI-layer deterrent, not a fix for the count.

Why does Google Ads show far more conversions than real leads?

Because a bot that submits your form fires the same form_submit Key Event a real lead does, and Smart Bidding counts it, then optimizes to find more traffic like it. Invalid-traffic credits refund some spend inside Google Ads, but they never remove the conversion from GA4, so the inflated count keeps feeding the bidding model.

Can GA4 tell which form submissions are bots?

No. GA4's only bot defense is a known-bot list matched on the declared user-agent, which disguised bots like headless Chrome walk straight past. GA4 attaches no real-versus-bot score to the event itself, so it can't show you which conversions were automated.

The cheap thing to do first

A bot in your traffic is noise. A bot in your conversion count is a decision. It changes which campaigns you scale, which leads your sales team chases, and which audience your bidding goes looking for more of. You can't scrub it out after the fact. You can only keep it from counting in the first place.

So before you bolt another CAPTCHA onto the form, do the cheap thing first: find out how many of your form_submit conversions were even human. You can't un-count the ones already in GA4, nobody can, but you can stop the obvious spam from ever counting again and finally see the real-versus-bot split on your conversions. Try Clickport free. No cookie banner, no setup marathon. I answer every email, so if your conversion count looks too good to be true and you can't work out why, write to me.