JS Challenge Against Bots
A JS challenge against bots only lets browsers that actually execute JavaScript through to the offer, filtering out plain crawlers and HTTP scripts before the real page ever loads. Most moderation parsers and cheap bots don't fully render JS, which makes this one of the cheapest, most effective filters in the stack. Here's how it works and what it can't catch on its own.
How a JS challenge works
Before the main page loads, the visitor gets served an intermediate script that runs a small JS task — a computation, a token being set, reading a browser property — and sends the result back to the server as proof. A real browser clears this in a fraction of a second, invisibly to the user, while a bare HTTP client or a crawler with no JS engine can't complete the check and never reaches the offer. It's close to how bot protection works at large CDNs, just scaled down to a single landing page's cloaking.
Which bots a JS check filters out
Mainly simple scripted parsers and moderation crawlers that request raw HTML without fully rendering the page. It also catches a chunk of automated ad-platform scanners, which check ads in bulk and can't afford a full headless browser on every single hit. Advanced bots running headless Chrome can pass this check — at that point the JS challenge is working alongside other filters, not alone.
What this method can't do
A JS challenge can't tell an advanced headless-browser bot from a real user — both complete the JS task the same way. It also adds a small delay to page load, usually a fraction of a second, worth accounting for on already-heavy PWA pages. That's why it almost always runs paired with UA filtering, IP-intel, and behavioral checks rather than standing alone.
The JS challenge inside APEX's anti-bot cloaking
In APEX, the JS check is part of the built-in anti-bot cloaking and runs as another filter layer alongside UA, geo, and IP-intel — no need to write or host a challenge script yourself. The check is transparent to real users; the delay isn't noticeable, but plain bots and JS-less crawlers drop off at this step. The whole layer stack gets configured once and applies automatically to every visitor on the funnel.
When a JS challenge earns its place
It's especially useful against bulk automated ad-platform scanners and parsers that sweep through large numbers of ads without full rendering. On high-competition verticals where funnels get scanned for cloaking often, an extra JS-check layer cuts the odds of getting caught by the cheapest, most common tier of scanning.
FAQ
- Does a regular user notice the JS challenge?
- No, for a real browser the check clears in a fraction of a second and is invisible; the page-load delay is minimal and doesn't affect how the landing feels.
- Can an advanced bot get past a JS challenge?
- Yes, a bot running a full headless browser can complete the JS task just like a real user. Against those, the JS challenge only works paired with the rest of the cloaking filters, not on its own.
- Does the JS check slow down PWA page load?
- Only slightly, usually a fraction of a second — barely noticeable for users, but worth factoring in on PWA pages that are already resource-heavy.
- Does the JS challenge need separate setup from the rest of cloaking?
- In APEX, no — it's a built-in anti-bot cloaking layer that turns on together with the UA, geo, and IP-intel filters in one setup, with no separate script needed on the landing page.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free