Why firewall rules matter
Every unwanted request you stop at Cloudflare is a request your hosting server and WordPress do not have to process. That can reduce noise, form abuse, scanning and unnecessary resource use. The key is to stop the right traffic.
Managed protection versus custom rules
Managed WAF protections are maintained by Cloudflare to identify broad classes of malicious requests. Custom rules are your own logic for situations specific to the website: suspicious paths, abusive patterns, countries you do not serve, or traffic characteristics you have actually observed.
Custom rules should complement managed protection, not become a homemade replacement for it. A giant rule copied from a forum can create more risk than a short rule whose purpose you understand.
Understand the action before the expression
Cloudflare changes product names, expression fields and plan availability over time. Always use the current dashboard/documentation when building a production expression rather than copying an old field name character for character.
Practical rule strategy
1. Protect obviously sensitive or nonexistent technical paths
Public visitors normally have no reason to request files such as environment files, source-control directories, server debug files or other known sensitive development artifacts. Blocking requests for clearly impossible paths can reduce automated probing without affecting normal navigation.
Be precise. A path that looks suspicious on one application might be legitimate on another.
2. Reduce abusive request rates
Rate limiting is useful when a source repeatedly requests the same endpoint or floods a site faster than a human visitor normally would. Login pages, XML-RPC where still enabled, search endpoints and forms can be candidates, but thresholds should reflect real site behaviour.
3. Challenge suspicious traffic before blocking it
When you are not certain, a managed challenge can be a better tuning step than an outright block. Review Security Events afterward. If legitimate visitors are being challenged, refine the condition.
4. Keep verified search bots in mind
Do not create a broad bot rule that accidentally blocks legitimate crawlers you actually want indexing the website. Where Cloudflare exposes reliable verified-bot signals for your plan and rule type, use those signals rather than guessing from a user-agent string alone.
Example: a scanner requests a file that should not exist
Imagine a bot requesting /.env, then a source-control path, then a debug file. The useful question is not “what country is this IP from?” It is “does any real visitor need these paths?” If the answer is no, a narrow path-based rule can stop the requests before WordPress ever sees them.
What about contact-form spam?
A Cloudflare firewall can reduce abusive traffic, but it does not understand every form submission. Use multiple layers: edge filtering/rate limits, Turnstile or another appropriate challenge, server-side validation, honeypot or anti-spam tooling where useful, and application-level controls. Part 7 goes deeper into that stack.
How to test a new rule
Do not deploy several new rules simultaneously and then try to guess which one broke the website. Controlled changes are easier to troubleshoot.
A real-world reason these layers matter
Firewall rules only help requests that actually pass through Cloudflare. In my separate case study, I describe finding suspicious requests that were reaching an origin directly. That is why Part 3 and Part 4 belong together: first establish the intended route, then filter the traffic on that route.
Read the real-world Cloudflare origin-bypass case study →
Common questions
Should I block entire countries?
Only when it matches a genuine business/security requirement and you understand the false-positive cost. Geographic blocking is not a substitute for identifying malicious behaviour.
Should every suspicious request be blocked?
No. The internet is noisy. A request can be odd without being dangerous. Prioritize patterns that create risk, consume resources or target paths that have no legitimate purpose.
Can firewall rules break WordPress?
Absolutely. Admin AJAX, REST endpoints, payment callbacks, form submissions and third-party services can resemble automated traffic. Test carefully.
Next: security headers in the browser
Part 5 follows a successful response back toward the visitor and looks at instructions the server can send to the browser to reduce several classes of client-side risk.