This is the Guidance section, which acts as the “Manual” within the plugin. It explains the logic behind each rule group so you can understand the operational impact of your security settings.

Allow Good Bots
The Allow Good Bots rule is arguably the most important part of your firewall setup.
Purpose
This rule ensures that legitimate bots such as search engine crawlers and monitoring services can access your site without restrictions or challenges by using Cloudflare’s Skip action. It must be Rule #1 so verified bots are whitelisted before any blocking or challenge rules run.

Key Benefits
- Ensures your site is properly indexed by search engines (Google, Bing, etc.)
- Allows monitoring tools to verify your site’s uptime and performance
- Prevents disruptions to services that rely on API access
- Improves SEO by ensuring search engines can crawl your content efficiently
- Enables social media platforms to generate preview cards when your site is shared
Important Considerations
- The Skip action is automatically configured via API when you deploy; no manual Cloudflare dashboard setup is needed.
- Be selective about which bot categories you allow if you have bandwidth or performance concerns.
- If a bot you need is being blocked by other rules, enable it here to ensure it has unrestricted access.
Recommendation
Select only the Cloudflare verified bot categories you know you need. Always enable logging for proper testing and auditing.
Block Aggressive Crawlers & WP Paths
While “Good Bots” are welcomed, the internet is full of “Bad Bots” that can slow down your site or look for security holes. This rule acts as your site’s security guard, specifically watching for aggressive behavior and protecting your most sensitive “private rooms.”
Purpose
This rule targets bots that consume excessive resources or crawl your site too aggressively and protects sensitive WordPress paths from unauthorized access. It uses User-Agent matching and URI pattern detection to identify bad actors.

Key Benefits
- Reduces server load from aggressive crawlers that do not respect crawl limits
- Prevents bandwidth consumption from unauthorized SEO tools
- Blocks common penetration testing tools (Nikto, SQLMap, Masscan, Nmap)
- Protects sensitive WordPress paths (xmlrpc, wp-config, wp-json, install.php)
- Hides WordPress version info by blocking readme.html and license.txt
- Prevents XML-RPC amplification attacks and brute force attempts
Important Considerations
- If you use SEO tools like Ahrefs or SEMrush, allow them in Rule #1 before blocking here.
- If you use the WordPress REST API (wp-json), do not enable that path protection.
- Some WordPress plugins or mobile apps may require XML-RPC access.
- Monitor your event logs after implementing this rule because some legitimate bots may be caught.
Recommendation
Start with blocking generic unverified crawlers and bots first. For WordPress paths, enable xmlrpc and wlwmanifest blocking by default, and only enable wp-json blocking if you don’t use the REST API.
Block or Challenge Web Hosts / TOR
Most regular visitors access your website through a standard Internet Service Provider (ISP) like Comcast or local mobile networks. However, malicious scripts and automated “attack bots” usually run from Web Hosting Providers (data centers) or the anonymous TOR network. This rule allows you to filter this high-risk traffic.
Purpose
This rule manages traffic from common web hosting providers and TOR exit nodes, which are frequently sources of automated attacks and malicious scripts. You can choose to block them entirely or use Managed Challenge to allow legitimate visitors through.

Key Benefits
- Blocks or challenges automated attacks from web hosting providers where malicious scripts often run
- Prevents TOR-based attacks while optionally allowing legitimate TOR users
- Reduces fraudulent transactions and spam registrations
- Helps prevent credential stuffing attacks
- Flexible: use Block for maximum security or Managed Challenge when legitimate proxy users matter
Important Considerations
- Some legitimate visitors may use TOR for privacy reasons
- Corporate traffic sometimes routes through cloud providers or proxies
- External services you use may be hosted on blocked ASNs; allowlist them in Rule #1 if needed.
- Monitor WAF events after deployment to check for false positives.
Recommendation
Start with Block action for maximum security. If you see false positives or need to allow legitimate proxy connections, switch to Managed Challenge. It still blocks automated attacks while letting real humans through after a quick challenge.
Challenge Large Providers / Country
Even if a bot isn’t “aggressive,” it might still be running on a professional server. This rule allows you to put a “security checkpoint” in front of traffic coming from the world’s biggest cloud companies and from countries outside your target market.
Purpose
This rule adds security by challenging traffic from cloud provider IP ranges (AWS, Google Cloud, Azure) where many automated attacks originate, and optionally challenges visitors from outside your target country audience.

Key Benefits
- Reduces automated attacks that often originate from cloud providers
- Helps prevent credential stuffing and brute force attempts
- Can limit spam and bot registrations from contact forms
- Adds geographic protection if your site only serves specific countries
- Uses Managed Challenge so legitimate visitors can usually pass through transparently
Important Considerations
- If you target a multi-national audience, leave the country option unchecked.
- Corporate traffic and remote workers sometimes route through cloud providers.
- API integrations with third-party services might be affected if they use these ASNs.
- The country picker becomes available below the rule card when the country option is enabled.
Recommendation
Managed Challenge is barely invasive to humans but very effective against bots. Check all cloud provider options to start. Only enable the country restriction if your site serves a specific geographic audience.
Challenge VPN Connections & wp-login
The WordPress login page (wp-login.php) is the most targeted “door” on your website. This rule adds a sophisticated security checkpoint to that door, specifically focusing on traffic coming from VPN providers, which attackers often use to hide their true location.
Purpose
This rule protects WordPress login paths from unauthorized access and adds security against connections coming through VPN providers, which are frequently used for manual and automated attacks against WordPress sites.

Key Benefits
- Prevents most brute force attacks and credential stuffing on wp-login.php
- Blocks automated attacks targeting WordPress vulnerabilities
- Adds security against attacks originating from VPN services
- The Managed Challenge is transparent to real humans but stops automated scripts
Important Considerations
- Legitimate visitors may use VPNs, so monitor the Challenge Solve Rate after deployment.
- For higher security, consider using a Cloudflare Configuration Rule to set “I’m Under Attack” mode on wp-login.php.
- For the highest security, use Cloudflare Access to protect wp-login.php and wp-admin instead.
Recommendation
Enable wp-login.php protection and select all VPN providers. This is one of the most impactful rules for WordPress security and won’t noticeably disrupt legitimate users.