Headless Browsers and Fake User Agents: How Bots Pose as Customers

A fake user agent is the cheapest disguise available, and it is the reason bot traffic can land on your page looking like a customer on an iPhone in Manchester. The user agent is just a text string the browser sends with every request, saying what it claims to be. Nothing verifies it. Any script can set it to anything. That one fact explains most of the confusion advertisers have about why their traffic reports look normal while their conversion rate does not.

For the wider picture of what this traffic costs an account, see our overview of bot traffic in Google Ads. This page is about the specific disguise.

What a headless browser actually is

A headless browser is a real browser running without a visible window. Same rendering engine, same JavaScript execution, no screen. It was built for legitimate reasons and is used for legitimate work every day: automated testing, screenshot generation, page monitoring, scraping that site owners have agreed to.

The thing that makes it useful for testing is the thing that makes it useful for fraud. A headless browser is not a crude script that fetches HTML and leaves. It loads your page properly. It runs your tracking tags. It fires your analytics. As far as most of your stack is concerned, something arrived, rendered the page and executed the JavaScript, which is exactly what a person does.

That is a meaningful step up from the older generation of automation. A simple request-based bot never ran your JavaScript, so it never appeared in analytics that depend on it. A headless browser does appear, and it appears as a session.

Why fake user agent bot traffic is so hard to spot

Put the two together and the disguise gets thorough. The script declares itself as Chrome 130 on Android. It runs a genuine browser engine, so the page renders. It sets a screen size that matches a common handset. It can be told to wait a few seconds, scroll part of the page, and move the pointer in a way that is not a perfect straight line.

Now compare that to the declared crawlers. A search engine bot puts its name in the user agent and behaves consistently. It is easy to identify precisely because it is not trying to hide. The industry calls that general invalid traffic, and it is filtered routinely. Everything described in this section is the other category: sophisticated invalid traffic, which is defined by the fact that it actively conceals what it is.

The practical consequence for you is that no single field in your logs answers the question. The user agent says Chrome. It is not Chrome, but the string cannot tell you that, because the string is whatever the sender typed.

What this traffic looks like from your side of the glass

You will not identify it by inspecting one visit. You identify it by noticing that a group of visits behaves in a way people do not.

• Uniformity. Real customers vary. They read at different speeds, scroll to different depths, hesitate in different places. A batch of sessions that all last a similar length and stop at a similar point is a machine doing the same job repeatedly.
• Engagement that stops short. The page loads, something scrolls, nothing is clicked, nothing is typed, the session ends. It reads like interest and produces none of the behaviour interest produces.
• Device profiles that do not match your market. Sudden volume from a browser version or handset combination that barely exists in your customer base.
• Timing that ignores human schedules. Steady traffic overnight in a business where nobody buys overnight.
• Form fills with correct shape and wrong content. Valid-looking phone numbers that do not connect, addresses that do not exist, job titles assembled from a word list.

Any one of those has an innocent explanation. A cluster of them, arriving together, does not.

Why the cost is worse than it looks

Because a headless browser runs your tags, this traffic ends up inside the numbers you plan with. It inflates sessions, drags engagement metrics down, and shows up as demand that failed to convert. You then treat that as a message about your landing page or your keyword, and you act on it.

Meanwhile the click has already consumed part of your daily budget. Google does issue automatic credits for clicks it classifies as invalid, and those credits are real, but they arrive on the next month's bill and they only address the charge. We set out the full extent of that gap in what Google's invalid click refunds actually cover. The short version is that getting the money back does not undo the session, the skewed metric or the bidding signal.

What you should not do about fake user agent bot traffic

The obvious instinct is to start blocking on the user agent string. Resist it, for two reasons.

First, it does not work on the traffic you care about. Blocking a user agent blocks anything honest enough to use it. The bots in this article are not honest. They will present whatever string is most common in your logs, which by definition is the same string your real customers use. You cannot block that.

Second, you will break things you need. Googlebot and AdsBot-Google identify themselves in the user agent, which makes them the easiest thing in your logs to block by accident. Block them and you lose organic indexing and your ad landing page checks start failing, which is far more expensive than the fraud you were chasing. Our guide to the crawlers you must never block covers which ones need clear access.

The useful approach works from behaviour and context across many visits rather than from one declared field, and it runs continuously, because the disguise changes faster than a manual list can. That is the job click fraud protection does.

AI Agents Are Blurring the Line

A newer source of automated visits has nothing to do with fraud rings. AI assistants and browsing agents can now open pages, read them and sometimes click through on a person's behalf. Some identify themselves honestly. Others run inside an ordinary browser and look much like a person reading quickly.

For an advertiser the question is the same one you ask of any automated visit: did a paid click lead somewhere a customer could follow? An agent that clicks an ad while researching for someone may be closer to a lead than a bot, or it may burn a click and never return. The practical response is not to block every unfamiliar browser, which catches real people, but to judge sources by what they do after the click across repeated visits.

The takeaway

Stop treating the user agent as evidence of anything. It is a claim, not a fact, and the traffic worth worrying about knows that better than you do. What a headless browser cannot fake convincingly is being a customer: it does not read, hesitate, change its mind, or buy. Judge your traffic on what it did, not on what it said it was.

Frequently Asked Questions

Is every headless browser visit ad fraud?

No. Monitoring services, search engine renderers, testing tools and accessibility checks all run headless browsers for legitimate reasons. It becomes a cost when that traffic arrives through paid clicks and never behaves like a buyer.

Why do bots fake their user agent?

Because the user agent is just text the browser sends, and changing it is free. Claiming to be a common phone browser gets a bot past filters that only read that label.

Can IP exclusions stop headless browser traffic?

Partly. They stop your ads showing to addresses you have identified, which handles repeat sources. Traffic that rotates addresses keeps arriving from new ones until each is spotted.

Does Google catch this traffic on its own?

Some of it. Google filters invalid traffic before billing and credits invalid activity it finds later. The disguised traffic that looks like a real visitor is the part most likely to be billed.