Wygard help

Seeing a 403 in your Wygard tests?

A 403 means something on your side — a CDN, firewall, or security plugin — is blocking our crawler before it reaches your page. Here’s how to let us through.

Why this happens

When Wygard checks one of your pages, our crawler requests it like any other visitor. If a CDN, web application firewall (WAF), host-level firewall, or a WordPress security plugin decides the request looks unfamiliar, it can return a 403 Forbidden before WordPress even runs. The page itself is usually fine — the request just never gets through. The fix is to tell that layer our crawler is welcome.

The fix — allowlist our crawler

Add our crawler’s IP address to your allowlist (some tools call it a whitelist). It’s a single IPv4 address:

Wygard crawler IP
72.61.159.30

This is our current crawler IP. If it ever changes, this page is always the source of truth — bookmark it. After allowlisting, re-run the test; the 403 should clear within a few minutes.

Allowlisting by platform

Not sure which layer is blocking us? Work top-down — CDN or WAF first, then any WordPress security plugin, then your host. Allowlisting in more than one place is harmless.

CDN & web application firewalls

A CDN or WAF sits in front of your site and is the most common source of a 403. Start here.

Cloudflare

  1. Open Security → WAF → Tools → IP Access Rules.
  2. Enter the IP, set the action to Allow, and scope it to this site or your whole account.
  3. Add the rule, then re-run the Wygard test.
Official docs →

Fastly

  1. Edit your service and open its ACL (access control list).
  2. Add the IP as an allow entry and save.
  3. Activate the new service version.
Official docs →

AWS WAF

  1. Create an IP set containing the IP as /32, in the same Region as your Web ACL (or Global for CloudFront).
  2. Add a rule to your Web ACL referencing that IP set with the action Allow.
  3. Move the Allow rule above any Block rules.
Official docs →

Sucuri Firewall

Sucuri restructures its docs often — from the docs home, search “allowlist IP”.

  1. In the Sucuri dashboard, open Firewall → Settings → Allowlist.
  2. Add the IP under Allowlisted IP Addresses.
  3. Apply the change and re-test.
Official docs →

WordPress security plugins

If you run a security plugin, it can block our crawler from inside WordPress. Add the IP to its allowlist.

Wordfence

  1. Go to Wordfence → Firewall → All Firewall Options.
  2. Find “Allowlisted IP addresses that bypass all rules” and add the IP on its own line.
  3. Save changes.
Official docs →

Solid Security

Formerly iThemes Security; now Kadence Security.

  1. Open Security → Settings and find the Authorized Hosts / IP allowlist field.
  2. Add the IP and save.
Official docs →

All-In-One Security (AIOS)

  1. Go to WP Security → Firewall → Internet Bots, or the Blacklist Manager.
  2. Open the IP allowlist and add the IP.
  3. Save settings.
Official docs →

Managed WordPress hosts

Some managed hosts apply their own firewall. A few have no self-serve allowlist — open a support ticket with the IP above and they’ll add it.

WP Engine

No self-serve IP allowlist — request it from support.

  1. Open a chat or ticket from the WP Engine User Portal.
  2. Ask them to allowlist the IP at the server and CDN level for your environment.
Official docs →

Kinsta

Kinsta fronts sites with its own Cloudflare — allowlisting needs support.

  1. In MyKinsta, open a support ticket and ask them to allowlist the IP.
  2. If you run your own Cloudflare in front of Kinsta, use the Cloudflare steps above too.
Official docs →

SiteGround

  1. In Site Tools, open Security → Blocked IPs and remove the IP if it’s listed.
  2. If SiteGround’s WAF is still blocking it, ask support for a rule exception for the IP.
Official docs →

Cloudways

  1. In the Cloudways console, open your server’s Security → Bot Protection.
  2. Add the IP to the Whitelist tab and save.
Official docs →

Generic & self-hosted

On your own server, allow the IP at the web-server or control-panel level.

Apache (.htaccess)

  1. On Apache 2.4, add Require ip 72.61.159.30 to the relevant block.
  2. On legacy Apache 2.2, use Allow from 72.61.159.30 with Order Allow,Deny.
Official docs →

cPanel / ModSecurity

  1. In cPanel → Security → IP Blocker, remove the IP if it appears in the blocked list.
  2. If ModSecurity is triggering, disable the offending rule for your domain or ask your host to whitelist the IP.
Official docs →

Frequently asked questions

Will allowlisting our IP weaken my security?
No. You’re allowing one specific, known IP address to reach your pages — the same way you’d allow an uptime monitor or your own office IP. Every other request is still filtered exactly as before.
I allowlisted the IP but still see a 403
Something else in the chain is still blocking us. Allowlist the IP in every layer you run — CDN or WAF, WordPress security plugin, and host firewall — since any one of them can return a 403 on its own. On managed hosting like WP Engine or Kinsta, open a support ticket and ask them to allowlist 72.61.159.30 at the server and CDN level.
Does the crawler IP ever change?
Rarely, but it can. This page always lists the current address. If your tests start failing with a 403 again after a while, check here for an updated IP.
Can I allowlist by User-Agent instead of IP?
IP allowlisting is the most reliable method and the one we recommend. If your firewall only filters by request signature and you’d rather allow us that way, contact us and we’ll share our crawler’s User-Agent.

Still blocked?

If you’ve allowlisted the IP everywhere and tests still come back 403, we’ll help you pin down which layer is the culprit.

Contact support

Trust, but verify.