Here is an uncomfortable fact about almost every WordPress firewall plugin on the market: by the time it blocks an attack, the attack has already reached your server.
That sounds like a contradiction, so walk through what happens. A malicious request arrives. Your web server accepts the connection, PHP boots, WordPress starts loading, and somewhere in that process the firewall plugin wakes up, inspects the request, and returns a block page. The attacker got denied, sure. But your server did real work to deny them: a PHP process, a database connection, memory, CPU. Multiply that by the thousands of requests a botnet sends during a scanning run, and “blocked” traffic can still slow your site to a crawl or push a shared hosting account past its resource limits. The block page is a technicality at that point. The attack succeeded at what most automated attacks actually do, which is burn your resources while looking for a way in.
This is not a flaw in any particular plugin. It is a limitation of where plugins live. A firewall can only stop traffic at the layer where it runs, and a plugin runs inside WordPress, which is the last stop on the request’s journey, not the first.
Why bad bot traffic makes this urgent
The number of requests making that journey is the part most site owners underestimate. A small WordPress site with modest human traffic still takes thousands of automated hits a day: probes for .env files and wp-config.php backups, login and XML-RPC hammering, version fingerprinting, and scanners walking the plugin directory looking for anything with a known CVE. Cloudflare’s own measurements put automated traffic at roughly half of everything on the web, much of it bad bots, and WordPress, powering over 40% of the web, is the target every scanner is tuned for. These bots do not care whether your site is big enough to be “worth” attacking. They scan everything, every day, because scanning is free for them.
The AI era turned that dial further in both directions. On the hostile side, AI-assisted tooling has collapsed the time between a vulnerability being disclosed and botnets mass-scanning for it, from weeks down to hours, so the background noise against every site keeps rising. On the “neutral” side, a new generation of AI crawlers now harvests content for model training at a pace that rivals attack traffic, crawling thousands of pages without the restraint search engines learned to show. A training scraper is not trying to hack you, but your server cannot tell the difference in cost: it burns the same PHP and database work either way. SiteFort’s bot and AI crawler controls exist for exactly this traffic, and it is a separate problem from the malicious kind.
Here is what that means in practice: bad bot traffic is no longer just a security concern, it is a line item. Every automated request you absorb competes with real visitors for CPU and memory. On shared hosting it triggers resource throttling that makes your site slower for humans, which feeds into Core Web Vitals and rankings. On metered or cloud hosting it shows up directly on the bill, and it is often the invisible reason a host pushes you toward a more expensive plan. The firewall’s job has quietly changed: it is no longer only about stopping the rare targeted hack, it is about shedding a constant flood of junk traffic as cheaply as possible. And how cheaply you can shed it depends entirely on where the blocking happens.
The three places a WordPress firewall can run
It helps to picture the path a request takes: attacker, then Cloudflare (if you use it), then your web server, then PHP and WordPress.
A plugin-level firewall runs at the end of that chain. It has the most context, because it can see WordPress users, login attempts, and REST API calls, but it acts last and every block costs server resources.
A server-level firewall intercepts requests before WordPress loads. SiteFort’s Server-Level WAF works this way, and it is a meaningful upgrade: blocked requests never boot WordPress, so the per-request cost drops sharply. But the connection still lands on your machine.
An edge firewall blocks the request before it ever leaves Cloudflare’s network. The attacker connects to a Cloudflare data center near them, gets refused there, and your server never sees the packet. Zero PHP, zero database, zero load. For high-volume attacks, this is the only layer where blocking is actually free.
So the answer seems obvious: block everything at the edge. Except there is a catch, and it is the reason edge firewalls alone have never been enough for WordPress.
Why Cloudflare alone doesn’t know enough
Cloudflare is very good at what it can see from the outside: known bad IPs, malformed requests, volumetric floods. What it cannot see is what is happening inside WordPress. It does not know that an IP just failed five login attempts, or that a “normal looking” GET request is the fourth probe for wp-config.php backups in ten minutes, or that a user agent claiming to be Googlebot just failed DNS verification. That intelligence only exists at the WordPress layer, where the application context lives.
This is why most site owners who put Cloudflare in front of WordPress end up with two disconnected systems: an edge firewall that lacks WordPress context, and a plugin firewall that has the context but acts too late. You can bridge them by hand, copying IPs from your plugin’s block list into Cloudflare’s dashboard, but nobody sustains that. Attack IPs rotate faster than any human updates rules.
Closing the gap: detection in WordPress, enforcement at the edge
The fix is to connect the two layers so they act as one firewall: let WordPress do the detecting, because that is where the context is, and let Cloudflare do the blocking, because that is where blocking costs nothing.
This is exactly what we built Cloudflare Sync in SiteFort to do, and as far as we know, no other WordPress security plugin does it. When SiteFort’s firewall identifies an attacker, whether through scanner detection, failed login lockouts, rate limiting, or a manual block rule, the block does not stay trapped inside WordPress. Supported rules push automatically to your Cloudflare zone, where they are enforced across Cloudflare’s 300+ global locations. The attacker gets stopped at the data center nearest to them, often on another continent, before your server is involved at all.
Country blocking works the same way. Instead of checking a visitor’s country after they reach your site, country rules synced to Cloudflare are enforced at the edge, so geographic policy costs your server nothing.
The part that matters most under real attack conditions is Automatic Edge Blocks. When an IP keeps hammering your site and repeatedly triggers SiteFort’s firewall, SiteFort escalates it to a temporary Cloudflare edge block on its own. Out of the box, an IP that triggers three firewall blocks within ten minutes is blocked at the edge for the next two hours, and every number in that sentence is adjustable. Escalated blocks expire automatically and are managed separately from your manual rules, so a botnet node that attacks you today gets pushed off your server within minutes, without leaving stale rules behind forever.
The net effect is a feedback loop no standalone firewall has. WordPress-level detection, which knows what an attack looks like, continuously feeds Cloudflare-level enforcement, which can absorb any volume. Attack number one reaches your server and gets blocked there. Attacks two through ten thousand from that source never arrive.
Setting up Cloudflare Sync
You need a domain routed through Cloudflare, on any plan including the free one, and SiteFort installed.
From there:
- Create a Cloudflare API token and connect it under SiteFort > Settings > Integrations. The Cloudflare connection guide walks through the token permissions. Once connected, SiteFort verifies your zone and handles the Cloudflare-specific details, like reading the real visitor IP behind the proxy, automatically.
- Review the Cloudflare Sync tab under Firewall. Rule changes push to the edge as they happen, so there is nothing to switch on, and your origin firewall rules stay active as a second layer. Check that the Automatic Edge Blocks thresholds fit your site; the defaults are sensible, and SiteFort caps edge blocks to your Cloudflare plan limit. A Push now button is there if you ever want to force an immediate sync.
After that, watch the Traffic Log for the first week. You will see the pattern shift: an attacking IP appears in the log a handful of times at the WordPress layer, then goes quiet, not because the attacker gave up but because their traffic stopped reaching you.
Where this leaves your security stack
None of this replaces the basics. You still need updated core, plugins, and themes, hardened logins, and malware scanning, because a firewall does not fix a vulnerability, it only controls who gets close enough to exploit one. But if you already run WordPress behind Cloudflare, leaving detection and enforcement disconnected means paying server resources for every attack your firewall “blocks.”
Connected, the two layers become what a firewall should have been all along: your site decides who is hostile, and the attacker is turned away before they ever reach your server.
Cloudflare Sync is included in SiteFort Free. If Cloudflare already sits in front of your site, connecting the two takes about 2 minutes.
