Skip to content

For website owners

Let ScanDefend in,in about two minutes.

If your firewall or bot protection stopped our check, that means it is working. Here is how to let our identified check through, then run it again.

ScanDefendBot/1.0 (+https://scandefend.com/bot)

The idea

You stay in control.We never try to get around protection.

Our check names itself as ScanDefendBot, but anyone can send that name, so a rule must never rely on it alone. A rule that lets us in should require your private access token, which you get by verifying your domain in ScanDefend. You decide whether to let us in, and for how long.

Cloudflare

A custom rulethat skips the checks for us.

Cloudflare can let our check through while it stays on for everyone else.

  1. In Cloudflare, open your site, then Security, Security rules, Create rule (custom rule).
  2. Use this expression. Replace YOUR_TOKEN with your scanner access token. Keep both lines: the X-ScanDefend-Token header is what proves it is us. No token yet? Verify your domain to get one, or contact your provider or host.
(http.user_agent contains "ScanDefendBot")
and any(http.request.headers["x-scandefend-token"][*] eq "YOUR_TOKEN")
  1. Choose the action Skip and tick managed rules, rate limiting and Super Bot Fight Mode.
  2. Put the rule first in the list, save it, and run the check again.

Free plan? Bot Fight Mode can't be skipped.

A rule can't skip Bot Fight Mode on the free plan. Turn it off for a moment, or move to a plan with Super Bot Fight Mode, then run the check.

AWS WAF

A header ruleset to Allow.

AWS WAF can allow a request that carries our access token.

  1. In AWS WAF, open your web ACL, then Add rules, Add my own rules, Rule builder.
  2. Inspect the single header X-ScanDefend-Token and match it exactly to your token.
  3. Set the action to Allow.
  4. Give it a lower priority number than your managed rule groups, so it runs first. Run the check again.

The token needs a verified domain in ScanDefend. No token yet? Verify your domain to get one, or ask your provider or host.

Akamai, Imperva, Fastly

Match our headerwhere your plan supports it.

These services can usually allow a request by a header it carries.

  1. Ask whoever manages the service for your site to add an allow rule for requests whose X-ScanDefend-Token header equals your token. (They can also match ScanDefendBot as an extra condition, never on its own.)
  2. No token yet? Verify your domain to get one, or contact your provider or host.
  3. If your plan can't match on a header, ask your provider what they can offer. We'd rather you say no than weaken your protection.
  4. Run the check again.

Wordfence

Its exceptions are scoped.Ask Wordfence or your host.

Here is what Wordfence documents, and where it stops.

  • Wordfence can leave a chosen page and request parameter out of its firewall rules (allowlisted URLs). It is meant for false alarms on a page you pick, so it may not fit a check of your homepage.
  • Rate limiting and blocking of bots are separate Wordfence features. An allowlisted URL may not cover them, so a check can still be turned away.
  • Best next step: ask Wordfence support, or your host, which exception (if any) lets an identified check read your homepage. Wordfence firewall help.

We haven't tested a specific Wordfence setting, so we won't promise one. As a last resort you can pause the firewall briefly for a check and switch it back on straight after.

Sucuri

It can allow a URL path.With limits.

Here is what Sucuri documents, and where it stops.

  • Sucuri can allow a URL path (Allow URL Paths, in its firewall settings). It applies to every visitor, so Sucuri advises it only for paths that must be open to everyone.
  • It does not bypass Sucuri's signature blocks or JavaScript challenges, so a check can still be turned away.
  • Best next step: ask Sucuri support, or your host, which exception (if any) lets an identified check read your homepage. Sucuri: allow a URL path.

We haven't tested a specific Sucuri setting, so we won't promise one. As a last resort you can pause the block briefly for a check and switch it back on straight after.

Not sure what you have?

A plain "403"means we can't tell.

Sometimes the answer is just "no" with no name on it. It can be a firewall, your host or the site itself.

  1. Ask your host or whoever runs the site which firewall or bot protection is on.
  2. Tell them our checks identify as ScanDefendBot and read public pages only. A name alone is not enough to trust: any exception should require your token. About our scanner.
  3. If the site asks for a login before it shows its homepage, that is expected: we only check pages anyone can open.
  4. Your credit is returned whenever a site blocks the check, so there is nothing to lose by trying.