How websites recognise automated and headless browsers

Websites recognise automated browsers by combining many small signals into one risk score: flags that automation tools switch on, differences in how headless browsers behave, values in the fingerprint that contradict each other, a network handshake that does not match the browser it claims to be, input that moves too fast or too evenly, and an IP address with a poor reputation. No single signal decides. A site weighs them together, then lets the visit through, shows a challenge, or blocks it.

This post walks through each family of signals, why a freshly launched automation browser stands out, what a site's terms have to say, and how to check your own setup.

Why sites look for automation

A large share of web traffic is automated: more than half of it in 2025, according to the Imperva Bad Bot Report (29 April 2026). Some of it is welcome, such as search engine crawlers. Much of it is not, which is why sites protect themselves. Bot-defence services sit in front of many large sites to tell the two apart, and AI agents doing ordinary tasks for their owners now meet the same checks.

The signal families

1. Automation flags

The WebDriver standard asks browsers under remote control to say so: navigator.webdriver reads true (MDN). Automation libraries that launch their own browser also start it with switches an ordinary user never sets, which can change visible details such as an "is being controlled by automated software" bar or default window sizes. These are the easiest signals to read, and most detectors check them first.

2. Headless differences

A headless browser runs without a window. Older headless modes announced themselves in the user agent string, and even modern ones can differ from a headed browser in small ways: screen and window sizes that do not add up, missing media devices or voices, a software graphics renderer in place of a real GPU. A detector that sees a desktop browser with no real graphics card, or a window larger than its screen, has a reason to look closer.

3. Side effects of the control channel

Libraries such as Playwright and Puppeteer drive the browser through the Chrome DevTools Protocol. Some of the protocol's features, when switched on, slightly change behaviour that page scripts can observe. Detectors look for these traces, as well as for objects or functions that automation code adds to the page.

4. Fingerprint contradictions

A browser fingerprint is the set of values a site reads: platform, screen, fonts, graphics, timezone, languages and more (what browser fingerprinting is). Detectors care less about how rare a fingerprint is than about whether it is coherent:

• a user agent that says Mac next to client hints or fonts that say Windows;
• a timezone or language that does not fit the IP address's country;
• a value in the page that differs from the same value read in a web worker;
• a property whose function no longer looks native, the mark of a script that overwrote it;
• canvas or audio output that changes on every read, the mark of random noise.

Tools that change the fingerprint with an injected script are especially prone to the last three.

5. The network handshake

Before any page loads, the browser opens an encrypted connection, and the way it does so (the TLS ClientHello and HTTP/2 settings) has its own fingerprint, often summarised as JA3 or JA4. An HTTP library, or a proxy that ends the encrypted connection and opens its own, produces a different handshake from the browser it claims to be. A site that sees a browser's user agent over a non-browser handshake knows something is off.

6. Behaviour

People scroll, pause, move the pointer in curves and type at uneven speeds. Scripts often click the exact centre of an element instantly, fill a form in one event, or load pages at a steady rate around the clock. Behavioural models score these patterns over the whole visit.

7. IP reputation

Addresses carry history. Datacenter ranges, addresses shared by many users of a cheap proxy, and addresses seen in earlier abuse carry more risk than an ordinary home or mobile connection. Residential, datacenter, ISP or mobile proxies explains how sites see each kind.

From signals to a decision

A bot-defence service turns these signals into a score. A low-risk visit passes untouched. A middling one gets a challenge: an invisible check that runs in the background, a "verify you are human" box, or a CAPTCHA. A high-risk visit gets a block page. Scores also build over time, so a profile that keeps the same coherent identity across visits is judged differently from one that looks new every time.

Why a fresh automation browser stands out

Put the families together and a browser launched straight from an automation library starts with several marks against it at once:

• automation switches and navigator.webdriver set;
• the same fingerprint on every run, and on every parallel worker;
• empty cookies and storage, so every visit is a first visit;
• often headless, often in a datacenter, often acting at machine speed.

Any one of these is common. Together they describe a bot.

What a site's terms allow

Being able to automate a site is not the same as being allowed to. Before you point a script or an agent at a site, read its terms of service, respect its rate limits, and keep to accounts you are entitled to use. Some sites offer an API for exactly the work you want to do; use it. Our acceptable use policy applies to scripts and AI agents the same as to people.

How to check your own setup

You can see much of what a detector sees:

1. Open the browser's developer console in your automated browser and read navigator.webdriver.
2. Run a fingerprint consistency test headed, then headless, and compare every row. Our browser fingerprint test runs locally and sends nothing.
3. Compare the user agent string with the client hints the browser sends.
4. Check the timezone and languages against the country of the IP address your traffic leaves from.
5. Open the same profile twice and confirm its fingerprint stays the same.

How Browz keeps automation from changing the fingerprint

In Browz, every profile's fingerprint is set in the browser engine itself, not by a script injected on top, so there is no overwritten property for a page to catch. Each profile is one consistent device derived from a real device type and a seed; user agent and client hints agree; TLS and HTTP/2 come from the engine's own network stack; timezone and languages follow the proxy's exit. Driving a profile with Playwright, Puppeteer or MCP does not change the device or network fingerprint it presents (anti-detect, measured). Start profiles from Browz, and attach your library to the browser it started rather than launching your own.

The results are published. On 13 November 2026 Browz 0.1.9 on macOS passed 15 of 15 consistency checks in our fingerprint test, headed and headless. On 10 November 2026 an agent in Browz passed 12 of 12 checks on pages protected by Cloudflare Turnstile, DataDome, PerimeterX (HUMAN), Akamai Bot Manager, reCAPTCHA v3 scoring, CreepJS and Fingerprint bot detection (the bot detection results). When a verification check still does not complete, this help article lists what to check; a person completes CAPTCHAs, which Browz hands to you.

Frequently asked questions