- A security plugin runs inside WordPress, so it only acts after a request has already reached PHP and loaded your site.
- A firewall that sits in front of your site blocks bad traffic before it uses any of your server's resources.
- Unpatched plugins are the leading real-world WordPress breach cause: update discipline beats any scanner.
- Restore-tested backups turn a breach into an inconvenience: you roll back instead of rebuilding.
- Site isolation stops one hacked site becoming ten, because there is no shared PHP pool or shared database.
Why can't a WordPress security plugin stop an attack on its own?
Secure a WordPress site with layers, not one plugin. Put a firewall in front of the site, give every account the least access it needs, keep WordPress, plugins and PHP patched, take restore-tested backups, and run each site in isolation. A security plugin helps, but it acts last, after a request already reached your site.
Plugins like Wordfence and Sucuri are genuinely useful. They add login protection, malware scanning and rule-based filtering. The limitation is where they run: inside WordPress. By the time the plugin evaluates a request, your server has already accepted it, started PHP, and loaded WordPress. The work is done before the decision is made.
The plugin decides last, not first
For a plugin to block a request, the request must first reach your site and trigger PHP. Under a flood of malicious requests, that per-request work alone can exhaust your site's PHP processes and take the site down, even when every single request is eventually blocked.
Why can't a plugin inside WordPress block traffic that already reached PHP?
Because a plugin is code that only runs once WordPress is already running. Follow one request through the stack and the order is fixed: your server accepts the connection, hands it to PHP, PHP starts up and boots WordPress, WordPress loads its plugins, and only then does your security plugin get a turn. Every step before it has already spent CPU, memory and a slice of your site's capacity.
This is why a plugin cannot be your outer wall. It lives in the last room of the house. A request designed to be expensive (a heavy search, an XML-RPC probe, a login brute-force) has already made your server pay before the plugin says no. Blocking the request at that point saves you from the exploit, but not from the load. The only way to stop traffic cheaply is to judge it before PHP ever starts.
| Stage of the request | Resource already spent | Can a plugin act here? |
|---|---|---|
| Your server accepts the connection | A connection slot | No |
| The request is routed to PHP | Server capacity | No |
| PHP starts up | A PHP process plus memory | No |
| WordPress boots and loads plugins | Full WordPress bootstrap | No |
| Security plugin evaluates request | All of the above | Yes, but the cost is already paid |
A security plugin runs at the last stage, after the expensive work is already done.
What does a firewall in front of WordPress actually stop?
A firewall that sits in front of your site judges traffic before it reaches your server at all, so a blocked request costs you nothing. It stops automated exploit scans probing for known plugin holes, credential-stuffing bots hammering the login form, and traffic floods aimed at exhausting your site. Your site never spends any capacity on it.
On G7Cloud, every site sits behind ScaleShield, a firewall plus bot protection that filters malicious and automated traffic before it reaches your container. It is on every plan, including Free, and is never sold as an add-on. Because it runs in front, it also absorbs sustained attacks: the traffic is dropped before it can touch the machines that serve your site. Our WordPress security approach starts here, with the outer wall, and only then adds the layers inside.
Front-line filtering and DDoS
A firewall in front of your site is also your first answer to a sustained flood. It drops attack traffic before it reaches PHP, so a burst that would overwhelm plugin-based filtering never lands. For the mechanics of soaking up a flood, see our guide to DDoS protection for WordPress.
Traffic dropped in front of your site never starts PHP, so a blocked request costs you nothing.
How does least-privilege access reduce your attack surface?
Least privilege means every account, file and process gets only the access it needs, and nothing more. Most WordPress compromises spread through over-broad access: a stolen editor login that can install plugins, a writable file that should be read-only, an admin account shared by three people. Tightening access does not stop the first mistake, but it limits how far that mistake can travel.
The practical controls are simple and each one shrinks the attack surface. Give every person their own account, never a shared one, so a leaked password maps to a single user you can disable. Turn on two-factor authentication for admin logins. Scope roles: an editor should not have plugin-install rights. Use SFTP, not plain FTP, so credentials and files are never sent in the clear. Set file permissions so WordPress core files cannot be written by the software serving your site. And disable the in-dashboard file editor, which turns a single stolen admin session into direct code execution.
Add define('DISALLOW_FILE_EDIT', true); to wp-config.php. It removes the Appearance and Plugins code editors from wp-admin, so a hijacked admin session can no longer paste PHP straight into your theme.
On G7Cloud these controls come built in. Every account supports two-factor authentication, team members get scoped roles (owner, admin, developer, editor, viewer), changes are audit-logged, and access to files is over SFTP, not FTP. The developer tools give your team the access they need without handing everyone the keys to everything.
Why does keeping WordPress, plugins and PHP updated matter more than any scanner?
Because unpatched plugins are the single leading cause of real-world WordPress breaches. Most compromises are not clever, targeted hacks. They are automated bots scanning millions of sites for a known hole in an out-of-date plugin, then walking straight through it. A scanner tells you after the fact that you were breached. An update closes the door the attacker was going to use.
The update gap is the breach window
When a plugin vulnerability is disclosed, exploit bots start scanning within hours. Every day you delay the update is a day your site is in a race against automation. Update discipline is not glamorous, but it closes far more real breaches than any amount of scanning.
Good update discipline has three parts. Keep WordPress core, every plugin and every theme current, and remove any plugin you no longer use, because a deactivated plugin can still be exploited. Keep PHP itself on a supported version: old PHP stops getting security fixes and drags performance down with it. And test updates before they hit your live site. This is where a preview environment earns its place: on G7Cloud you can push changes to a PR preview environment and confirm an update did not break anything before it reaches real visitors.
How do restore-tested backups turn a breach into an inconvenience?
Security is not only about keeping attackers out. It is also about recovering fast when something gets through, because eventually something will. A good backup turns a breach from a rebuild into a rollback: you restore a clean copy from before the compromise and you are trading minutes, not days. The catch is that a backup you have never restored is a guess, not a safety net.
On G7Cloud, backups run daily, weekly and monthly, and every backup is restore-tested overnight. That means a real restore into a sandbox, not a checksum: the system actually rebuilds the site from the backup to prove the backup works. When you need it, you can do a full restore, or a single-file restore to recover just one changed file, or a single-database restore to roll back only your data. Read how we structure it on the backups page, and for planning your own cadence see our WordPress backup strategy guide.
After a suspected compromise, do not simply delete the bad file and move on. Restore from a known-clean backup taken before the breach, then apply every pending update. Cleaning in place often misses a second backdoor the attacker left behind.
Why does site isolation stop one hacked site becoming ten?
Because on isolated hosting there is no shared floor for an attacker to walk across. On traditional shared hosting, hundreds of sites share one PHP environment and one file system, so a single compromised site can read or infect its neighbours. One breach quietly becomes ten. Isolation removes that path entirely: each site is walled off from every other.
On G7Cloud, every site runs in its own dedicated container with its own database. No shared PHP pool, no shared database tables, no cross-site file access. A vulnerability in a stranger's site cannot become your incident, because there is no shared server in any meaningful sense. This is the layer no plugin can give you: a plugin protects the inside of one site, while only the platform can guarantee that one site's problem stays that site's problem.
"A plugin protects one site from the inside. Only isolation guarantees a hacked neighbour never becomes your problem."
What is a sensible layered WordPress security checklist?
A sound security posture stacks controls so that each one catches what the others miss. No single layer is enough, and the point of the stack is that a failure in one is caught by the next. The table below maps each control to where it acts and what it can and cannot stop, which is the clearest way to see why a plugin alone leaves gaps.
| Control | Where it acts | Stops | Cannot stop |
|---|---|---|---|
| Plugin firewall | Inside PHP, after boot | Some known patterns once they arrive | Load from the request itself; traffic floods |
| Firewall in front (ScaleShield) | In front of your site | Exploit scans, bad bots, floods, before PHP | A valid login with a stolen password |
| Least privilege plus 2FA | Accounts and files | A stolen login spreading; unwanted code edits | The initial credential theft |
| Updates | WordPress, plugins, PHP | Known vulnerabilities being exploited | A brand-new, undisclosed flaw |
| Isolation | Platform | One hacked site infecting others | The first site being compromised |
| Restore-tested backups | Recovery | A breach becoming permanent damage | The breach happening in the first place |
Each control acts at a different point. Security is the whole stack, not any one row.
The short version
Put a firewall in front, give every account the least access it needs with 2FA, keep everything patched, run each site isolated, and take restore-tested backups. A security plugin then adds a useful inner layer, rather than being asked to do the whole job on its own. To see how these layers fit together on our platform, read our WordPress security overview.
Common WordPress security questions
Short, direct answers to the questions people ask most when they move past thinking a single plugin is enough.
Frequently asked questions
Do I still need a WordPress security plugin if my host has a firewall?
A plugin still adds a useful inner layer, such as login hardening and malware scanning inside the site. It just should not be your only defence. A firewall in front of your site stops most attack traffic before it reaches PHP, which a plugin cannot do, so the two work best together rather than one replacing the other.
Why can a plugin firewall not stop a DDoS attack?
A plugin firewall runs inside WordPress, so every request in a flood still starts PHP and loads WordPress before the plugin can block it. Under a large flood, that per-request work exhausts your site even though each request is refused. Stopping a flood needs a firewall in front of the site that drops traffic before it reaches your server.
What is the single most important thing I can do to secure WordPress?
Keep WordPress core, plugins, themes and PHP updated, and remove anything you no longer use. Unpatched plugins are the leading real-world breach cause, and most attacks are automated bots hunting for known holes. Update discipline closes more real breaches than any scanner or plugin setting.
How do backups help with security if they do not stop attacks?
Security includes recovery, alongside prevention. A clean backup lets you roll a breached site back to before the compromise in minutes instead of rebuilding. On G7Cloud backups run daily, weekly and monthly and are restore-tested nightly by rebuilding into a sandbox, so the backup is proven to work before you ever need it.
Is shared hosting less secure than isolated hosting?
It carries more risk from your neighbours. On shared hosting many sites use one PHP environment and file system, so a single compromised site can spread to others. With isolation, each site runs in its own container with its own database, so one hacked site cannot become ten.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →