Every one of these is a real human who may be scored as a bot. Read this before acting on any single verdict.
Never act on the score alone. Look at the reasons and ask whether that specific combination describes a person you would recognise. A session called a bot on an automation marker is not arguable. A session called likely bot on no-JS plus a timezone mismatch is a privacy-conscious VPN user until proven otherwise.
Ad blockers, script blockers, browser shields, Lockdown Mode, strict tracking protection and corporate proxies all block the beacon. From the transport plane that is indistinguishable from a non-JS client: an HTML 200 served, a real browser User-Agent, and no beacon.
The rule that fires on it is weighted 70 — deliberately below the 80 threshold — so it cannot condemn on its own, but it will push somebody into likely bot if anything else fires. If a meaningful share of your audience is technical, expect this and lower the weight.
A large office, a university, a VPN provider or a mobile carrier can put hundreds of real people behind a few addresses with similar browser builds. The proxy fleet rule excludes mobile networks for exactly this reason — which means an ASN misclassification turns into a batch of false positives.
If a whole organisation is showing up as a fleet, check the network type for their ASN first, before you conclude anything about the traffic.
Screen readers, magnifiers and keyboard-only navigation produce interaction patterns that do not look like mouse-driven browsing. Low mouse-movement entropy is a signal here, and a blind user generates none at all. Treat the no-interaction rule with care.
The engine claim probe assumes a Chrome-family version-to-feature mapping. A forked Chromium, an embedded web view, a browser that deliberately freezes its User-Agent, or a genuinely old build can fail a probe honestly. The rule reports which probe failed for exactly this reason — look at the code before believing the score. The signal codes page has the probe table.
The timezone rule fires on anyone whose browser timezone does not match their exit address, which describes every VPN user and everybody on a plane. It is weighted 35 because it is nearly useless alone.
It is whatever the geolocation service named, and otherwise it is derived from the country — but only where the country has exactly one timezone, which is 216 of the 247 territories the timezone database covers. For the other 31 — the United States, Russia, Canada, Australia, Brazil, Mexico, Indonesia, Kazakhstan, China, Germany and the rest — it is absent unless the service supplied one, and the rule then cannot fire at all. That is deliberate: the comparison is of exact zone identifiers, so picking the most populous zone for a multi-zone country would report a mismatch for everybody outside it — a false positive on a weight-35 rule, manufactured by us, on traffic that did nothing wrong.
- Speculative fetching. Browsers and extensions fetch pages the user never visits. Those look like single-page, no-asset, no-interaction sessions — three weak signals stacking to 80.
- Your own uptime checks. Synthetic monitors and health probes are bots and will be scored as bots, correctly. Filter them by address or by User-Agent rather than wondering why your bot rate is four per cent on a site nobody visits.
- A visitor who leaves in the first few hundred milliseconds. The beacon’s first call is fired immediately, but a browser that tears the page down before the request leaves the socket produces nothing. Those visits appear as no-beacon.
- Interaction inside a third-party frame does not reach the beacon, so a page whose only interactive element is an embedded widget can look interaction-free.
Not false positives so much as blind spots, and worth knowing for the same reason:
- Anything served from a CDN edge, a browser cache or a service worker. Loghound reads your origin’s log. If you run a CDN, you are analysing your cache misses — the beacon partially compensates by firing on cache hits too, which is one of the few places the two planes usefully disagree.
- Requests behind a proxy that does not forward the client address. Every visitor then appears to come from the proxy. Log the forwarded header and set the trusted proxy list.
- API and native-app traffic, unless you also point Loghound at that host’s log. There is no beacon in a native app, so the execution plane is permanently blind there and every client looks non-JS.
- Which human. There is no cookie and no cross-site identifier. The visitor hash is coarse and is intended to be coarse.
- Non-Chromium engine claims. The engine claim check only tests Chrome-family claims; another engine yields an absent result, not a false one.
The other side of this — what a scraper has to do to be wrongly called a human — is evasion.