GuardPress Documentation

Seven modules turn on automatically at activation: the Firewall, Brute-Force Protection, the Malware Scanner, File Integrity Monitor, XMLRPC Protection, WP Version Hiding, and File-Editing Lockdown. Two-Factor Authentication and Email Alerts are off by default because they need your input (a phone for 2FA, an email address and working SMTP for alerts). Uptime Monitoring and custom Security Headers are also off by default and can be enabled after the first-week review.

About 30 minutes end to end. The 2FA setup is the longest step (5–10 minutes to install an authenticator app, scan the QR code, save backup codes, and test signing back in). Email alerts take 5 minutes to enable plus however long it takes to install an SMTP delivery plugin if your host doesn’t run its own. Everything else is either already on or a one-click confirm. Follow Quick Start for the exact order.

Almost always one of two things. Either the CAPTCHA / Cloudflare Turnstile widget isn’t rendering on the login form they’re using (WooCommerce my-account, MemberPress, a page-builder login widget), or their IP tripped brute-force because they use a corporate NAT that a colleague also uses. See CAPTCHA Blocks WooCommerce/MemberPress Login for the first case, and whitelist the shared IP for the second.

Yes, one important thing. Without configuring the Cloudflare real-IP resolver, every request looks like it’s coming from Cloudflare’s IPs, so brute-force lockouts trigger against Cloudflare and geographic rules never work. See Country Blocking and the Cloudflare Real-IP Gotcha. This is a pre-flight check before doing anything IP-based.

AI-agent traffic is high-frequency and predictable, so it tends to trip brute-force rate limits fast. Whitelist their known IP ranges or use Application Passwords with a dedicated user for the agent. See MCP / OAuth Clients Getting Locked Out for the pattern.

Marginally. The firewall runs on every request at plugins_loaded priority 20 (before WordPress loads most of core), but the rule check is optimized to a single regex sweep. Malware and vulnerability scans run in the background via WP-Cron, not during page requests. On typical shared hosting, GuardPress adds approximately 5–20ms to admin page loads and effectively zero to frontend visitors.

No. GuardPress is fully compatible with Cloudflare, ForgeCache, WP Rocket, server-level FastCGI cache, LiteSpeed, and other cache layers. PHP sessions are scoped to wp-login.php only, so the rest of your site caches normally. If you were previously on an older GuardPress version that predates this scoping, purge your cache once after updating so any old no-store responses stop being served.

We don’t recommend it. Two firewalls fighting over the same request, two CAPTCHAs stacked on the same login form, and two file-integrity scans rotating the same cron lock cause real conflicts that make both plugins behave worse than either would alone. Pick one and deactivate the others.

If you’re switching to GuardPress from another security plugin, deactivate the old one first, then activate GuardPress and walk through GuardPress → Settings to enable equivalent protections. Follow Quick Start for the recommended enable order.

Depends on the plan. Each plan has a fixed site-activation limit shown on the pricing page. Localhost, .local, .test, and .localhost domains are excluded from the site count when WP_DEBUG is true and the GUARDPRESS_DEV_MODE constant is defined as true in wp-config.php, so your local development site doesn’t burn a real slot. See the Installation and License Activation article for the full flow.