Cloudflare Edge Sensor

The edge sensor is a Cloudflare Worker that reports automated clients which never execute JavaScript. It runs in front of your origin, so it sees requests a browser never makes.

Why you need it

WebDecoy’s detection script runs in the visitor’s browser. That is the right place to fingerprint a real browser, and it is the wrong place — the impossible place — to see a client that never opens one.

Googlebot’s crawl pass does not run your JavaScript. Neither does GPTBot, ClaudeBot, CCBot, PerplexityBot, curl, or most scrapers. On a JavaScript-only install, your Citation Monitor can only ever show browser extensions and LLM referrals. It cannot show you a crawler, ever. That is not a tuning problem or a bug; it is what a page tag is.

The edge sensor closes that gap and nothing else. It does not replace the detection script — they see different populations.

What this looked like in practice

On our own site, Googlebot detections went from 0 to 68 in 41 hours after deploying the sensor, alongside roughly twenty other crawlers the page tag had never been able to see. The crawl timestamps matched Google Search Console’s own lastCrawlTime to the second.

What it does and does not do

It inspects each request, decides whether it looks automated, and sends a small beacon to WebDecoy when it does.

Sensing never blocks, challenges, or modifies a response. Detection and enforcement are two jobs of the same Worker — Cloudflare runs one Worker per matched route, so shipping two would mean one of them silently not running — but they are separate paths through it. Enforcement acts only on clients you have already denied; sensing only reports.

On any internal error it fails open: ingest being unreachable, a malformed config, an oversized beacon, or an unexpected exception all result in your visitor’s request being served exactly as it would have been.

Install

One click, from the app

Integrations → Cloudflare → Edge Sensor. Pick your zone and press deploy. WebDecoy uploads the Worker, binds the route, and switches reporting on.

You need a connected Cloudflare integration whose API token carries:

Permission	For
Zone → Zone → Read	Listing your zones
Zone → Workers Routes → Edit	Binding the sensor to your traffic
Account → Workers Scripts → Edit	Uploading the Worker
Zone → DNS → Read (optional)	Confirming your record is proxied before installing

Scope the token to both Zone Resources and Account Resources. Workers Scripts is an account-level permission, so a token scoped only to a zone fails the upload with an error that reads like a missing permission.

Deploy it yourself

If you would rather own the deployment, the Worker is published at github.com/WebDecoy/edge with a “Deploy to Cloudflare” button. It is byte-identical to what the one-click installer uploads.

You bind the route yourself in that path. Deploying a Worker without a route means it runs for nothing.

Your zone must be proxied

Worker routes only fire on proxied (orange-cloud) DNS records. On a DNS-only record, Cloudflare accepts the route and the Worker never runs — the install reports success and produces nothing, indefinitely.

Whether WebDecoy can check this for you depends on how you connected:

Connection	Proxied check
API token with Zone > DNS > Read	Checked before installing; a DNS-only record is refused with a specific error
API token without it	Install proceeds and warns that it could not verify
Consent (OAuth)	Not available — see below

Consent-based connections cannot check this

Cloudflare’s OAuth permissions do not cover reading DNS records. There is no scope to grant: dns.read and dns.write are both accepted at consent and both are still refused by the DNS records API.

So if you connected by pressing Connect with Cloudflare, the install will tell you it could not verify the record. That is expected and not a misconfiguration — confirm the orange cloud yourself in DNS → Records. Everything else about the install is unaffected.

Invocations and billing

The sensor consumes a Worker invocation on your Cloudflare account for every request it runs on. Workers’ free tier is 100,000 requests/day.

The installer reduces this by binding negating routes — routes bound to no script, which stop any Worker running on a more specific path, since Cloudflare matches most-specific-first:

/_astro/*   /_next/*   /_nuxt/*   /_app/*   /assets/*   /static/*
/build/*    /dist/*    /wp-content/*   /wp-includes/*   /cdn-cgi/*

These affect every Worker on those paths, not only the sensor. If you already run a Worker that must serve them, install with negating routes disabled and manage the patterns yourself.

Troubleshooting

It says installed but reports nothing

In order of how often each is the cause:

1. Reporting is off. The card shows Reporting: On or Off. Off means the Worker is deployed but no enabled configuration is being served, so it classifies traffic and sends none of it.
2. The record is not proxied. Check for the orange cloud in Cloudflare DNS → Records. This is the most common cause of a silent install.
3. The route does not match your traffic. example.com/* does not cover www.example.com/*. Check the bound pattern against the hostname visitors actually use.
4. Nothing has crawled you yet. Crawler traffic is bursty. Give it an hour before treating silence as a fault.

The install refused

Refusals are deliberate and each names its fix:

• “already bound to the Worker …” — another Worker owns that route pattern. Cloudflare runs one Worker per matched route, so taking it over would silently stop yours. Remove or change that route, then install again.
• “Cloudflare is paused on …” — the zone is not proxying at all.
• “the DNS record for … is DNS-only” — switch the record to Proxied.
• “we cannot tell which one the sensor’s detections belong to” — your organization has several properties and none is named for the zone. Choose one; detections are filed against that property.

Detections appear under the wrong property

The sensor reports against one scanner, which belongs to one property. Re-installing and choosing a different property does not move detections that already landed.

Uninstall

From the app: Integrations → Cloudflare → Edge Sensor → Uninstall. This removes every route the installer created and then the Worker.

If you deployed it yourself, delete the route first, then the Worker. Deleting the Worker while a route still points at it leaves the route referencing a script that no longer exists, and your visitors are what discovers that.

Related

• Cloudflare Integration — WAF enforcement and credentials
• Detection Sources — how edge_worker rows differ