You have a WordPress site, and somewhere along the way someone told you to “install a security plugin.” Then your host mentioned that your plan already includes a firewall and malware scanning. Now you are not sure whether you need the plugin as well, whether it would clash with what the host does, or whether it is just one more thing slowing the site down.
The honest answer is that most WordPress sites benefit from one well-chosen security plugin, set up properly. But a plugin covers less than its dashboard suggests, and some of what it does may already be handled elsewhere. Here is how to work out what you actually have and what is missing.
What a security plugin actually does
Security plugins such as Wordfence, Sucuri Security and Solid Security bundle several separate jobs into one package. The mix varies, but most offer some version of these:
- Login protection. Limiting repeated failed logins, blocking addresses that keep guessing, and adding two-factor login. We have covered brute-force attacks and two-factor authentication in their own guides, so we will not repeat them here.
- File scanning. Comparing WordPress core, plugin and theme files against known clean copies, and looking for code patterns that match known malware.
- An application firewall. Some plugins include a firewall that filters requests on your server. Our guide to website firewalls explains how that compares with a cloud firewall.
- Hardening settings. Switches that turn off the built-in file editor in the dashboard, block PHP from running in the uploads folder, or hide information that helps attackers.
- Alerts and logs. Emails when an administrator logs in, when a plugin has a known vulnerability, or when files change unexpectedly.
That last item is easy to underrate. A plugin that tells you “this plugin has a published vulnerability and an update is available” is often more useful than one that blocks a thousand bots a day.
What a security plugin cannot do
This is where expectations usually go wrong. A plugin runs inside WordPress, which sets hard limits on what it can see and protect.
- It cannot protect a site that is already compromised. If an attacker got in before the plugin was installed, they may have left a backdoor the scanner does not recognise. Installing a plugin on a hacked site is not a cleanup.
- It cannot fix outdated software. It can warn you that a plugin is out of date. Someone still has to update it, and test that nothing broke.
- It cannot see problems below WordPress. A compromised hosting account, an infected neighbouring site on shared hosting, or a stolen FTP password all sit outside its reach.
- It cannot stop a real login with a real password. If a staff member’s password is reused and leaked elsewhere, the plugin sees a normal login unless two-factor is switched on for that account.
- It cannot take heavy traffic off your server. A plugin firewall still lets every request reach your hosting before it decides what to block.
- It does not replace backups. If something does go wrong, a clean copy of the site stored somewhere else is what gets you back.
A malware scan coming back clean is useful information, but it is not proof the site is clean. Scanners match known patterns. New or heavily disguised code can pass.
The overlap with your host’s security
Many hosts now include security features on their plans: a server-level firewall, malware scanning, automatic blocking of abusive addresses, and sometimes a cloud firewall in front of the site. Some managed WordPress hosts go further and do not allow certain security plugins at all, because those plugins duplicate or interfere with what the host runs.
Before installing anything, find out what your host already does. Look in your hosting control panel for sections named something like “security”, “firewall”, “malware scanner” or “Imunify”. If you cannot tell, ask your host’s support a direct question: “Do you run a web application firewall and malware scanning on my site, and do you recommend against any WordPress security plugins?”
Here is a rough way to split the work when the host already covers part of it:
| Job | Often handled by the host | Usually needs a plugin or a person |
|---|---|---|
| Filtering bad traffic | Server or cloud firewall | Only if the host has none |
| Malware scanning | Server-side scanner on many plans | WordPress-aware file comparison |
| Login limits and two-factor | Rarely | Plugin |
| Vulnerability alerts for your plugins | Sometimes | Plugin or monitoring service |
| Applying updates | Some managed hosts | Someone responsible for the site |
| Off-site backups | Host backups, often on the same provider | A separate copy you control |
If the host already has a strong firewall and scanner, you might choose a lighter plugin focused on logins and alerts, or switch off the plugin’s own firewall module to avoid doing the same job twice.
Signs your security plugin is causing problems
A security plugin is one of the heavier things you can install. When it is misconfigured, the symptoms usually look like this:
- You or a staff member get locked out after a few wrong passwords, sometimes with no clear way back in except through the hosting file manager.
- The admin area feels slow, especially while a scan is running.
- Customers report a blocked or “forbidden” page when submitting a form or checking out.
- Payments go through but orders stay pending, because the payment gateway’s callback to your site was blocked.
- Your inbox fills with alerts that nobody reads, so the one that matters gets missed.
Most of these are settings problems, not reasons to remove the plugin. Lower the scan frequency or schedule it for quiet hours, allow your payment gateway’s webhook, and turn off alert types you never act on.
Do not stack security plugins
A common mistake is installing two or three security plugins “to be safe.” They often try to manage the same files, the same login page and the same firewall rules. The result can be conflicts, lockouts and a slower site, and when something breaks it becomes hard to tell which plugin caused it.
Pick one. If you want to try a different one, deactivate and delete the old plugin first, then check that it has not left firewall rules behind in your .htaccess file or a wp-config.php setting. Some plugins add code there that keeps running after the plugin is gone.
How to decide
Work through these questions in order:
- What does your host already provide? Ask, and write the answer down.
- Is the site clean right now? If you have seen strange redirects, unknown admin users or spam pages, deal with that first. Our hacked website repair page explains what a proper cleanup involves.
- Are logins protected? If your host does not limit login attempts or offer two-factor, a plugin is the simplest way to add both.
- Will anyone read the alerts? A plugin that warns about an outdated plugin is only useful if someone acts on the email.
- Do you have off-site backups? No plugin setting makes up for not having one.
For a typical small business site on ordinary shared hosting, the sensible setup is usually one reputable security plugin with login protection, two-factor for every administrator, vulnerability alerts going to someone who will act on them, and backups stored away from the server. On a managed host with its own firewall and scanning, the plugin can be lighter, or in some cases unnecessary.
Free versions of the well-known plugins cover a lot. Paid tiers generally add things like faster firewall rule updates and support, which matter more on busier or higher-risk sites.
The part a plugin cannot do for you
Security is mostly routine: updates applied and tested, accounts reviewed, alerts read, backups checked. A plugin helps with some of that, but it does not do the routine on its own.
If you would rather have someone check what your host already covers, set up one plugin properly and keep an eye on it, that is what our website security maintenance covers. We can look at your current setup first and tell you plainly what is missing and what you can leave alone.
Next in this series: SSL Certificate Expired: What Visitors See and the Fix
