Site script
The WebShield script is a small code fragment added to your site pages. It makes bot farms and browser automation detectable without enabling the browser check, that is, without showing visitors a verification screen.
Installation is optional. It is intended for those who prefer not to enable the browser check but still want the statistics to reflect the real picture: how much traffic originates from farms and automated browsers.
Purpose
Section titled “Purpose”Some visitor traits are observable only from inside the page. Simple clients such as curl and scrapers are
filtered out without it, but automation of a genuine browser — when an attacker drives an ordinary
Chrome instance with a program — looks like a live visitor from the outside.
The script closes this blind spot: it captures a technical fingerprint of the environment, which reveals clones of a single image spread across many addresses (see Invalid traffic and fraud). Previously this data was collected only on the browser check screen — the script provides it on sites where the check is disabled.
Installation
Section titled “Installation”Add one line to the shared HTML template of your pages:
<script src="/webshieldpro/t.js" async></script>No keys or configuration are required: the script is served from your own domain, and WebShield
identifies the site automatically. The async attribute is required — it guarantees that loading the
script does not delay page rendering.
Place it either in <head> or at the end of <body>, at your discretion. Placing it in <head>
is slightly preferable: the script starts working earlier and therefore also accounts for visitors who
leave before the page has finished loading. Such brief visits are characteristic of bot farms, so the
resulting picture is more complete. This does not delay rendering — the async attribute ensures that.
To verify the installation, open https://your-domain/webshieldpro/t.js in a browser. The script text
should be displayed. A 404 response means the domain is not yet served through WebShield.
WordPress
Section titled “WordPress”Add the following to your theme’s functions.php. The final argument false places the script in
<head>, true places it in the page footer; both are supported:
add_action('wp_enqueue_scripts', function () { wp_enqueue_script('webshield', '/webshieldpro/t.js', [], null, false);});Next.js
Section titled “Next.js”In app/layout.tsx:
import Script from "next/script";
<Script src="/webshieldpro/t.js" strategy="afterInteractive" />Other systems
Section titled “Other systems”Any method of inserting a <script> tag into the shared page template will do: a “custom header or
footer code” block in a site builder, base.html in Django, layout.blade.php in Laravel. The script
must be present on all pages, not only the home page — otherwise a portion of visitors remains
unaccounted for.
Inserting the script through tag managers such as Google Tag Manager is not recommended: they are frequently blocked by browser extensions, which results in incomplete data.
If the site uses CSP
Section titled “If the site uses CSP”Under a strict Content Security Policy, permit loading and sending data to your own domain:
script-src 'self';connect-src 'self';The script loads nothing from third-party addresses and communicates only with your domain, so the
'self' directive is sufficient.
What is collected and what is not
Section titled “What is collected and what is not”The script collects technical characteristics of the environment (screen and graphics subsystem parameters, time zone, hardware characteristics of the device) and anonymised counters of page usage.
Not collected: form field contents, entered text, passwords, page content, browsing history, files, or any data from other tabs. The script sets no advertising identifiers and transfers no data to third parties.
If your site publishes a privacy policy, state in it that visitor data is processed for technical purposes to protect against automated traffic.
Where to see the results
Section titled “Where to see the results”The Protection tab of domain statistics: detected groups of addresses sharing a fingerprint, together with the reason for the flag. Data appears as traffic accumulates, normally within a day of installation.
Limits
Section titled “Limits”The script blocks nothing. It only collects the traits by which WebShield identifies automated traffic; blocking decisions are made separately, according to the domain’s general protection rules.
The script is not a replacement for the browser check. The browser check denies an automated client access to the site, whereas the script merely makes it visible in statistics and in cross-site correlation. If the objective is to deny access, enable the browser check.
The data collected by the script is not available to your page code or to your backend: it starts no session, returns nothing to the browser and exposes no API. All it does is feed the data on which WebShield bases its own domain protection decisions.
For that reason the script is not suitable for protecting forms — sign-ups, applications, promo codes: there is nothing to ask whether a given submission should be accepted. That is what form protection is for: its tag issues a session identifier, and your backend uses it to obtain a verdict before accepting the action. Form protection also works for sites behind our protection; there is no need to install both scripts, as the form protection tag collects everything this one does.
Visitors with JavaScript disabled or blocked by an extension are not accounted for by the script. An attacker may likewise decline to execute it — in that case the attacker forgoes this data but remains subject to the general protection rules (signatures, rate limits, bans).