Hotjar applies bot and automation detection against the User-Agent string and other signals to avoid recording and billing non-human traffic. This legitimately blocks real automated tools - scrapers, headless test runners, some corporate proxy or security software that rewrites the User-Agent header - but can also false-positive on real users behind aggressive corporate proxies or unusual browser configurations.
Why this happens
Session-recording and heatmap vendors have a strong incentive to exclude bot and script traffic from both billing (session-based pricing) and analytics (a recording of a scraper is not useful UX data), so Hotjar runs client-side detection flagging browsers that show automation signatures: known automation keywords in the User-Agent, headless Chrome/Puppeteer/Selenium fingerprints, or missing browser APIs real browsers always expose.
That detection is necessarily heuristic, not perfect, so it occasionally flags real human traffic sharing a signal with automated traffic - most often through corporate security tools or internal QA automation that a security team did not realize would also hit the production Hotjar snippet.
Fix it
- If the block affects your own internal QA/testing traffic, check whether it is a genuine headless browser tool (Puppeteer, Selenium, Playwright default configs) - these commonly report automation-flagged User-Agents by design, and the fix is to exclude test environments from loading Hotjar at all, not to "unblock" them.
- If real customer traffic is affected, check with your network or security team whether a corporate proxy or endpoint security tool is rewriting or stripping the User-Agent header - the most common cause of false positives on legitimate traffic.
- Confirm you are not loading Hotjar in a server-side-rendered or prerendering context - some SSR/prerender crawlers report bot-like User-Agents; gate the snippet to client-side-only rendering.
- There is no supported client-side override to force Hotjar to ignore its own bot detection for a specific User-Agent - if real traffic is being excluded at scale, that is a case for Hotjar support with specific examples, not a workaround to build yourself.
- Separately verify the flagged traffic is not actually bot traffic mislabeled as legitimate - cross-check its behavior pattern against genuine human sessions before assuming false positive.
How to verify it worked
Load the site in a standard, non-automated browser session (no dev-tools automation flags, a real User-Agent) and confirm Hotjar records normally - this isolates whether the block is genuinely about the automation signature versus a separate, unrelated issue like CSP or an ad blocker.