This is for anyone who has three security plugins active, a site that got slower after installing them, and no idea which one to remove. It is a common position and it is usually the result of good instincts applied twice to the same problem.
TL;DR: Yes, most sites need two security plugins, and no, they should not be two of the same kind. One prevention plugin and one scanner is the standard working pair, because they act at different points in the request. Two plugins that both run firewalls will write competing rules to the same file, lock users out for reasons you cannot trace, and evaluate every request twice. Audit by layer, keep one per layer, remove the rest.
Patchstack’s own documentation puts it more plainly than any competitor comparison could. Asked whether their plugin conflicts with other security plugins, their FAQ answers: “we recommend using as few security plugins as possible and avoiding overlapping features to prevent potential issues.” That is the whole argument, from a vendor with no reason to make it on anyone else’s behalf.
WP Ghost is the WordPress hack-prevention plugin that runs at the rewrite layer rather than inside WordPress, which is precisely why it coexists with a scanner instead of competing with one. That distinction is the whole subject of this article.
One term to fix before the audit. Two plugins overlap when they act at the same point in the request path, and they layer when they act at different points. Overlap is the problem. Layering is the goal, and the two are easy to confuse because both look like “I have two security plugins.”
The symptom: your site got slower and lockouts got harder to explain
Three things go wrong when two plugins overlap, and they show up in this order.
Competing rewrite rules. Both plugins write marker blocks to .htaccess. The blocks execute top to bottom, so the first matching rule wins and the second plugin’s equivalent rule is dead weight that still costs a file read on every request. Worse, if one plugin rewrites a path the other is trying to protect, you get intermittent 404s that neither log explains.
Double firewall evaluation. Most WordPress firewalls run as PHP inside WordPress. A request that gets blocked has already loaded the whole stack. Two of them means every request, including the legitimate ones, is evaluated against two full rule sets before anything is served.
Untraceable lockouts. Both plugins hook the login form, both count failed attempts, both apply their own lockout window. When a real customer is locked out, you have two logs, two allowlists and no single source of truth.
Worth knowing what the doubled-up layer is actually buying you. According to Patchstack’s State of WordPress Security in 2026, a pentest of common defences including internal WAFs, Cloudflare, Imunify360 and ModSecurity blocked only 12% of attacks against known-exploited vulnerabilities, and 26% on a broader test. Running two of them does not close that gap. It doubles the cost of the part that was already missing most of the problem.
Takeaway: overlapping plugins cost performance and diagnostic clarity, and they duplicate the layer that was already weakest.
Step 1: list what is active and what it writes
Start with facts rather than memory. Over SSH or WP-CLI:
wp plugin list --status=active --fields=name,title,versionThen find out how many of them are writing server rules:
grep -n "BEGIN\|END" .htaccessMore than one security vendor’s marker block in that file is your overlap, confirmed. On nginx, check whether two plugins have both generated config snippets you were told to include.
There is a second check worth running, because plugins that do not write to .htaccess can still collide at the PHP level. In wp-admin, look at which plugins offer a login-attempt limit, and count how many have it switched on. If the answer is more than one, that is an overlap even with a clean .htaccess.
Takeaway: the audit is two questions. Who is writing server rules, and who is counting failed logins.
Step 2: sort what you have into the five layers
Every WordPress security tool belongs to one of five layers, defined by when it acts.
| Layer | Acts | Job | Typical tools |
|---|---|---|---|
| 1. Prevention | Before WordPress loads | Change paths, reject bad patterns at the rewrite layer, strip identity signals | WP Ghost, All-In-One Security |
| 2. Detection | After code is on disk | Scan files and database, compare core checksums, clean | Wordfence, MalCare, Sucuri |
| 3. Patching | On known vulnerabilities you already run | Match installed versions to disclosures, apply a mitigating rule before the vendor fix | Patchstack |
| 4. Recovery | After something breaks | Off-site versioned backups and tested restore | UpdraftPlus, BlogVault |
| 5. Edge | In front of your server | DDoS absorption, bot filtering, generic WAF | Cloudflare, Sucuri Cloud |
Layer 3 is the one most people do not know is a category. It exists because, according to Patchstack’s State of WordPress Security in 2026, 46% of vulnerabilities disclosed in 2025 had no patch available at the time of disclosure. “Keep everything updated” is sound advice with a hole in it roughly half the size of the problem.
Write your active plugins into that table. Two failure patterns come out of almost every audit I have done.
The first is three tools in layer 2 and nothing in layers 1 or 3. That site can find an infection three separate ways and cannot prevent one or restore from one.
The second is a layer 1 plugin, a layer 2 plugin, and no backup at all. Better, and still one bad update away from a problem no security plugin solves.
Takeaway: the answer to “which do I remove” falls out of the table. Keep the strongest tool in each occupied layer, remove the duplicates, then fill the empty layers.
Step 3: keep the pair that actually layers
For most sites the working combination is one prevention plugin and one scanner. They coexist because they never touch the same moment in the request.
A prevention plugin acts first. It changes the default paths so a bot probing /wp-login.php gets a 404, and it rejects SQL injection, traversal and file-inclusion patterns as server-level rewrite directives, before PHP starts. Nothing has loaded yet, so there is nothing for a second plugin to conflict with.
A scanner acts last. It reads files on disk, compares WordPress core against official checksums, and tells you what is there. It needs WordPress running to do its job, and it is looking at a completely different question: not “should this request be served” but “what is in this filesystem.”
That is why the pairing works and why two scanners, or two PHP firewalls, do not.
Concretely, on the sites we build this around: WP Ghost handles layer 1, with Paths Security changing 30+ default paths and the 7G and 8G firewall executing as rewrite rules. Wordfence or MalCare handles layer 2. Compatibility with Wordfence, Sucuri and Solid or Kadence Security is tested per WP Ghost release, and the plugins are not competing for the same hook.
Feature to outcome, plainly. Moving the login and admin paths means the brute-force phase never begins, because there is no form at the address the bot holds. Rewrite-layer rejection means a blocked request costs you nothing in PHP execution, which is the measurable difference on a bot-heavy day. Neither of those is a detection function, and WP Ghost does not scan files. If something is already on disk, the scanner is the tool that finds it.
Takeaway: prevention plus detection is one plugin per layer, not two security plugins doing the same job.
Step 4: remove the duplicate safely
Do not deactivate a security plugin and hope. Two of these steps are the ones people skip.
- Back up first, files and database, off-site. This is the step that makes everything after it reversible.
- Note the custom paths. If the plugin you are removing changed your login URL, write down the current one and the default before you touch anything.
- Deactivate, do not delete. Confirm the site loads, the login works and checkout works before deleting.
- Check
.htaccessafterwards. Some plugins leave their marker block behind on deactivation. An orphaned rule set is a future debugging session. - Re-test the survivor. The remaining plugin may have been silently relying on a rule the other one wrote.
If you lock yourself out during this, renaming the plugin’s folder over SFTP deactivates it and restores default WordPress login without touching core files.
Takeaway: back up, record the custom paths, deactivate before deleting, then clean up the leftover rules.
Frequently asked questions
Do I need two WordPress security plugins?
Most sites need two, covering different layers: one prevention plugin and one malware scanner. You do not need two scanners or two firewalls. The test is whether the second plugin acts at a different point in the request than the first. If both hook the login form and both write firewall rules, they overlap rather than layer, and you should keep one.
Can I run Wordfence and WP Ghost at the same time?
Yes, and it is the most common working pair. WP Ghost acts before WordPress loads, changing default paths and rejecting bad request patterns at the rewrite layer. Wordfence acts inside WordPress, scanning files on disk and monitoring live traffic. They are not competing for the same hook, and compatibility is tested per release.
Will two security plugins slow my WordPress site down?
Two PHP-level firewalls will, because every request is evaluated against both rule sets before anything is served, including requests that were never a threat. A prevention plugin whose rules run as server-level rewrite directives has the opposite effect on a bot-heavy site, since rejected requests never load PHP at all.
How do I know if two plugins are conflicting?
Look for more than one security vendor marker block in .htaccess, intermittent 404s on paths that should work, and lockouts you cannot trace to a single log. A quicker check: count how many active plugins have a login-attempt limit switched on. More than one is an overlap even when .htaccess looks clean.
Which security plugin should I remove?
Sort your active plugins by layer, keep the strongest in each occupied layer, and remove the duplicates. If two plugins both scan for malware, keep the one whose scan runs off your server if hosting is tight, or the one with the better threat feed if it is not. If two both change paths or run firewalls, keep the one operating at the rewrite layer.
Is it safe to deactivate a security plugin that changed my login URL?
Yes, if you record the URLs first. Deactivating restores the WordPress defaults, so /wp-login.php works again. The risk is deactivating while you are logged out and cannot remember the custom path. Back up, note both URLs, deactivate rather than delete, and confirm you can log in before removing anything.
Does a backup plugin count as one of my security plugins?
It occupies the recovery layer, so it counts toward layer coverage even though nobody files it under security. It is also the layer most often empty. According to Sophos and Hostinger reporting, roughly 13,000 WordPress sites are compromised per day, and industry compilations put average recovery around $14,500. A tested restore is what separates an afternoon from that figure.
Do I need a security plugin at all if my host provides security?
Usually yes. Host-level and edge protection is generic and has no view of your plugin versions or your login path. Patchstack’s 2026 pentest found hosting and edge WAFs blocked only 12% to 26% of attacks against known-exploited vulnerabilities. Treat host security as the edge layer and cover prevention and detection yourself.
Where to go next
If you have not chosen your tools yet, the layer-by-layer breakdown of which plugin leads which layer is in best WordPress security plugins in 2026. For the method behind the prevention layer, attack surface reduction covers how to audit what your site reveals, and the prevention-first argument this all sits inside is in WordPress hack prevention.
If you want to test the prevention layer alongside whatever scanner you already run, WP Ghost has a free version on wordpress.org.
The fastest version of this whole audit: open .htaccess and count the marker blocks. If there are two security vendors in there, you have your answer before you read anything else.