Skip to content

Netlify extension

The WebDecoy extension injects an edge function into your site’s next build. It runs at Netlify’s edge on every request, reports the ones that look automated to WebDecoy, and leaves every response untouched. It sees crawlers that never run JavaScript, which a script tag cannot.

It changes nothing until you say so. As installed it never blocks, redirects, challenges or slows a request, and a reporting failure never affects your visitors. One more variable, when you want it, turns the same function into WebDecoy’s clearance validator for that site: see Enforcement below.

  1. Install the WebDecoy Crawler Sensor extension on your Netlify team. Installing adds it to the team; nothing changes on a site until you set the variables below.

  2. In WebDecoy, open the site’s Setup page and choose Netlify. It shows three values.

  3. On the Netlify site, under Site configuration → Environment variables, add them with the Functions scope:

    Variable What it is
    WEBDECOY_SITE_KEY The organization the sensor reports under
    WEBDECOY_SCANNER_ID This site’s detection script id
    WEBDECOY_SENSOR_KEY A secret that proves the sensor is one WebDecoy issued. Keep it in Netlify’s environment, never in a file you commit
  4. Trigger a deploy. The sensor is injected into that build.

Deployed is not verified: the Setup page waits for the sensor’s first report. Request any page with the user agent WebDecoy-Test/1.0 to prove it end to end; that request is labeled a test, not a finding.

Requests whose user agent names a known crawler or tool, requests with no user agent, requests for crawler-only paths such as /robots.txt, and browsers missing headers real browsers send. Static assets are skipped. Human visitors with ordinary browsers are never reported.

Every non-asset request invokes the edge function, which counts as an edge function invocation on your Netlify plan. The function does no network work before your response is sent.

The injected function can also be WebDecoy’s clearance validator, the same one that runs as a Cloudflare Worker or an AWS Lambda@Edge. It is off until you add a fourth variable to the site:

Variable Value
WEBDECOY_ENFORCEMENT on

Deploy again, and the next build carries the gate. What it then does is WebDecoy’s setting, not the variable’s: in Monitor it records what enforcing would have done, in Enforce it asks a request with no clearance to verify. Sites without the variable are unaffected.

Two things are particular to Netlify:

  • Verified crawlers. Netlify gives the edge no verified-bot signal, so the validator verifies search engines itself by forward-confirmed reverse DNS (Google, Bing, Yahoo, Apple, Yandex, Baidu) and accepts any bot that signs its requests (Web Bot Auth). Other crawlers you allow under access exceptions are let through only if they sign; otherwise they meet the path’s verification requirement like any other visitor.
  • Next.js middleware runs first. Netlify runs your framework’s middleware before the injected function. A request your middleware answers itself is never gated, and if your middleware rewrites a path, the gate matches protected paths against the rewritten one. Your own edge functions, your redirects and your origin all run after the gate.

To turn it off: delete the variable and deploy. The sensor keeps reporting.

WebDecoy does not manage Netlify’s own Firewall Traffic Rules. Those take an allow or deny for an IP address or a country, with no challenge, and full functionality is on Enterprise plans with High-Performance Edge. The validator above is how WebDecoy refuses a request on Netlify, and it works on every plan.

Delete the three variables and deploy again. The next build injects nothing.