Allowing scans through Cloudflare Technote TN-W22

Cloudflare’s bot protection may block OnDemand scans before any pages are fetched. Scans of an affected site show 403 Forbidden errors (or a Cloudflare challenge page) instead of the usual results, often starting with the home page.

This technote describes the narrowest Cloudflare exception that allows scans through, without disabling bot protection for other visitors.

Identifying scan requests

IP addresses. Each OnDemand account scans from a fixed set of IP addresses, listed on your account page (see Technote TN-Q12). Scans are not routed through shared or rotating proxy networks. The list can change - we notify customers in advance when it does - so review your Cloudflare rule if scans start being blocked again.

User-Agent. Cloud scans send the embedded browser’s User-Agent string with the product name and version appended - the current strings are listed under Cloud User Agents on the user agents page, for example:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.4129.78 Safari/537.36 Edg/151.0.4129.78 SortSiteCmd/2026.60.2064

Match on the SortSiteCmd/ token (sitemap scans use MapperCmd/) - the version numbers change every few weeks, so match the token, not the full string. The User-Agent alone should not be trusted - anyone can send it - so combine it with the IP addresses, which are the reliable signal.

Verifying a request came from us. Reverse DNS for each scanner IP resolves to a *.powermapper.com hostname, and a forward lookup of that hostname returns the same IP (forward-confirmed reverse DNS). Your Cloudflare security event log shows the source IP, which you can check against your account’s list.

How scans behave

Scans respect robots.txt
A scan fetches one page at a time - page resources (images, CSS, scripts) load in parallel, as in a normal browser visit
The scanner honors HTTP 429 responses and Retry-After headers

Scan traffic looks like one fast reader, not a flood - but it is faster than a human, so rate limiting rules tuned for human visitors may trigger.

Cloudflare configuration

The narrowest exception is a WAF custom rule with the Skip action, matching your scanner IPs (custom rules run before bot protection in Cloudflare’s evaluation pipeline):

In Cloudflare, go to Security > WAF > Custom rules and create a rule
Use an expression matching your account’s scanner IPs, optionally combined with the User-Agent token:

(ip.src in {203.0.113.10  203.0.113.11  203.0.113.12} and (http.user_agent contains "SortSiteCmd/" or http.user_agent contains "MapperCmd/"))

Replace the 203.0.113.x example IPs above with the list from your account page

Set the action to Skip, and select the protections that are blocking scans:
- Super Bot Fight Mode
- Rate limiting rules
- Browser Integrity Check (under products to skip)
- Managed rules - only if your security events show WAF managed rules blocking scans; otherwise leave them on

Including the User-Agent condition means the exception only applies to requests that both come from your scanner IPs and identify as the scanner - the narrowest practical rule.

Free plan note: Bot Fight Mode on the Free plan runs outside Cloudflare’s ruleset engine and cannot be bypassed by custom rules or IP allowlists. The options are to upgrade to a plan with Super Bot Fight Mode (which honors Skip rules), or to turn Bot Fight Mode off while scans run.

Alternative: an IP Access rule with the Allow action for the scanner IPs also bypasses Super Bot Fight Mode, but it is broader than a Skip rule - it cannot be combined with a User-Agent condition or limited to specific protections.

If scans are still blocked after adding the rule, check Security > Events in Cloudflare for the blocked requests - the “Service” column shows which protection fired, telling you what else the Skip rule needs to cover. Our support team can cross-reference a scan ID against the Cloudflare event timestamps if needed.

Applies To: OnDemand

Last Reviewed: September 28, 2026