Do you need edge protection if you already have a security plugin?

What is edge protection, and where does it actually sit?

Edge protection is filtering that happens on a network of servers sitting in front of your web server, rather than on the web server itself. In the reverse-proxy model that most of the modern web runs on, a visitor does not connect straight to your hosting; they connect to whichever edge server is nearest to them, and that server decides what to forward to your origin. Cloudflare defines a reverse proxy as a network of servers that sits in front of web servers and either forwards requests to those web servers or handles requests on their behalf. That second clause is the whole point: a request handled at the edge never becomes your server’s problem.

The distance matters more than it sounds. Detection at the edge happens on the same machines that are already terminating the connection, in every data centre, close to wherever the traffic originated. Cloudflare’s DDoS documentation notes that a detection daemon runs in every single server in every one of its data centres, and can detect and mitigate attacks autonomously without requiring centralised consensus. Filtering that is spread across hundreds of locations can absorb something that no single origin server could survive, simply because the work is divided before it ever converges on you.

RankShield’s edge protection is a second line running across that global network, in front of whatever you already have. It does not replace your hosting, your plugin, or your firewall. It changes what reaches them. And it deliberately starts in observation mode on a new site, watching and classifying traffic before it filters anything, because the fastest way to break a website is to start denying requests on day one against a traffic pattern nobody has looked at yet.

What does a security plugin protect, and where does it stop?

A security plugin is not the weak link in this story, and it is worth being precise about that before explaining its limit. A plugin runs inside your application, which means it knows things the edge cannot: which user is logged in, what role they hold, which form they submitted, whether this request is trying to touch a vulnerable endpoint in a specific plugin you happen to have installed. That context is exactly what you need to catch an attack aimed at your site’s logic rather than its bandwidth, and no amount of network-layer filtering substitutes for it.

The scale of the work plugins do is genuinely enormous. Wordfence reported that in a single year it blocked and logged over 54 billion malicious requests and blocked over 55 billion password attacks, originating from roughly 136 million distinct IP addresses. That is not a rounding error in someone’s traffic; it is a continuous, industrial-scale assault that a plugin is absorbing on behalf of ordinary websites. The reason plugins matter so much is also visible in where the vulnerabilities actually live: Patchstack found that 91% of new WordPress vulnerabilities disclosed in 2025 were in plugins, against 9% in themes, across 11,334 new vulnerabilities, a 42% year-on-year increase. That finding is not one vendor’s quirk, either: Wordfence independently reported that plugins accounted for 96% of all vulnerabilities disclosed in 2024, with themes making up the remaining 4%. Two large datasets, gathered separately, point at the same place.

So the limit is not competence, it is position. Your plugin is code running on your server, which means it cannot evaluate a request until your server has already accepted the connection, terminated TLS, started PHP, loaded WordPress, and handed the request to the plugin to judge. By the time the plugin says no, every one of those steps has already happened. The plugin is doing its job perfectly, at the only place it is able to stand.

Why does a request your plugin blocks still cost you?

Because a block at the origin is a verdict, not a shield. Picture the sequence for a single hostile request that your plugin correctly denies. Your server accepts the TCP connection. It performs a TLS handshake, which is real cryptographic work. It hands the request to your web server, which starts a PHP worker. PHP loads WordPress, which loads your plugins, one of which is the security plugin. That plugin inspects the request, recognises it as hostile, and returns a denial. The attack failed, which is the outcome you wanted. But you paid for a connection, a handshake, a PHP worker, and a WordPress bootstrap in order to say no. Multiply that by the volume in the Wordfence figures above and the cost stops being theoretical.

This is the part most people underestimate, because it is invisible until it is not: it shows up as a slow site during an attack, a hosting plan that keeps needing an upgrade, PHP workers exhausted so real customers get a spinner, or a bill that grows without your traffic growing. The traffic that causes it is not a fringe minority any more. The 2026 Thales Bad Bot Report puts automated traffic at 53% of all web traffic, with bad bots alone at 40%, up from 51% and 37% respectively the year before. The report also found AI-driven bot attacks surged 12.5x, with daily blocked AI-related incidents rising from about 2 million to 25 million, and 17.2 trillion malicious bot requests blocked across the year. Most of what asks your server for something is no longer a person.

The clearest public evidence that bots consume more than their share comes from an organisation that publishes its own numbers. The Wikimedia Foundation reported that at least 65% of its most resource-expensive traffic came from bots, even though bots accounted for only about 35% of pageviews. The same analysis noted that bandwidth used for downloading multimedia content grew 50% since January 2024, a rise driven by automated demand rather than by more readers. Read those two numbers together: the automated share of the expensive work was nearly double the automated share of the visible work. Bots are not just numerous, they are disproportionately costly, because they ignore the caching and browsing patterns that make human traffic cheap to serve.

None of that is an argument against your plugin. It is an argument about arithmetic. If most requests are automated, and automated requests are disproportionately expensive, then the layer that decides whether a request reaches your server at all is doing more for your hosting bill and your uptime than the layer that decides what to do with it once it has arrived. The plugin still has to be there for everything that legitimately gets through. It simply should not be your first and only filter.

Which attacks can only be absorbed before they reach your origin?

There is a category of attack where the origin-versus-edge question is not a matter of efficiency but of possibility, because the attack does not care what your plugin thinks. A volumetric denial-of-service attack does not try to exploit your application; it tries to exhaust the pipe and the machine in front of it. Your PHP never runs. Your plugin is never consulted. The connection saturates before any of your code has an opinion.

The scale here is genuinely difficult to hold in your head. Cloudflare reported mitigating 47.1 million DDoS attacks across 2025, an average of 5,376 every hour and more than double the 2024 figure, with network-layer attacks alone rising from 11.4 million to 34.4 million. The largest single attack it recorded peaked at 31.4 Tbps and lasted 35 seconds. No shared hosting plan, no VPS, and no plugin has a meaningful response to 31.4 Tbps. The only thing that answers an attack like that is a network large enough to absorb it in many places at once, which is precisely the property the edge has and your origin does not.

Credential attacks sit in a middle ground that is worth naming honestly. A plugin can and does lock out repeated failed logins, and that protection is real. But every attempt still had to arrive, boot your stack, and be evaluated, so a sustained credential-stuffing run against your login endpoint is a resource event as much as a security one. The underlying pressure is well documented: the Verizon 2025 Data Breach Investigations Report found that about 88% of the breaches in its Basic Web Application Attacks pattern involved the use of stolen credentials. Filtering that traffic before it reaches the login form does not make your lockout rules redundant; it means they are being asked to run far less often.

The honest boundary: edge protection does not make a site unhackable, and it cannot fix a vulnerable plugin. If you are running code with a known vulnerability, the request that exploits it may look perfectly ordinary at the network layer, because it is ordinary at the network layer. That is exactly the request your security plugin and your update discipline exist to catch. The root causes here mostly sit outside your control (stolen credentials from someone else’s breach, a vulnerability in code you did not write, an attacker with a botnet you cannot see), which is why the sane goal is reducing exposure and containing damage rather than eliminating risk.

Do you need both, or does one replace the other?

Both, and the reason is visible in the table above: the two layers fail in opposite directions. The edge sees volume and shape but has no idea what a logged-in editor is allowed to do on your site. The plugin sees roles, endpoints, and application logic but only after your server has already paid to hear the request. Remove the plugin and you lose the context that catches exploits aimed at your specific stack, which is where 91% of WordPress vulnerabilities actually live. Remove the edge and every hostile request in a majority-automated web becomes your hosting’s problem to answer one at a time, at the volumes that produced 54 billion blocked malicious requests in a single year.

The practical way to decide is to stop asking which product is better and start asking what your origin is currently being asked to do. If your site is slow when nothing has changed, if your hosting costs drift upward while your customers do not, if your PHP workers exhaust during traffic you cannot explain, or if your analytics show a large gap between requests served and humans served, then the pressure you are feeling is arriving before your plugin ever gets a vote. That is an edge-shaped problem, and no amount of tuning inside the site will fix where the traffic is being handled.

If instead your concern is a specific vulnerability, a compromised login, or what an authenticated user can reach, that is squarely plugin territory and adding an edge layer will not address it. Most real sites have both problems at once, which is why the answer is usually both. RankShield’s edge protection is built as an add-on for exactly this reason: it sits in front of the WordPress security plugin or Shopify fraud protection app you are already running rather than asking you to replace them, and the two report into the same picture. For the deeper mechanics of network-layer filtering, see the edge WAF; for how shared signal decides what to filter in the first place, see threat prediction.

Is your site exposed at the edge?

Run this quick check to see how much of your hostile traffic your origin is currently paying to refuse. It scores where your filtering happens, not how good it is, because a perfect verdict delivered after the work is already done still leaves you holding the bill. The gaps it surfaces are the requests your hosting is answering on your behalf right now.