Block Bots

StatelessID filters known crawlers and automated traffic so your page view counts reflect real visitors, not indexing runs, uptime monitors, or scraping tools.

How bot filtering works

Most bots never trigger the beacon at all. The tracking script runs inside a browser context — it needs JavaScript to execute, the DOM to be available, and a live page load event to fire. A standard HTTP crawler that fetches raw HTML and moves on never runs the script. Those requests contribute nothing to your counts because the counting mechanism simply never activates.

For bots that do execute JavaScript — headless browsers, synthetic monitoring tools, and some modern scrapers — the server applies a secondary check against a maintained list of known automated user-agent strings. Requests that match the list are recognized as automated and are counted separately rather than being mixed into your page view totals. The main count on your dashboard reflects only requests that passed both checks.

The two-layer approach keeps the false-positive rate low. A legitimate visitor using an unusual browser is not caught by the user-agent list because the list is matched against known automated identifiers, not against browsers that deviate from the most popular configurations.

What counts as a bot

The filter covers the common automated categories: search engine crawlers, site auditing tools, uptime and availability monitors, synthetic performance testers, and known scraping frameworks. The criteria are drawn from the user-agent string the client sends with each request. A tool that sends a recognizable identifier — Googlebot, AhrefsBot, UptimeRobot, and similar — is identified and excluded from your main count.

The list is maintained and updated over time. When a new automated tool becomes common enough to appear meaningfully in traffic data, it is added to the filter. You do not need to manage the list yourself; the filtering is built into the pipeline that processes incoming beacons.

Some automated traffic is intentionally indistinguishable from a real visitor. A bot that sends a realistic browser user-agent, loads the full page, and executes JavaScript the same way a human browser does will look like a human visit. Such bots exist but are not common. They represent a small and unavoidable edge case in any analytics system that relies on client-side signals.

Why identified bot counts appear separately

Rather than silently discarding identified bot traffic, the dashboard makes it visible as a separate figure. This lets you see the volume of automated traffic your site attracts without it contaminating the main count. If you run a site that search engines crawl heavily, the bot count gives you a sense of that activity without making your visitor numbers look inflated.

The separate count is also a diagnostic signal. A sudden spike in bot traffic that did not exist before can indicate that a new crawler has found your site, that a security scanner is running against it, or that a competing tool is harvesting your pages. Seeing that activity in its own column lets you investigate if you want to, without guessing whether your visitor count is real.

Bot counts do not consume your page view quota. Only page views from real visitors count against the limit on your plan. If automated traffic is high, it does not shorten the period before your quota resets or push you toward an upgrade you would not otherwise need.

Accuracy and what the filter cannot catch

The filter handles the common cases reliably. For well-known crawlers and tools that identify themselves honestly, the filtering is consistent. The accuracy breaks down at the edges: a bot that mimics a real browser user-agent exactly, that runs full JavaScript, and that is not yet on any identification list will pass the filter and appear as a visitor. These cases are uncommon but real.

Headless browser traffic from automated test suites run by your own team is another category that may appear in counts. If your build or deployment pipeline runs end-to-end tests that load your site with a headless browser, those test loads fire the tracking script. If the test environment uses the same site key as production, the test runs show up in your production counts. Using a separate site registration with a different key for testing environments prevents this.

The goal of the filter is to make the counts genuinely useful — to reflect the traffic your site is actually receiving from real people — not to achieve a perfect zero for automated traffic under all possible adversarial conditions. For the ordinary mix of crawlers and automated tools that a typical site encounters, the filter does its job cleanly.

Troubleshooting

If you believe bot traffic is inflating your page view counts and you can identify it from patterns in the referrer or source data — unusual sources, uniform visit timing, unrealistic page load speeds — note the user-agent string from your server access logs and contact support to review whether it belongs in the filter list. The server access logs are separate from the analytics data and contain the raw user-agent strings that the analytics pipeline sees.

If your dashboard bot count is very high compared to your visitor count, that is expected for certain kinds of sites. Developer tools, API documentation, and open-source project pages attract heavy crawling from indexers and scrapers. A high bot count is a sign that the content is being found and catalogued, which is generally a positive signal for search discoverability. It does not indicate a problem with your tracking or your site.

If you are running automated tests against your site using a headless browser and those test visits are appearing in your counts, register a separate site in the dashboard for your staging or testing environment. Use the staging key in your test environment and the production key only in production. This separates automated test traffic from real visitor traffic completely.