How bot detection works: one visit, one read, many decisions
Klacos doesn’t put a challenge in front of your visitors by default, and doesn’t take their word for anything. It analyses every visit as a whole, in front of your site, forms one read of it, then uses that read for every decision it makes: serve, count, slow down, check or block. Each decision keeps its reason, readable in the console.
What you can’t see from inside the page
Many tools judge a visitor from a script loaded in the page, so they only see the visitors that run it. The simplest bots never load it: they request your pages, files and forms without leaving a trace. The more sophisticated ones run it like a browser would, and pass for people.
Getting it wrong costs you either way. A bot taken for a person uses up your server, skews your analytics and fires your tags. A person taken for a bot is a lost customer, often with nobody knowing why. To judge well, you need to see the whole visit, where it arrives, and keep the reason for every decision.
What happens in front of your site
Four stages, from request to decision
Everything goes through the service
Every request passes through Klacos before it reaches your server, including those from bots that never load a full page. So it sees what a script inside the page can’t, and the protection adds nothing to your pages.
The visit is read as a whole
How the visitor connects, their path from page to page, their pace, their network, their behaviour across your whole site. The whole picture tells the story, not one isolated detail.
The response is graduated
Let through, slow down, check without showing anything, and block as a last resort. A visible challenge only exists if you choose one.
It is explained
Every decision keeps its reasons, readable in the console. A blocked visitor gets a reference to appeal, and you know what to tell them.
The same view of each visit drives the whole service
The web application firewall
An injection attempt counts against the visitor who sent it, and a doubtful case can be checked rather than blocked.
The waiting room
During a rush, bots that have been turned away take no place in the queue: your customers get in on their turn.
The tag manager
Your analytics and advertising tags don’t fire for visits judged to be bots.
The same read keeps bots out of your cookieless analytics, drives bot management, and decides what the web application firewall, the virtual waiting room and the server-side tag manager do. One install, one view of every visitor.
What the service does when it doesn’t know
Some visits won’t be pinned down: too short, coming from a network lots of people share, or simply unremarkable. Klacos doesn’t force a verdict. A visit it doesn’t know enough about stays unknown, and an unknown visitor isn’t blocked.
One isolated clue isn’t enough to block anyone either, and what a browser says about itself isn’t enough to believe it. If the visit carries on, the read sharpens page by page, and the decision follows. Meanwhile, these visits keep a column of their own in bot traffic analytics, separate from people and bots, so you see what is still uncertain instead of having it counted on one side or the other.
How mistakes are avoided, then put right
Two rules run through the whole service: observe first, decide next, enforce last; and no decision without a reason. Here is what they mean in practice, in the order you meet them.
Observe
Everything starts in observation, site by site and traffic type by traffic type. Klacos works out its decisions without applying them, and you see what it would have done to your own traffic.
Replay
Before tightening a setting, you replay it against your past visits. The console tells you how many requests it would have caught and how many came from visitors judged to be human, and which reasons come up most. If the replay stops customers, you adjust the setting before it goes live.
Enforce in steps
You enforce one step at a time, and any step can be rolled back in one move. The response stays graduated: slowing down and checking without showing anything come before a block.
Explain and unblock
A visitor who is stopped all the same sees a page in your branding, with a reference and a link to appeal. Your support team finds the visit, reads the reasons behind the decision and lets them back in with one click.
The page on explained decisions and appeals shows what a blocked visitor sees, and what you see on your side.
Good bots are verified, then they get through
Search engines, uptime monitors, link previews and payment providers are bots your site needs. Klacos checks they are who they claim to be before letting them through, and treats anyone borrowing their name as an impostor.
They stay visible in the console, category by category, but never count towards your audience. The upshot: you know how much of your traffic is human, and every bot gets the response you chose for it.
See what Klacos would say about your traffic
Request early access: everything starts in observation, and nothing is blocked until you choose to enforce it. Or tell us about your site and the bots you see coming through.