How to install bot protection on a site

Bot protection is installed as a script on the page. Binetro protects a site from bots and ad click fraud: the script collects data in the visitor’s browser and sends one check request. The response is a decision for that visit. There is no separate panel where you mark every arrival by hand.

What follows is what actually gets installed, when the same visit is sent again, what the script does if no answer comes back, and when the check never starts.

What goes on the page

A script is placed on the page. It runs in the browser of whoever opened the page, collects data for this visit, and sends one request. The decision is for this visit, not for the site as a whole and not for every future arrival in advance.

One request per visit is the ordinary path. The script does not fire a series of identical checks just because the page stays open. A second send is described separately and belongs to two clear cases: after a computational task, and when the network request fails.

When the site key, the page domain, and the site status are in order, the request reaches the check and a decision comes back. If one of those conditions fails, the visit is rejected earlier and the main review never starts. Those conditions are below, so a rejection at install time is not mistaken for “a bot on a real person.”

When the same visit is sent again

After the computational task, the script sends the collected data once more. That is not a new visit and not a second independent check “just in case.” The same visit is completed with the result of the task.

One retry is also appropriate when the request fails on the network. That means one retry, not a queue of attempts until some answer suits the sender. If the first send did not get through because of the network, the script may send the data again.

A successful check can issue a signed pass for the rest of this visit. The pass is bound to the site, the network, and the browser. It cannot be carried to another site, another network, or another browser with the decision riding along.

The pass does not turn a “do not admit” decision into “let through.” If the visit was already decided as do-not-admit, a signed pass does not rewrite that mark. The pass belongs to continuing a visit that the check completed successfully, not to bypassing a refusal.

If there is no answer, the visit is let through

If the script got no answer — an error, a timeout, or a 5xx response — the visit is let through. The check itself has no such mode. The pass-through on failure is done by the script on the site. The check does not announce “when in doubt, admit.” It simply did not answer in time or could not answer, and the script does not hold the person on the page waiting.

If the response could not be assembled, the visitor is let through as well. An unassembled response is the same case for the script as an error, a timeout, or a 5xx: there is no decision, and the visit continues.

That is different from an explicit decision. An explicit answer is a decision on the visit. No answer is an action of the script, not a lenient mode of the check. A real visitor is not locked out only because the request never returned. An automated client gets the same pass-through if there was no answer: the script does not substitute silence with a refusal.

An address on the site’s exclusion list is skipped before the main check. That is a separate path, not a failure. The exclusion runs before the main review of the visit begins. The size of the list and the format of its entries are not set here. The order is what matters: the exclusion list first, and only if the address is absent does the main check start.

When the request never reaches the check

An unknown site key is rejected. A script using a key the site does not have does not get a visit review. The key ties the request to a specific site. A foreign or invented key never reaches the check.

A disabled site is rejected even if a record of it exists. Having a record is not the same as protection being on. While the site is disabled, the visit is rejected rather than “checked in the background.”

If the page address does not match the site’s domain, the visit is rejected. A script placed on a page of another domain does not pass as a visit of this site. A subdomain is not stripped off the site domain by itself: a site has one domain. A page on another name, even if it looks like a subdomain, is not treated as the same domain automatically. The match is against the domain recorded for the site, without cutting off the left-hand part of the name.

A connection that “shows no decisions” often lands on one of the last rows: the key is not for this site, the site is disabled, or the page is open on the wrong domain. Then the check is not silent. The request never reached it, and the visit was rejected under that rule.

When the request did arrive and there is no answer, the picture is the opposite: the script lets the visit through. Those two outcomes must not be mixed. Rejection before the check means “this request is not accepted.” A pass-through on failure means “there was no decision, the person continues.”

A signed pass after a successful check does not repair a foreign domain or a disabled site either. It is issued to continue a visit that already passed the check, and it stays bound to the site, the network, and the browser.