Headless Browser Traffic: Signs Worth Checking in Server Logs
Headless browsers drive a lot of scraping and credential testing, and they leave traces in logs that a user agent string alone will not show. The signals analysts actually check.
A headless browser is a real browser with nobody sitting at it: Chrome or a similar engine, driven by a script, loading full pages, running JavaScript, clicking and scrolling on command. That makes it the tool of choice for scraping that needs to render pages properly, and for testing stolen credentials against login forms at scale.
It also makes headless traffic harder to spot than a simple script. The user agent often claims to be ordinary Chrome on ordinary Windows. The tells are elsewhere: in inconsistencies between what the request claims and what the browser actually does, and in behaviour no shopper produces.
Inconsistencies are the first tell
A real browser is a coherent object. Its user agent, its supported features, its graphics capabilities, its language and timezone settings, and the order and content of its request headers all belong to the same machine. Automated setups cut corners somewhere in that stack. A user agent claiming a recent Chrome with a feature set from an older build. A desktop user agent with no plugins, no fonts, and a graphics renderer that belongs to a virtual machine.
Individually, each oddity has innocent explanations, which matters. Privacy tools, older hardware, and corporate builds all produce strange fingerprints. Analysts score combinations rather than convicting on one signal, and any store acting on this should do the same before blocking anything. The pattern across signals is the evidence, not any single flag.
Behaviour gives it away over time
Watch sequences, not single requests. Headless sessions often move with mechanical regularity: identical gaps between actions, no idle time, no backtracking, no typing corrections, pages visited in sitemap order or alphabetical order. A scraper working a catalogue has a shape, and that shape repeats across sessions from different addresses, because the same script wrote them all.
Volume patterns help as well. Credential testing, for example, produces many login attempts with very low success, spread across addresses to stay under per address limits, often against accounts that have never logged in from that geography. Rate limiting per address alone will not catch it. Looking at failure rates across the whole login endpoint, segmented by these behavioural marks, is what makes it visible.
What to do with a suspicion
Log first, block later. Capture the signals, the addresses, the sessions, and the outcomes, and build the case over days. Blocking on a hunch teaches the operator which signal you caught, and they will fix that one and return. A quiet observation period usually reveals the full shape of the operation, including the address ranges and the target pages, which makes the eventual block far more complete.
Where the traffic is hitting login or checkout, bring in the controls that raise cost without punishing shoppers: challenges applied to the suspicious segment rather than the whole site, velocity limits on failures rather than attempts, and alerts on success after long failure runs, which can indicate an account takeover in progress. Blanket challenges for everyone, all the time, mostly challenge your customers.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Not All Bots Are Waste: Separating Search Crawlers and Monitoring From Scraping, Bots in Your Wishlist Data: When Favourites Stop Meaning Demand, and Scrapers That Hit Size Guides, Stock Feeds, and the Quiet Corners.
Frequently asked questions
What is a headless browser?
A full browser engine, usually Chrome based, run without a visible interface and controlled by a script. It renders pages and runs JavaScript like a real browser, which makes it useful for scraping and automated account testing.
Why is headless traffic hard to detect?
Because it is a real browser, so simple checks like user agent strings look normal. Detection relies on inconsistencies between claimed and actual browser properties, and on behavioural patterns across sessions.
Can one strange signal prove a visitor is a bot?
No. Privacy tools, older devices, and corporate setups produce odd fingerprints innocently. Analysts combine several signals and behavioural evidence before acting, and stores should check suspected segments against real orders before blocking.
What should a store do when it suspects headless abuse?
Observe and log first to learn the operations full shape, then apply targeted controls to the suspicious segment: velocity limits on failed logins, selective challenges, and alerts on suspicious successes, rather than blanket friction for all shoppers.