Allow AudioEye Agentic Audits Through Your Bot Protection

If a page in your Agentic audit shows Blocked by site, your CDN, firewall, or bot manager answered our audit browser with a challenge or a denial instead of the page, so there was nothing for us to check. Nothing is wrong with your site. Whoever manages your bot protection can allowlist AudioEye in about ten minutes, plus however long your vendor takes to publish the change.

Before you start

• Add both the IP addresses and the user agent. Several bot managers challenge a visitor before any IP rule runs, so an IP-only allowlist often isn't enough.
• Confirm which protection blocked us. The blocked page in your audit names it. Some sites run two layers, and changing the wrong one has no effect.

What to allowlist

If your tool asks for the full user agent our audit browser sends today:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko; compatible; AudioEyeMonitoringBot) Chrome/131.0.0.0 Safari/537.36

Add the allow rule

These steps work with any tool. If you know your vendor, its rule under Rules by vendor is faster.

1. Find who manages your CDN or firewall. This is usually the team that owns your DNS or hosting.
2. Add the three IP addresses to an allow rule, and place it ahead of any bot-management or rate-limiting rule. Most tools evaluate rules in order and stop at the first match, so a rule below the bot rule never runs.
3. Add a user agent rule that matches user agent contains AudioEyeMonitoringBot. If your tool runs a JavaScript or managed challenge on every new visitor, set this rule to skip that challenge as well as the block.
4. Retry the page. Open the audit, find the page marked Blocked by site, and select Retry.

Rules by vendor

Match the blocked page against the How to tell column to find your vendor.

Cloudflare

The settings live in Security > WAF > Custom rules and Security > Bots.

Create a custom rule with this expression:

(ip.src in {35.84.232.39 44.235.14.160 54.214.155.2}) or (http.user_agent contains "AudioEyeMonitoringBot")

Set the action to Skip. Select All remaining custom rules, and under WAF components select Super Bot Fight Mode, Managed rules, Rate limiting, and Browser Integrity Check.

• On the Free plan, no rule can skip Bot Fight Mode. Turn it off while the audit runs, or use a plan with Super Bot Fight Mode.
• An IP Access Rule (Security > WAF > Tools) set to Allow is a useful backup, but on its own it doesn't exempt requests from a browser challenge.

Akamai

The settings live in your App & API Protector security configuration, plus Bot Manager if you license it.

Create a network list and allow it in the IP/Geo Firewall:

Network list: 35.84.232.39, 44.235.14.160, 54.214.155.2 IP/Geo Firewall: Allow

If you run Bot Manager, also define a custom bot category that matches user agent contains "AudioEyeMonitoringBot" and set its action to Allow rather than Monitor.

• Akamai changes need activation to production, which takes several minutes. Wait for activation to finish before you retry the page.

Imperva (Incapsula)

The settings live in Cloud WAF > your site > Security > Settings > Allowlist. Add our IP addresses to the allowlist:

Allowlist IPs: 35.84.232.39, 44.235.14.160, 54.214.155.2

Under Bot Access Control, add an exception for user agent contains "AudioEyeMonitoringBot" and set its client classification to allowed.

• Imperva classifies automated browsers before your URL rules run, so the user agent exception matters more here than with other vendors. An IP allowlist alone often isn’t enough.

DataDome

The settings live in DataDome dashboard > Protection > Custom rules (Allowlist). Create a custom rule with this condition:

Allow when: IP in {35.84.232.39, 44.235.14.160, 54.214.155.2} OR User-Agent contains "AudioEyeMonitoringBot"

Set the rule action to Allow, and confirm it applies to all endpoints rather than only the homepage.

• DataDome allowlist rules take effect within about a minute, so you can retry the page right away.

HUMAN (PerimeterX)

The settings live in HUMAN console > Policy > Allowlist. Add both allowlist entries:

Allowlist by IP: 35.84.232.39, 44.235.14.160, 54.214.155.2

Allowlist by User-Agent: contains "AudioEyeMonitoringBot"

Apply the allowlist to every application that fronts the pages being audited.

• HUMAN applies allowlists per application. If several applications serve your site, the entry has to exist in each one.

AWS WAF

The settings live in WAF & Shield > your Web ACL > Rules. Create an IP set and an allow rule:

IP set "audioeye-audit": 35.84.232.39, 44.235.14.160, 54.214.155.2

Rule "Allow AudioEye audit": action Allow, priority above Bot Control

Alternatively, add a scope-down statement to the Bot Control managed rule group that excludes the IP set, or excludes user agent contains "AudioEyeMonitoringBot".

• Rules run in priority order and an Allow terminates evaluation, so the allow rule must sit above AWSManagedRulesBotControlRuleSet.
• Bot Control applies its Challenge and CAPTCHA actions before the request reaches your origin, so make the fix in the Web ACL rather than the origin firewall.

Vercel

The settings live in Vercel dashboard > your project > Settings > Security (Firewall). Create a firewall rule:

IP Address is one of: 35.84.232.39, 44.235.14.160, 54.214.155.2

Or: User-Agent contains "AudioEyeMonitoringBot"

Action: Allow (bypass)

If Attack Challenge Mode is on, the allow rule has to bypass it. A rule that only skips rate limiting still leaves the checkpoint in place.

• The checkpoint returns a real HTML page, so an audit that reaches it reports a handful of components and no issues instead of an outright failure. If a Vercel-hosted page comes back suspiciously empty, check this first.

Other or self-hosted

Depending on your setup, the setting lives in your origin firewall, nginx or Apache rules, hosting provider’s security panel, or rate limiter. Add an allow rule:

Allow 35.84.232.39, 44.235.14.160, 54.214.155.2 before any deny or rate-limit rule

Where the tool supports matching on user agent, add contains "AudioEyeMonitoringBot" to the same allow rule.

• Check your rate limiter as well as your firewall. An audit requests many pages in a short window, which some default rate limits treat as abuse.

If the page is still blocked

Most failed allowlists come down to one of these:

• Only one of the three IP addresses was added.
• The allow rule sits below the bot rule, so it never runs.
• The IPs were allowed at the origin server, but the block happens at the CDN in front of it.
• The rule skips the block action but not the challenge action, so the audit still gets an interstitial.
  

If none of those apply:

1. Confirm the rule is live. Some vendors need a separate publish or activation step after you save a rule, and Akamai in particular takes several minutes.
2. Check your WAF or CDN log at the time of the retry for a request from one of our three IP addresses. If the request is there and was still blocked, your rule didn't match, and the expression needs another look.
3. Check for a second layer. A site behind both a CDN and an origin firewall, or behind two bot products, needs the allowlist in each. The log shows which layer answered.
4. Send it to us. Contact AudioEye support with the page URL, the rule you added, and the time of the retry.

FAQ

Is this traffic safe to allow? Yes. The audit only reads pages. It loads a page the way a visitor's browser would, inspects what's on it, and moves on. It doesn't submit forms, make purchases, or change anything on your site.

Does a retry use up my page allowance? No. A retry after a block doesn't count against your page allowance.