Part of the traffic reaching any website does not come from people. Search engines, monitoring services, link preview tools, scrapers and automated scripts visit pages all the time. Many of them do not execute JavaScript and therefore never show up in client-side analytics, but some do. When they get into the data, they inflate visits, lower conversion rates and can make a campaign look more effective than it is.
Kinds of non-human traffic
It helps to distinguish a few families, because they are recognised and handled differently:
- declared crawlers: they identify themselves with a recognisable user agent and usually do not run analytics scripts;
- automated browsers: testing, monitoring or scraping tools that use a real browser engine and therefore execute JavaScript just like a visitor;
- referral spam: visits, or fake events sent straight to the collection servers, with an invented referrer meant to catch the curiosity of whoever reads the reports;
- internal traffic: not a bot, but visits from you, your team or your checking tools distort the data in the same way.
Signals to watch
No single signal is proof. They become meaningful when several add up in the same segment:
- sudden spikes from a single city, network or hosting provider;
- sessions with zero duration, or identical to the second, repeated hundreds of times;
- unusual screen resolutions, or always the same one;
- browser language missing or inconsistent with the country;
- every visit lands on the same page with no interaction;
- referrers from unknown domains that contain no link to your site;
- hits recorded against hostnames that are not yours.
That last signal is typical of spam sent directly to the collection system: the script never ran on your site, so the reported hostname is fake or missing.
An investigation in practice
Suppose traffic on a Tuesday triples with no active campaign. The procedure I follow is this:
- isolate the anomalous day and compare it with a normal Tuesday;
- break it down by source, country, device and landing page, looking for the dimension where the increase is concentrated;
- look at that segment's behaviour: pages per session, events, engagement time;
- where possible, cross-check with server logs to see addresses, user agents and the rhythm of the requests.
If the increase sits entirely in one segment with zero interaction and a regular cadence, it is almost certainly automation.
How to filter
There are three levels of intervention, each with benefits and limits:
| Level | Example | Pros | Cons |
|---|---|---|---|
| Before collection | rules on the server or web application firewall | data is never polluted | risk of blocking real visitors |
| In configuration | valid hostname filter, excluding internal addresses | simple, applies to all reports | usually not retroactive |
| At analysis time | segments excluding suspicious traffic | reversible, works on past data | must be remembered every time |
A very effective, low-risk filter is the hostname filter: accepting only data that claims to come from your own domains removes most spam sent directly. For internal traffic, a parameter or cookie set on team devices is more reliable than excluding by address, which changes when people work from different networks.
Don't overdo it
Overly aggressive filters create the opposite problem. Excluding a whole country because it produced an anomalous spike may delete real customers; excluding short sessions also removes people who found a phone number immediately. Each filter should target a specific trait of non-human traffic, not a behaviour that people can also show.
Document it
Every exclusion should be recorded: what it does, when it was switched on, and why. A short log with date and reason lets you explain a sudden drop in the reports and remove a filter that has become useless. Without documentation, a year from now nobody will know why certain data is missing.
Bots and conversions
The most delicate case is forms. Automated spam submissions can inflate recorded conversions. It is better to count as a conversion only a submission that passed server-side checks, not the mere click on the button. That way the reports reflect requests someone will actually read.
In short
- Not all recorded traffic is human: crawlers, automation and spam get into the data.
- Look for anomalous concentrations in one segment with no interaction and a regular cadence.
- Hostname filtering and excluding internal traffic are the safest first steps.
- Avoid filters that target behaviour real people also show.
- Document every filter and count as a conversion only server-validated submissions.