How to Configure a WordPress Firewall Without Blocking Real Visitors
Control abusive bots, repeated requests, scanners, and known bad traffic without blocking customers, APIs, search crawlers, or your own team.
Choose the Firewall Control That Matches the Problem
A firewall works best when each rule has a clear reason to exist. Do not start by blocking as much traffic as possible. Start with what the traffic is doing, then use the narrowest control that solves it.
| What you are seeing | Good first control |
|---|---|
| Repeated login attempts | Login rate limiting |
Requests probing .env, backups, shells, or vulnerable paths | Scanner and probe detection |
| One IP or network repeatedly abusing the site | Temporary IP or CIDR block |
| Aggressive scraper or crawler | Bot or crawler rule |
| Legitimate service being blocked | Narrow allow rule after verification |
| High-volume abusive traffic reaching WordPress | Edge or CDN filtering |
| Sustained abuse from a region you do not serve | Country block, if the false-positive risk is acceptable |
Get the Real Visitor IP Right First
IP-based firewall decisions only work if WordPress sees the real visitor address.
On a server directly exposed to visitors, this is usually straightforward. Behind Cloudflare, another CDN, a reverse proxy, or a load balancer, WordPress may see the proxy address instead unless the environment is configured to use a trusted forwarding header.
If this is wrong, the firewall can rate-limit, block, allow, or geolocate the wrong address.
| Environment | What to check |
|---|---|
| Direct hosting | The firewall should normally see the connecting visitor IP directly. |
| Cloudflare | Confirm the application uses Cloudflare's trusted visitor-IP information rather than the proxy address. |
| Other CDN or reverse proxy | Verify which forwarding header is authoritative and which proxies are trusted to set it. |
Do not blindly trust a visitor-supplied forwarding header such as X-Forwarded-For. Proxy headers should only be trusted when they come through infrastructure you control or explicitly trust.
Verify it before tightening anything
Make a controlled request from a network where you know the public IP and compare that address with what the firewall records.
If they do not match, stop there and fix IP detection first.
Rate-Limit Abusive Behavior, Not Normal Browsing
Rate limiting is useful when one visitor or automated client repeats an action faster than a real user normally would.
Good candidates include:
- repeated login attempts
- XML-RPC authentication
- high-frequency search requests
- repeated form submissions
- abusive REST or API calls
- repeated checkout or payment attempts
- large numbers of 404 or probe requests
Avoid choosing a global request limit simply because another website uses that number. A customer placing an order can generate several legitimate requests in seconds, while a brochure site may generate very little dynamic traffic at all.
Dynamic sites need more room
Be especially careful with:
- WooCommerce cart, checkout, account, and payment flows
- membership dashboards
- LMS course players
- live search and product filters
- mobile applications
- headless frontends and API clients
Start above normal observed traffic, then tighten only when logs show that abusive requests are still getting through.
Verify it
Browse normally, log in, submit forms, search the site, and test any checkout or API flow before deliberately triggering a controlled rate-limit event.
The blocked event should match the behavior you intended to limit.
Block Bots and Scanners Based on Behavior
Not all automated traffic is malicious. Search crawlers, uptime monitors, social preview services, API clients, security scanners, and scrapers can all look automated while serving very different purposes.
The useful distinction is what the client is doing.
| Traffic | How to treat it |
|---|---|
| Requests probing known vulnerable paths | Block or challenge automatically |
| Aggressive scraper consuming resources | Rate-limit or block narrowly |
| Known search crawler | Allow if it is legitimate and wanted |
| Monitoring or integration service | Allow only when verified and required |
| Unknown automation | Judge by request pattern and impact before trusting it |
A User-Agent is a claim, not proof of identity. A request calling itself Googlebot, Bingbot, or a monitoring service should not automatically receive trusted access simply because of the name it sends.
Add Manual Traffic Rules Only When You Have Evidence
Manual rules are useful when the logs give you a concrete reason to create one. They are not a general-purpose way to make a firewall look stricter.
- Temporary block: use it for a source actively abusing the site. This is usually better than a permanent rule when the behavior may move to another IP.
- Longer or permanent block: use it only when there is a durable reason to distrust the source itself, not simply because one burst of bad traffic came from that address.
- Allow rule: use it only when a verified service genuinely needs to bypass protection that would otherwise block it.
Bot or User-Agent rules
Keep crawler patterns as specific as possible. Avoid broad patterns such as bot, crawler, or Mozilla when the rule grants trusted access or bypasses other firewall checks.
Before creating a manual rule, check the source IP, request path, method, User-Agent, frequency, and the firewall reason already recorded in the logs.
Be Careful With Trusted Traffic
An allow rule deserves more scrutiny than a block rule because it removes protection instead of adding it.
Reasonable allowlist candidates
- a static office IP you control
- a fixed agency or developer VPN
- a verified monitoring service that requires direct access
- a known integration endpoint that cannot otherwise operate correctly
Avoid broad trust
- dynamic home IPs
- shared commercial VPN exit ranges
- large CIDR ranges added for convenience
- whole hosting networks
- temporary exceptions nobody plans to remove
If your public IP changes regularly, do not permanently trust it simply because it is yours today. That address may later belong to someone else.
Use Country Blocking Only When Geography Is Part of the Problem
Country blocking is not a general substitute for firewall protection. Attack traffic is distributed across hosting providers, compromised systems, VPNs, and many different countries.
Blocking a country can make sense when:
- your business genuinely does not serve that region
- logs show sustained abusive traffic from there
- the volume is high enough to justify the restriction
- the risk of blocking an occasional legitimate visitor is acceptable
Be much more cautious when customers travel, staff work remotely, the site sells internationally, or third-party services may connect from infrastructure around the world.
Allow-only rules are a special case
Allow-only country policies are better suited to private portals, internal tools, or genuinely local services with a narrow and predictable audience.
They are usually a poor fit for public ecommerce, membership, publishing, or globally accessible sites.
Move High-Volume Blocking to the Edge
A WordPress firewall and an edge firewall solve different parts of the problem.
| Layer | What it is good at |
|---|---|
| WordPress or application firewall | Understands WordPress routes, application behavior, login activity, and other site-specific context |
| CDN or edge firewall | Stops supported abusive traffic before it reaches PHP, WordPress, or the origin server |
If the problem is a large volume of requests consuming origin resources, blocking earlier in the request path can matter as much as the rule itself.
If your site uses Cloudflare, see our WordPress firewall and Cloudflare guide for the architecture and tradeoffs.
Before You Tighten the Firewall
Test the traffic your site genuinely depends on:
- confirm the firewall records your real visitor IP
- browse important pages while logged out
- log in as an administrator
- submit public forms
- test search, filters, and other dynamic frontend features
- test WooCommerce cart, checkout, account, and payment flows if applicable
- test membership or LMS activity
- test REST, mobile, headless, webhook, and other API clients
- confirm search crawlers and social previews still work where required
- trigger one controlled firewall or rate-limit event and verify the log shows the correct source and reason
A good firewall blocks behavior you can explain. If legitimate traffic is being denied and you cannot explain why, the policy is too broad or the underlying signal is wrong.