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 addresses to your allowlist (some tools call it a whitelist). We crawl from one IPv4 and one IPv6 address:

IPv4 72.61.159.30
IPv6 2a02:4780:41:932f::1

These are our current crawler addresses. If they ever change, 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. Add each IP with the action set to Allow, scoped to this site or your whole account.
  3. Save, then re-run the Wygard test.
Official docs →

Fastly

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

AWS WAF

  1. Create IP sets for both addresses — the IPv4 as /32 and the IPv6 as /128 — in the same Region as your Web ACL (or Global for CloudFront).
  2. Add a rule to your Web ACL referencing those IP sets 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 both IPs 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 both IPs to its allowlist.

Wordfence

  1. Go to Wordfence → Firewall → All Firewall Options.
  2. Find “Allowlisted IP addresses that bypass all rules” and add both IPs, each 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 both IPs 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 both IPs.
  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 both addresses above and they’ll add them.

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 both addresses 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 both addresses.
  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 either IP if it’s listed.
  2. If SiteGround’s WAF is still blocking us, ask support for a rule exception for both addresses.
Official docs →

Cloudways

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

Generic & self-hosted

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

Apache (.htaccess)

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

cPanel / ModSecurity

  1. In cPanel → Security → IP Blocker, remove either 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 both addresses.
Official docs →

Frequently asked questions

Will allowlisting our IPs weaken my security?
No. You’re allowing two specific, known IP addresses 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 IPs but still see a 403
Something else in the chain is still blocking us. Allowlist both addresses 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 both addresses at the server and CDN level.
Do I need to allowlist both the IPv4 and the IPv6 address?
Yes. We may crawl your site from either address, so allowlist both to be safe. If your stack is IPv4-only, the IPv4 address is enough — but adding both does no harm.
Do the crawler IPs ever change?
Rarely, but they can. This page always lists the current addresses. If your tests start failing with a 403 again after a while, check here for updated IPs.
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 both addresses everywhere and tests still come back 403, we’ll help you pin down which layer is the culprit.

Contact support

Trust, but verify.