Skip to content

Bot and click-fraud protection

A browser check at the entrance filters out automated clients that don’t look like a real browser before they reach the site. It is off by default — enable it when you want it (not everyone wants visitors to see a verification screen). Below is what it gives you, where the honest boundary is, and where to see it in statistics.

The browser check and signatures filter out automated traffic: vulnerability scanners, parsers, password brute-forcers. Suspicious addresses are banned at the network level. Password brute-forcing against common login forms is additionally rate-limited.

Distributed attacks are detected using a combination of network and browser signals. No individual signal determines the verification result by itself.

Where to look: the Protection tab — “Attacks repelled”, “IPs banned”; the Visitors tab — the “scanners” layer on the “Humans and bots” chart.

Boundary: no automated system can guarantee detection of all malicious traffic. WebShield reduces its main volume and raises the cost of an attack, but does not claim 100% effectiveness.

Suspicious direct visits may be sent to the browser check. The decision is based on a combination of traffic signals.

Where to look: the Protection tab — the “Direct visits sent to verification” card.

WebShield analyzes visits from advertising campaigns and identifies suspicious visits that failed the browser check.

Where to look: the Protection tab — the “Suspicious ad clicks” card and the IP table below it.

How to use: export the list of suspicious IPs and times and attach it to a refund claim with the ad network.

Boundary: we detect the bots and provide evidence, but we do not cancel the click charge in real time — the refund decision is made by the ad network.

Automated form spam is filtered at the entrance: a spam bot does not pass the browser check and never reaches the form.

Boundary: we do not inspect submission content and do not catch manual (human) spam — this is not a “full form protection” with text filtering.

We reduce the bot load that distorts behavioral metrics and site analytics (direct-visit spikes, bot sessions).

Boundary: we do not influence what the search engine counts in its results — ranking happens on Yandex’s and Google’s side. There are no ranking guarantees.

For a proxied site the check level is configured per record in DNS → proxy settings (see CDN and protection); for a static site — in the site card (Sites → manage):

  • Bot protection: Off — no extra check (the default);
  • Browser — browser check for suspicious clients;
  • Captcha — CAPTCHA check (stricter, mutually exclusive with Browser).

If “Attacks over time” shows recurring spikes or “direct visits sent to verification” grows, it makes sense to enable a stricter mode. To avoid hindering indexing, configure check exclusions (one path per line, * wildcards supported) only for required service paths — for example, /robots.txt and /sitemap*.xml — and check crawl status on the Site health → Search engines tab. Exclusions only drop the browser-check screen; signatures, rate limiting and bans still apply to those paths.

Protection screen: who is blocked right now

Section titled “Protection screen: who is blocked right now”

The Protection section of the domain panel shows the addresses the system is blocking right now and whether they are still trying:

  • Blocked hits — how many requests from the address were cut off in the period. If it keeps growing and the “Still trying” badge is shown, the bot is still hammering (and the block is automatically extended).
  • Action — how the address is handled: Blocked (444) (the request is rejected at the edge but stays visible for observation) or Captcha (the address is sent to verification rather than blocked).
  • Reason — why the address was blocked: scanner (path enumeration), error burst, login brute-force, bot farm, etc.
  • Expires — when the block lifts if the bot goes quiet. As long as the address keeps trying, the deadline is extended; after a long silence it is unblocked automatically.

Only precisely identified bots and scanners are blocked — regular visitors do not end up here. The verification pages stay reachable, so a person who happens to share an address with a bot (for example, behind a mobile carrier) can still pass the check.

Related sections: Statistics, CDN and protection, Site under attack.