The word "anti-bot" sounds deceptively simple, like a single checkbox in your hosting settings. In reality it covers very different tools, from denial-of-service protection to a filter that decides, on every ad click, whether it is facing a human or a program. Choosing wrong costs money: either the site stays defenseless exactly where it hurts, or it loses real buyers.
Below: what anti-bot protection is, which problems it solves, and how to choose website bot protection for your situation.
What is anti-bot protection, in plain terms
An anti-bot is a system at the entrance to your site that tells a real visitor from an automated program and decides what to do with the visit: let it through, slow it down, show a challenge, serve a different page or refuse.
It is worth remembering that "bot" is not an insult. Search engine crawlers, uptime monitors and link previews in messengers are bots too, and your site needs many of them. The point of an anti-bot is not to "kill all robots" but to let the useful ones in, cut the harmful ones and leave people alone.
Harmful bots fall into a few large groups:
- Load bots — flood the server with requests until it stops responding.
- Scrapers — collect prices, copy, catalogs and contacts.
- Intruders — brute-force passwords and hunt for vulnerable forms and admin panels.
- Spammers — fill in lead forms, comments and sign-ups (what to do when bots submit forms on your site has its own article).
- Ad bots — click paid ads, fake visits, inspect ads and harvest other people's funnels.
Each group needs its own protection, which is why "anti-bot for a website" means different things to different people. What bot traffic looks like in numbers is covered in signs of bot traffic.
Types of anti-bot protection and what each one covers
| Task | What handles it | What it does not protect against |
|---|---|---|
| Denial-of-service attacks (DDoS) | CDN, network and hosting-level protection | Expensive one-off ad clicks |
| Password brute force, form spam | CAPTCHA, attempt limits, hidden fields | Scrapers that never submit anything |
| Scraping | Rate limits, browser checks, blocking hosting networks | Bots that arrive via an ad link |
| Ad bots and click fraud | A traffic filter on the landing page that scores every visit | Denial-of-service attacks |
Clearly, there is no universal anti-bot. DDoS protection works on the stream of requests and thinks in volumes: "too much from this subnet, slow it down". An ad filter thinks in single visits: "this specific click cost money, who made it?". Different math, different mistakes.
Bot protection for ad traffic vs DDoS protection
Denial-of-service protection answers the question "will the server hold up?". Success means the site is available. If it lets a hundred bots through, no harm done: the load is fine.
An anti-bot for ad traffic answers the question "who did the money go to, and who saw the page?". Success means a real person reached the offer while a bot, scanner or spy tool did not. A hundred bots let through here means a hundred paid empty clicks and corrupted stats that will lead you to kill working campaigns.
The difference cuts the other way too. DDoS protection can afford to show everyone a "Checking your browser, please wait" screen for a moment; people will wait. On an ad landing page every second of waiting and every extra screen lowers conversion, and you have already paid for the click.
Anti-bot vs anti-scraping
Scrapers usually come directly, without ads, from hosting and cloud networks, many times in a row. Rate limits and blocking data centers work well against them. An ad filter solves a related problem but at the entrance of a paid link: there the scraper disguises itself as an ordinary visitor from an ad, and frequency alone is no longer enough — you need network, browser and behavior checks.
How anti-bot protection works: layers of checks
A mature anti-bot does not rely on a single signal. It stacks several layers, and each catches its own class of automation.
- Network. Where the visit came from: a residential or mobile ISP, a hosting network, a VPN or proxy, a blacklisted address. More in VPN, proxy and data center IPs.
- Request. What the headers look like, whether there is a browser language, whether the claimed browser matches how it behaves, whether there is an ad click ID.
- Browser. Whether JavaScript runs, whether there are traces of automation typical of headless browsers, whether screen, time zone and language are consistent. See headless browsers and browser fingerprinting.
- Behavior. How the mouse and finger move, how long the visitor stayed on the page, whether they repeat the exact same path.
Some signals are conclusive and reject immediately: a program instead of a browser, a known review bot. The rest add up to a trust score: a VPN alone does not make someone a bot, but a VPN plus a hosting network plus no JavaScript is already significant.
Tip. Ask any anti-bot vendor whether you can see why a specific visit was filtered. Protection without explanations becomes a black box: you cannot tell useful work from cutting real buyers.
Website bot protection: typical cases
Anti-bots get installed on very different sites, and each type has its own pitfalls. Below are general considerations, not tied to settings of specific platforms: their interfaces change, so check details in their own help docs.
Sites on website builders
Website builders give no server access, so protection is either provided by the platform itself or added as a script in the page header. A script-based anti-bot must load first, before any content is shown, or the page will have opened for everyone already. Many builders only allow custom code in the head section on their paid plans, so check this before launching ads.
Sites on a PHP CMS (WordPress and others)
With server access you have more options: the check can run before the server even starts sending the page, rather than in the browser. That is more reliable — a visitor without JavaScript will not see the page even for an instant. The main enemy here is caching: a cache plugin or the host's cache serves a saved copy of the page, and the anti-bot never gets to ask for a decision. Ad landing pages must be excluded from the page cache. For WordPress details see cloaker plugin for WordPress.
Sites behind Cloudflare or another CDN
A CDN covers load attacks and crude scanners, which makes it a good first line of defense. But keep two things in mind. First, a CDN caches too, and if the landing page is cached at the edge, the filter on your server will miss part of the visits. Second, CDN rules apply to the whole site at once and do not know which click came from which ad campaign. That is why an ad filter is installed additionally, on specific landing pages.
Online stores and service sites without paid ads
If your traffic is mostly organic, you hardly need an ad anti-bot. DDoS protection, a CAPTCHA on forms and limits on account logins are enough. But you must not block search engine crawlers — that is a direct route to dropping out of search results.
Anti-bot protection for ad landing pages
When you pay for every visit, an anti-bot picks up three extra jobs.
- Protect the budget and the stats. Bots click ads, sometimes en masse — that is click fraud. If they are not filtered out, reports lie and optimization runs on noise.
- Hide the funnel from harvesters. Spy tools and scrapers crawl ad links to copy creatives and landing pages.
- Keep real people. In-app social browsers, mobile internet and shared carrier addresses all look "suspicious" to a crude filter.
That leads to requirements for an ad anti-bot that DDoS protection does not have:
- A decision for every visit, not for a stream of requests.
- No CAPTCHA and no extra screens for humans.
- The reason for the decision logged for every click.
- The ability to relax a single check if it hits people, instead of turning everything off.
- Separate settings for different sources: social, search and push traffic behave differently.
A step-by-step setup for such a filter is in how to filter bots out of ad traffic.
How it works in ArtisanClo
ArtisanClo is an ad traffic filter: on every visit from an ad link it decides in a fraction of a second whether to let the visitor through to the main page or show a neutral safe page (White Page). Your site stays with you.
- Two ways to connect. A JS tag as the first line in the page's head, or a PHP file on your server; for WordPress there is a plugin that sets up the same PHP method. How to choose is covered in how to connect the filter to your site.
- Layers of checks. IP blacklists, VPN and proxy, data center networks, headless browsers, Require JS, the live interaction check — each is switched on separately, and overall strictness is set with the Soft, Balanced and Strict levels.
- Trust score. Obvious automation is rejected immediately, other signals add up as penalties, and a visit goes to the White Page only if the total exceeds the threshold.
- Shared bot list. If an ad review service or a program posing as a browser is confidently identified for any client, its next visit to your flow gets the White Page straight away. Real visitors on a questionable network are never added to it.
- A reason for every click. The click log shows the decision and one of dozens of reasons, such as "VPN or proxy blocked", "A program, not a browser" or "Too many clicks from one IP". If you are not sure whether the filter cuts people, Shadow mode (with the PHP file) shows whom it would have filtered without filtering anyone.
The full feature list is on the features page and plans are on the pricing page; there is a free trial.
How to choose an anti-bot: a short checklist
- Decide what you are protecting against: load, forms, scraping or paid clicks.
- For ads, check whether there is a log with a reason for every visit.
- Find out how the protection connects to your site and whether caching breaks it.
- Make sure search engine crawlers are not blocked on your main site.
- See whether strictness can be tuned per traffic source.
- Run it on part of your traffic and compare conversion before and after.
Summary
Anti-bot protection is not one button but a class of tools. DDoS protection guards the server, a CAPTCHA guards forms, rate limits guard your catalog from scrapers. If you buy ads, you also need a filter that scores every paid click, explains its decision and stays out of real people's way. Start with the question "what exactly hurts?", and the choice becomes obvious.
