InstaWP Docs

Appearance

Configure Shield ​

Shield is InstaWP's built-in, edge-level security layer for your live sites. It protects your WordPress site with a Web Application Firewall (WAF), DDoS mitigation and Bot Detection. It filters malicious traffic at the CDN edge (powered by Bunny Shield) before it ever reaches your origin server. SSL is issued and renewed automatically as part of the same protection layer.

In this documentation, we will explore:

  1. Plan availability
  2. Where to find Shield
  3. Learning Mode
  4. WAF (Web Application Firewall)
  5. DDoS Configuration
  6. Bot Detection
  7. URL Exclusions
  8. Trusted IPs
  9. Downloading logs

Plan availability ​

Shield is included on all paid, public-facing plans: Starter, Plus, Pro, Turbo and Elite. It is not available on the Sandbox plan, which is meant for work-in-progress environments rather than live sites. If Shield is enabled and you want to move a site down to Sandbox, you must disable Shield first (see Downgrade Site Plans). For a full feature comparison, see Site Plans.

Where to find Shield ​

Open the site from your Sites list, then in the site's left-hand menu expand Security → Shield. The Shield page groups all three protection layers on one screen, with live counters showing how much traffic each layer has acted on.

Shield settings under Security, showing the header, learning-mode banner and the WAF layer

  1. Download Logs: export the raw WAF / DDoS / Bot event log for this site.
  2. Learning Mode: Shield's safe, log-only warm-up period (see below).
  3. Layer toggle: each protection layer has its own on/off switch.

Learning Mode ​

When Shield is first enabled it enters Learning Mode for 7 days. During this window every request that matches a WAF rule is logged but never blocked, so you can review what Shield would have acted on and catch any false positives before enforcement begins. This is important if your site uses page builders, custom endpoints or automation tools.

If you are confident and want protection enforced immediately, click Exit Learning Mode.

WAF (Web Application Firewall) ​

The WAF protects your site from exploits, SQL injection and other attacks aimed at harming your site. The counters show how many requests the WAF Triggered, Blocked and Logged.

WAF layer showing the on/off toggle and the Log/Block mode selector

  1. WAF on/off: enable or disable the Web Application Firewall for this site.
  2. WAF Mode: Log records rule matches without blocking (ideal while tuning); Block actively denies malicious requests. Start in Log, then switch to Block once you have confirmed there are no false positives.

DDoS Configuration ​

DDoS mitigation absorbs volumetric and challenge-based attacks at the edge. Tune it to match your site's traffic profile. The counters show Challenges Served, Challenges Verified and Logged.

DDoS configuration showing the Valid Challenge Window setting

  1. Valid Challenge Window: how long a visitor stays trusted after passing a DDoS challenge. When it expires they must pass a new one. A shorter window is stricter; a longer window means fewer challenges for legitimate visitors.

Bot Detection ​

Bot Detection identifies and mitigates malicious or unwanted automated traffic. The counters show Bots Challenged, Challenges Verified and Blocked.

Bot Detection showing the mode selector, sensitivity controls and the service allowlist

  1. Bot Detection on/off: master switch for the whole Bot Detection layer.
  2. Bot Detection Mode: Log only records suspected bots; Challenge makes them prove they are human before reaching your site. Use Log first, then Challenge.
  3. Sensitivity controls: Request Integrity, IP Address, Browser Fingerprint and Fingerprint Aggression each tune how aggressively traffic is judged to be a bot (from Low to High). Raise them when you are under bot pressure; lower them if legitimate tools are being challenged.
  4. Service allowlist: bypass Bot Detection for trusted services. Enable Allow ManageWP Access if you manage this site with ManageWP, and Allow ShortPixel Access if you use ShortPixel to optimize images, so those services are never blocked.

Some traffic is never challenged by Bot Detection on any site, so you do not need to add exclusions for it:

  • Search engine crawlers: Googlebot (including Search Console's URL Inspection tool, AdsBot and Storebot), Bingbot, Applebot, DuckDuckBot and YandexBot. Your pages stay indexable even with Bot Detection set to Challenge.
  • Link preview crawlers: Facebook, Instagram and Messenger, WhatsApp, X (Twitter), LinkedIn, Slack, Discord, Telegram, Reddit, Pinterest, Skype and Buffer. Links to your site show a proper preview card when they are shared.
  • WordPress static files: images, CSS and JavaScript under wp-content and wp-includes. Your site's styling and media load normally, including for visitors who have not passed a challenge yet. PHP files in those folders are still protected.

The WAF and DDoS layers still apply to all of this traffic.

URL Exclusions ​

Sometimes Shield blocks or challenges a request that is legitimate, for example a webhook, a REST API call, a form submission or saving a page in your page builder. Instead of turning a whole layer off, you can exclude just the URLs that need it.

There are two separate lists, one in each card:

  • WAF URL Exclusions (in the WAF card): URLs listed here skip the firewall's rule checks. Use it when a legitimate request is being blocked as an attack.
  • Bot URL Exclusions (in the Bot Detection card): URLs listed here skip bot detection, so automated clients are never challenged on them. Use it for API endpoints, webhooks and uptime monitors.

WAF URL Exclusions list in the WAF card

Bot URL Exclusions list in the Bot Detection card

Each list only affects its own layer. Excluding a URL from the WAF does not exclude it from bot detection, and neither list changes the DDoS challenge.

To add an exclusion:

  1. Open the site's Shield page and find the WAF or Bot Detection card.
  2. Under WAF URL Exclusions or Bot URL Exclusions, click Add URL.
  3. Enter a URL pattern. Use * as a wildcard, for example */wp-json/* to cover the WordPress REST API.
  4. Click Save. Each card saves its own list, so saving one does not change the other.

Rules for what you can add:

  • Up to 20 patterns in each list.
  • A pattern that matches too much of your site (and would turn Shield off almost everywhere) is refused. Narrow it to the endpoint you need to unblock.
  • If a pattern is refused, the rest of the list is still saved and a message under that pattern explains why.

WARNING

If a pattern covers your login page, the WordPress admin area or xmlrpc.php, the dashboard shows a warning. The pattern is still applied, but Shield will not protect those paths, and they are common targets for brute-force attacks. Keep exclusions as narrow as possible.

A pattern can also become too broad after you save it, usually after you map a new domain. The dashboard flags it, and you should narrow it.

If the request comes from a fixed IP address rather than a specific URL, use Trusted IPs instead.

Trusted IPs ​

The Trusted IPs card lets you exempt specific IP addresses from Shield. Traffic from an address on this list skips both Shield layers, Bot Detection and the WAF, so it reaches your site without being challenged or blocked.

Typical reasons to add an address:

  • A security scanner or penetration test you are running against the site.
  • A migration or backup tool that connects to the site from a fixed address.
  • An uptime monitor.
  • Your own office or agency network.

Trusted IPs card on the Shield page

To add a trusted IP:

  1. Open the site's Shield page. Trusted IPs is in the Bot Detection card, below the Allow ManageWP Access toggle.
  2. Click Add IP address and enter a single address (for example 203.0.113.5) or a CIDR range (for example 203.0.113.0/24).
  3. Click Save. To stop trusting an address, click Remove beside it and save again.

Rules for what you can add:

  • Up to 10 addresses or ranges per site.
  • IPv4 and IPv6 are both supported. The widest range accepted is /24 for IPv4 and /48 for IPv6.
  • The address must be public. Private, loopback and reserved addresses are refused, because your visitors can never arrive from them.
  • Enter an IPv4 address on its own, not written in IPv6 form.

If an address is refused, the list is still saved and a message under that address explains why it was not applied.

WARNING

Only add addresses you control or fully trust. Anything on this list is exempt from Shield on this site, so an address you do not control opens the site to whoever uses it.

Downloading logs ​

Use the Download Logs button at the top of the Shield page to export the event log for this site. Reviewing the log is the best way to confirm that Shield is blocking genuine threats and not legitimate traffic, especially before you exit Learning Mode or switch a layer from Log to Block.

Tip: The safe rollout order for any layer is Log → review the logs → Block. If a legitimate request is ever blocked, drop the affected layer back to Log (or lower its sensitivity) while you investigate.

Docs are open. Edit them on GitHub. Built with VitePress.

© InstaWP