Bot Traffic Filtering for Links: How Real Clicks Get Counted

Three server-side filters stand between a raw HTTP request and a counted click in TrackRev — user-agent heuristics, known-bot lists, and behavioural signals — and removing what they catch is why the platform’s median revenue per click holds at $3.80 rather than a diluted fraction of it.

Bot traffic filtering for links is the practice of rejecting non-human hits before they enter your click totals, so the numbers you report and optimise describe people, not crawlers.

Raw, unfiltered click counts overstate real human traffic by a wide margin — the exact margin varies enormously by link and audience, which is precisely why you filter rather than apply a flat discount.

This article walks through each filtering layer, what it catches, and where even good filtering has limits.

It is a technical companion to the 2026 link-tracking benchmarks, whose per-channel figures only hold up because the underlying clicks are filtered first — the clean base a report needs before it can trust its channel revenue figures.

Why this matters for your revenue

Unfiltered clicks corrupt every downstream number. Click-through rate, cost-per-click, revenue-per-click, conversion rate — all of them use clicks in the denominator, so inflating the denominator with bots deflates the metrics that decide budgets.

A channel that looks like it has a poor conversion rate might simply have a bot-heavy click count; a link that looks like a star might be a preview-fetch magnet. You cannot tell which without filtering first.

The reason a flat discount does not work is that bot contamination is wildly uneven.

A private, gated link shared in a Slack community might be almost entirely human; a public affiliate link on a high-traffic page might carry a heavy load of crawler and scanner traffic; a newsletter to a corporate list gets slammed by email-security scanners the instant it sends.

Apply the same “knock 20% off” rule to all three and you over-correct the clean link and under-correct the dirty one — you have added a second distortion on top of the first.

Per-link filtering, applied at the moment of the click, is the only approach that removes the right amount of noise from each link.

Get it right and your revenue-per-click figures become comparable across links; get it wrong and every ratio you compute inherits the contamination.

What bot traffic filtering is

Bot traffic filtering is a pipeline of checks applied to each incoming click that decide, before the click is counted, whether the request plausibly came from a human.

The checks run server-side on the raw request, so they work regardless of what the visitor’s browser does or does not execute.

Why raw click counts overstate

A tracked link is a public URL, and public URLs are hit constantly by machines that never intend to buy anything: search engines indexing, security tools scanning, monitors checking uptime, and social and chat platforms fetching previews.

Every one of these produces a valid HTTP request that a naive counter treats as a click. The overstatement is not a bug in counting — the counter is doing exactly what it was told.

Filtering is the step that adds the missing judgement about which requests represent people.

The filtering pipeline in order

Effective filtering is layered, cheapest checks first. A request is tested against user-agent signatures, then against known-bot and datacentre IP ranges, then against behavioural and referrer signals, with prefetch and preview detection woven through.

A click has to survive every layer to be counted. Because the layers run in sequence on the server, the obvious non-humans are rejected in microseconds and only ambiguous cases reach the more expensive behavioural checks.

User-agent heuristics

The first and cheapest layer reads the user-agent string every HTTP client sends, and a large fraction of bots identify themselves in it — either honestly or through tell-tale signatures.

Known-bot user-agent signatures

Legitimate crawlers and tools usually announce themselves: search-engine bots, monitoring services, and link-preview fetchers carry recognisable tokens in their user-agent. Matching against a maintained list of these signatures removes a large, benign chunk of non-human traffic immediately.

This layer is high-precision — a request that says it is a known crawler almost always is one — which makes it a safe first cut before any fuzzier judgement is applied.

Missing or malformed user-agent strings

The absence of a normal user-agent is itself a signal. Real browsers send rich, well-formed user-agent strings; many crude bots send none, send a truncated one, or send a library’s default token.

A click with a missing or obviously non-browser user-agent is unlikely to be a person and can be quarantined or dropped.

This does not catch sophisticated bots that spoof a real browser string — that is what the later layers are for — but it clears out the low-effort automation cheaply.

Known-bot and datacentre IP lists

The second layer looks at where the request came from. Humans browse from residential and mobile networks; a great deal of bot traffic originates from cloud and datacentre ranges that no ordinary consumer sits behind.

Datacentre and cloud IP ranges

Requests from known datacentre and hosting-provider IP ranges are strong bot candidates, because genuine buyers rarely browse from a cloud server.

Matching the click’s IP against maintained datacentre ranges and published bot-network lists catches automation that presents a clean user-agent but cannot hide its origin.

This layer is powerful precisely because IP origin is harder to fake convincingly than a user-agent string — spoofing a residential IP at scale is expensive, which raises the cost of evading this check.

Behavioural signals

The third layer stops trusting what the request claims and starts judging how it behaves. Behavioural filtering catches bots that pass the user-agent and IP checks by looking at patterns no honest visitor produces.

Impossible timing and click patterns

Humans click at human speeds and in human patterns. A single source hitting hundreds of links in a second, clicking every link in a message simultaneously, or producing perfectly regular intervals is behaving like a script, not a reader.

Rate and pattern analysis flags these bursts, which is especially effective against the email-security scanners and preview fetchers that betray themselves by touching many links at once. The pattern is the tell even when every individual request looks clean.

Referrer-chain validation

A genuine click usually carries a plausible referrer — the page or app it came from. Clicks with impossible, contradictory, or conspicuously absent referrer chains are suspicious, because a real navigation leaves a coherent trail.

Referrer validation is not decisive on its own (privacy features legitimately strip referrers, and some real clicks arrive bare), so it is weighted alongside the other signals rather than used as a sole verdict.

In combination with timing and IP, though, a broken referrer chain tips an ambiguous request towards rejection.

Prefetch and preview detection

A distinct problem deserves its own layer: clicks that are real requests from real platforms, generated on a human’s behalf but not by a human’s deliberate tap.

These are the hardest benign category to separate because they often come from residential IPs and real apps.

Link-preview fetchers

When a URL is pasted into a chat or social app, the platform fetches it to render a preview card — a title, an image, a description.

That fetch is a click as far as your server is concerned, but no human tapped anything. Preview fetchers can be identified by their user-agents and by the characteristic pattern of a single fetch with no follow-on session.

Filtering them out matters most for links shared in messaging apps and communities, where a popular share can generate a burst of preview fetches that dwarfs the real clicks.

Browser prefetch and speculative loads

Modern browsers and some apps speculatively load links the user is likely to tap, to make the eventual navigation feel instant. If the user never taps, the prefetch was a click with no human intent behind it.

These are detectable because the prefetch typically arrives without the engagement signals a real navigation produces — no meaningful session follows.

Counting prefetches as clicks inflates exactly the links a browser guessed were popular, which biases your data towards its guesses rather than your readers’ choices.

Bot types, tells, and filters

The table maps each major non-human source to the layer most likely to catch it. No single layer is sufficient — the design relies on a request having to pass all of them.

Raw versus filtered click views

The value of filtering is easiest to see as a before-and-after on the same link. The table contrasts what a raw counter reports with what survives the pipeline.

Where filtering has limits

Good filtering removes most non-human traffic, but it is honest to name where it cannot be perfect — and why the answer is a second line of defence rather than a stronger filter.

Sophisticated bots that mimic humans

The most advanced bots run real browser engines, spoof plausible user-agents, route through residential proxies, and pace their clicks to look human. These can pass every upstream filter, because at the request level they are indistinguishable from a person.

No user-agent, IP, or timing check catches all of them, and any filter aggressive enough to try would start rejecting real buyers. This is the ceiling of upstream filtering, and pretending otherwise would be dishonest.

Why revenue is the backstop

The defence against bots that pass every filter is to judge them on outcome rather than appearance.

A sophisticated bot can fake a click but has no reason to complete a purchase, so tying clicks to downstream revenue catches what upstream filtering cannot — the click that looks perfectly human but never becomes a sale.

Filtering and revenue verification are complementary: filtering removes the obvious non-humans cheaply and in real time, and revenue verification adjudicates the sophisticated remainder once the outcome is known.

How TrackRev filters link traffic

TrackRev runs the filtering pipeline server-side on every tracked click, before the click reaches your dashboard.

Filtering at the redirect, on your own infrastructure

Because link tracking captures the click at a server-side redirect on your own domain, the filters run on the raw request the instant it arrives — user-agent and datacentre checks first, behavioural and referrer analysis next, prefetch and preview detection throughout.

Only surviving clicks are counted, and because the same first-party pixel and billing connection also power attribution and the affiliate programme, the surviving clicks are the same ones later checked against revenue.

Filtering and revenue verification are one continuous pipeline rather than two tools disagreeing about what a click was worth.

When NOT to use TrackRev

If you never act on click counts — for instance, if you only ever read verified revenue and treat clicks as irrelevant — then click filtering is a feature you will not use, though the same platform still gives you the revenue view.

If your traffic is so low that a handful of bot clicks does not move any decision, the filtering is quietly working but not changing your conclusions.

And TrackRev is not an ad-network invalid-traffic clearinghouse arbitrating between third-party networks; that is the TUNE and Everflow category. TrackRev filters your own links so your own click metrics describe people.

Filtering only pays off if the filtered click is the same click your revenue is measured against — split link tracking from conversion tracking and you get a tool that filters clicks it cannot value and a tool that values conversions it cannot filter.

The default stack splits there: Bitly Growth at ~$35/month filters and counts clicks, Rewardful Starter at ~$49/month counts conversions, $84+/month for two systems that never share a definition of a valid click.

TrackRev is $39/month for link tracking, revenue attribution, and the affiliate programme on one pipeline, so a click the filter rejects never reaches attribution and a click attribution values was already filtered.

Clean clicks and trusted revenue are the same number only when one tool produces both.