Fix: WordPress security plugins block the crawl (Wordfence, Solid Security, Sucuri, LiteSpeed)

WordPress security plugins block traffic that looks automated: many page views in a short time, data-centre IPs, or User-Agents they don’t know. Our crawler and audits trip these rules. The fix is to allowlist our addresses, not to remove the plugin.

What to allowlist

• IPv4 147.93.19.85 and IPv6 2a02:4780:12:d33e::1
• User-Agent token SEOAuditSoftware (Site crawl, GEO and Local SEO audits only; classic audits use a normal Chrome User-Agent, so allowlist by IP)

Full details: What to allowlist.

Find which plugin blocks

1. Run this in a terminal (replace example.com):

curl -sS -A "SEOAuditSoftware" -o block.html -w "%{http_code}\n" https://example.com/ ; grep -oiE "wordfence|limited by the site owner|sucuri|imunify360|solid security|ithemes|aios|all in one|shield|ninjafirewall|mod_security|not acceptable" block.html | sort -u

2. Match the result:

3. If you have WordPress admin access, you can also check the plugin’s log for 147.93.19.85 (paths in each section below).

Wordfence

How we detect it

Crawl pages return 403 (blocked) or 503 (rate limited, “temporarily limited”), often after the first few pages. Audits fail with Audit failed: the site blocks automated page downloads (403). The block page says “Your access to this site has been limited by the site owner”.

Why it matters

Once Wordfence blocks our IP, every later request fails for the block duration, so a whole crawl can end with errors.

Common causes

• If pages work at first and then fail → Rate Limiting (“If a crawler’s page views exceed” or “If anyone’s requests exceed”).
• If it fails from the first request → our IP was blocked earlier (still in the block list), or Country blocking (Premium) covers our server’s country, or the Wordfence Premium IP blocklist.
• If it fails only on some URLs → a firewall rule matched the URL (rare for normal pages).

Fix: basic

Allowlist our IPs

1. In WordPress admin, go to Wordfence › Firewall (direct path on your site: /wp-admin/admin.php?page=WordfenceWAF&subpage=waf_options).
2. Click All Firewall Options. Wordfence’s own guide: Firewall options.
3. Open Advanced Firewall Options.
4. In Allowlisted IP addresses that bypass all rules, add 147.93.19.85 and 2a02:4780:12:d33e::1, one per line.
5. Click Save Changes (top right).

Remove an existing block

1. Go to Wordfence › Firewall › Blocking (older versions: Wordfence › Blocking). See Wordfence blocking help.
2. Find 147.93.19.85 in the list of blocks, tick it and click Unblock.

Relax rate limiting (optional)

1. Go to Wordfence › Firewall › All Firewall Options › Rate Limiting (Wordfence rate limiting help).
2. Set If a crawler’s page views exceed to 240 per minute or Unlimited, and the action to throttle it rather than block it.
3. Leave How should we treat Google’s crawlers as you like; it does not affect us.
4. Click Save Changes.

Fix: expert

Find the exact rule that blocked us in Live Traffic:

1. Go to Wordfence › Tools › Live Traffic.
2. Filter or search for 147.93.19.85.
3. Rows marked Blocked show the rule that blocked us.

Platform steps

WordPress

All steps above. Wordfence Login Security (2FA, login CAPTCHA) doesn’t affect crawls.

Cloudflare

If Cloudflare is in front, Wordfence may see Cloudflare’s IP instead of ours. Set Wordfence › All Options › General Wordfence Options › How does Wordfence get IPs to Use the Cloudflare “CF-Connecting-IP” HTTP header, so the allowlist matches our real IP.

Verify the fix

1. Click Crawl again in Site crawl.
2. In Wordfence › Tools › Live Traffic, our requests show as normal visits, not Blocked.
3. The Pages tab shows 200 status codes.

Automation

Assisted: needs WordPress admin access (Wordfence settings).

Solid Security (formerly iThemes Security)

How we detect it

Pages return 403, or the site shows a lockout message, after our IP was banned or locked out. Audits fail with a 403.

Why it matters

A ban in Solid Security applies to the whole site and can last hours or be permanent.

Common causes

• If our IP appears under banned IPs → a lockout became a permanent ban (repeated 404s or lockouts).
• If the block happens from the first request → Ban Users with the Default Ban List or a custom list of User-Agents.
• If 404 detection is on → a crawl that finds many broken links can trigger 404 Detection lockouts.

Fix: basic

Authorized IPs (never locked out)

1. In WordPress admin, go to Security › Settings (plugin: Solid Security).
2. Open Global Settings (in newer versions: Security › Settings › Configure › Global Settings, section Lockouts).
3. In Authorized IPs (older name: Authorized Hosts List), add 147.93.19.85 and 2a02:4780:12:d33e::1, one per line.
4. Click Save.

Remove a ban

1. Go to Security › Firewall (older versions: Security › Settings › Banned Users).
2. Open Banned IPs or Lockouts, find 147.93.19.85 and click Unban or Release lockout.

User-Agent ban list

1. Go to Security › Settings › Features › Firewall (older versions: Security › Settings › Banned Users).
2. Under Ban User Agents, remove any line that matches SEOAuditSoftware, Chrome/141, HeadlessChrome or generic words like bot.
3. Click Save.

Fix: expert

404 Detection counts 404s per IP. If the site has many broken links, either fix them (see Fix: Broken internal links (4xx)) or raise the Error Threshold in Security › Settings › Features › Site Check / 404 Detection while you crawl.

Platform steps

WordPress

To find the reason for a block, open Security › Logs and filter for 147.93.19.85.

Verify the fix

Security › Logs shows no new lockouts for our IP after Crawl again in Site crawl, and the Pages tab shows 200 status codes.

Automation

Assisted: needs WordPress admin access.

Sucuri

How we detect it

The block page says “Access Denied - Sucuri Website Firewall” and responses carry x-sucuri-id or server: Sucuri/Cloudproxy headers. Some blocks show a JavaScript challenge page.

Why it matters

The Sucuri Firewall sits in front of the site, so a block there never reaches WordPress. Allowlisting in the Sucuri plugin alone doesn’t help.

Common causes

• If the page says “Access Denied” with a block reason such as “Bad bot access attempt” → Sucuri’s bot rules.
• If a JavaScript challenge appears → Emergency DDoS protection or a protected-page setting is on.
• If only some countries are blocked → Sucuri’s geo-blocking.

Fix: basic

Allowlist our IPs in the Sucuri Firewall dashboard

1. Log in to the Sucuri Firewall dashboard and open Firewall (WAF) for the site (Sucuri docs).
2. Go to Settings › Access Control.
3. In Allowlist IP Addresses (older label: Whitelist IP Addresses), add 147.93.19.85, click Submit.
4. Add 2a02:4780:12:d33e::1 the same way.
5. Wait 1–2 minutes for the change to spread.

Turn off challenges while you crawl

1. Go to Settings › Security.
2. Turn off Emergency DDoS Protection if you don’t need it right now.
3. In Settings › Access Control › Blocked User Agents, remove any rule that matches SEOAuditSoftware or bot.

Geo-blocking

1. Go to Settings › Access Control › Geo Blocking.
2. Make sure country blocking doesn’t block our server: allowlisted IPs are let through, so step 3 of the first procedure covers this.

Fix: expert

To find the block reason, open Reports › Audit Trails in the Sucuri Firewall dashboard and filter for 147.93.19.85. The reason tells you which setting to change.

Platform steps

WordPress

The Sucuri Security plugin (malware scan, hardening) doesn’t block crawls on its own. Its Hardening options don’t affect normal pages.

Verify the fix

curl the home page: no Access Denied text and status 200. Audit Trails shows our requests as allowed. Then Crawl again in Site crawl.

Automation

Assisted: needs Sucuri Firewall dashboard access (or its API key and secret).

All-In-One Security (AIOS)

How we detect it

Pages return a plain 403 Forbidden. AIOS writes blocking rules into .htaccess or runs a PHP firewall.

Why it matters

The 6G rules and bot rules block whole classes of requests, which can include our crawler and audits.

Common causes

• If Block fake Googlebots is on → it doesn’t match us (we don’t claim to be Googlebot), so look elsewhere.
• If the 6G (or 5G) firewall rules are on → the User-Agent or URL rules can match.
• If our IP is in the Blacklist Manager or a login lockout list → blocked from the first request.

Fix: basic

1. In WordPress admin, go to WP Security › Firewall (plugin: All-In-One Security).
2. Open the tab with 6G Blacklist Firewall Rules (in newer versions under Firewall rules).
3. Untick the 6G (and 5G) user-agent option, or the whole 6G set, and click Save settings.
4. Go to WP Security › Blacklist Manager (newer versions: WP Security › Firewall › Blacklist). Remove 147.93.19.85 from the IP list and any matching User-Agent line. Save.
5. If the crawl still fails, open WP Security › Firewall › Internet bots and untick Block fake Googlebots to rule it out.

Fix: expert

AIOS rules live in .htaccess between # BEGIN All In One WP Security and # END All In One WP Security. Don’t edit that block by hand: AIOS rewrites it on save. Change the settings above instead.

Platform steps

WordPress

Login lockouts (WP Security › Brute Force) don’t affect crawls.

Verify the fix

curl the home page with our User-Agent: status 200. Then Crawl again in Site crawl.

Automation

Assisted: needs WordPress admin access.

LiteSpeed Cache and QUIC.cloud

How we detect it

Responses carry headers like x-qc-pop, x-qc-cache or x-litespeed-cache, and the page is a reCAPTCHA or “verifying” page, or a 403/429 from the LiteSpeed server.

Why it matters

The LiteSpeed Cache plugin doesn’t block anyone. Blocks come from the QUIC.cloud CDN or from the LiteSpeed web server’s bot protection set by the host.

Common causes

• If the domain uses the QUIC.cloud CDN → its security (reCAPTCHA, anti-bot, IP rules) can challenge us.
• If the host runs LiteSpeed Web Server with reCAPTCHA protection on high load → our crawl can trigger it.

Fix: basic

QUIC.cloud CDN

1. Log in to the QUIC.cloud dashboard and open the domain.
2. Go to CDN › CDN Config (or CDN Settings), then the Security section.
3. Add 147.93.19.85 and 2a02:4780:12:d33e::1 to the IP allowlist.
4. Turn off or relax reCAPTCHA / anti-bot challenges for normal pages.
5. Save and wait a few minutes.

LiteSpeed server bot protection (host level)

1. In cPanel, open LiteSpeed Web Cache Manager if your host provides it; server-wide reCAPTCHA settings are in the host’s WHM › LiteSpeed Web Server, which only the host can change.
2. If you can’t reach these settings, send the host these exact lines: “Please allowlist 147.93.19.85 and 2a02:4780:12:d33e::1 in LiteSpeed reCAPTCHA / bot protection and in the server firewall for our site example.com.”

Fix: expert

LiteSpeed Web Server allows trusted IPs in Server Configuration › Security › Access Control › Allowed List (WebAdmin console) and reCAPTCHA bypass via Server › Security › reCAPTCHA Protection › Bot White List: add SEOAuditSoftware.

Platform steps

WordPress

In LiteSpeed Cache › General (plugin: LiteSpeed Cache), a connected QUIC.cloud account shows the CDN status. Turn page caching on (LiteSpeed Cache › Cache › Enable Cache: ON): cached pages load fast, which also prevents timeouts and 5xx errors during crawls (see Fix: Server errors (5xx)).

Verify the fix

curl shows status 200 with no reCAPTCHA HTML. Then Crawl again in Site crawl.

Automation

Assisted: needs QUIC.cloud dashboard access, or host (WHM/WebAdmin) access for server settings.

Imunify360 (on the host)

How we detect it

The block page says “Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted”, or you get a “Captcha” splash page or a 403 or no response.

Why it matters

Imunify360 runs on the server below WordPress, so no plugin setting can override it.

Common causes

• If the page mentions Imunify360 → its WebShield or bot-protection blocked us.
• If there is no response at all → Imunify360’s firewall greylisted or blacklisted our IP.

Fix: basic

1. Log in to cPanel and open Security › Imunify360 (if your host gives users access; Imunify360 docs).
2. Go to Firewall › White list (newer label: Allowlist).
3. Click Add, enter 147.93.19.85, add the comment SEOAuditSoftware, and save.
4. Repeat for 2a02:4780:12:d33e::1.
5. If you don’t see Imunify360 in cPanel, send the host these exact lines: “Please add 147.93.19.85 and 2a02:4780:12:d33e::1 to the Imunify360 whitelist (allowlist) for example.com. They are our SEO audit tool’s server.”

Fix: expert

With root SSH access:

imunify360-agent whitelist ip add 147.93.19.85 --comment "SEOAuditSoftware"
imunify360-agent whitelist ip add 2a02:4780:12:d33e::1 --comment "SEOAuditSoftware"
imunify360-agent whitelist ip list | grep -E "147.93.19.85|2a02:4780"

Platform steps

cPanel / WHM

WHM: Plugins › Imunify360 › Firewall › White list.

Verify the fix

curl shows status 200 without the Imunify360 page. Then Crawl again in Site crawl.

Automation

Assisted: needs cPanel (if Imunify360 is exposed) or root SSH on the server.

Other plugins (Shield Security, NinjaFirewall, Block Bad Queries)

How we detect it

A 403 or a “silentCAPTCHA”/bot-check page, with no Wordfence, Sucuri or Imunify360 text.

Why it matters

These plugins score or filter visitors and can treat a crawler as a bad bot.

Common causes

• If Shield Security is installed → its AntiBot System (silentCAPTCHA) or IP auto-blocking.
• If NinjaFirewall is installed → its bot or User-Agent rules.
• If Block Bad Queries (BBQ) is installed → long or unusual query strings in URLs.

Fix: basic

Shield Security

1. In WordPress admin, go to ShieldPRO/Shield › IP Manager (or Security › IP Rules). Plugin: Shield Security.
2. Add 147.93.19.85 and 2a02:4780:12:d33e::1 as Bypass IPs.
3. Remove our IP from the Blocked list if it’s there.

NinjaFirewall

1. In WordPress admin, go to NinjaFirewall › Access Control (plugin: NinjaFirewall).
2. Add 147.93.19.85 and 2a02:4780:12:d33e::1 under IP Access Control › Allow the following IP.
3. Under Bot Access Control, remove any rule that matches SEOAuditSoftware.
4. Click Save.

Block Bad Queries

1. Temporarily deactivate it under Plugins (/wp-admin/plugins.php) and run the crawl in Site crawl to confirm it is the cause. Plugin: Block Bad Queries.
2. BBQ Pro has an allowlist under BBQ › Settings; add our User-Agent token SEOAuditSoftware.

Fix: expert

To prove which plugin blocks, deactivate security plugins one at a time on a staging copy, or temporarily on live during a quiet hour, and repeat the curl test.

Platform steps

WordPress

With WP-CLI, list active security plugins:

wp plugin list --status=active --fields=name,version | grep -iE "security|firewall|shield|ninja|wordfence|sucuri|bbq|aios"

Verify the fix

curl returns 200, then Crawl again in Site crawl shows normal status codes.

Automation

Assisted: needs WordPress admin access.

Common questions

Related articles

• Fix: Site can't be crawled (server errors, blocks and timeouts)
• Fix: Cloudflare blocks the crawl or audit (403, 'Just a moment', 429)
• Fix: 403 and 429 from the server, host firewall or ModSecurity (nginx, Apache, cPanel, Plesk, hPanel)
• Fix: Server errors (5xx) — 500, 502, 503, 504
• Crawl a whole website
• An audit failed or did not finish

Still need help?

Ask in the chat inside the app, or send us a message on the contact page. You can also browse all help topics.