WordPress Hardening: Stop Malware Flags Coming Back
WordPress hardening means closing the doors attackers walk through: updating core, plugins, and themes; turning on two-factor login; removing nulled or unused extensions; running a firewall; and keeping clean backups. Do this and the malware that triggered a blocklist flag is far less likely to come back — or get you flagged again.
Most reinfections aren't bad luck. They happen because the original hole never got patched. You clean the site, vendors eventually delist it, and weeks later the same backdoor lets the same payload back in. Hardening breaks that loop. This guide walks through the checklist in plain terms, in roughly the order that matters most.
TL;DR: Plugins cause the large majority of WordPress vulnerabilities — Patchstack logged that 97% of the vulnerabilities it recorded in 2021 came from plugins (Patchstack State of WordPress Security, 2022). So patch fast, drop nulled plugins, add 2FA and a firewall, and keep backups. That combination is what stops malware flags from returning.
A quick scope note before we start. Hardening is prevention. If your site is already infected, clean it first — our walkthrough on removing WordPress malware covers that. Hardening a still-infected site just locks the attacker inside with you.
Why do malware flags keep coming back after removal?
Flags come back because cleanup and hardening are two different jobs, and people often only do the first. Patchstack found that 97% of the WordPress vulnerabilities it tracked in 2021 originated in plugins (Patchstack, 2022). If you delete the malware but leave the vulnerable plugin, the door stays open.
There's a second pattern worth naming. Attackers rarely leave just one payload. They plant backdoors — small, hidden scripts that let them return even after you've scrubbed the visible infection. Wordfence has repeatedly reported backdoors among the most common malware types it cleans. Miss one backdoor and you're reinfected within days, sometimes hours.
In our experience running unflag, the sites that get re-flagged almost always skipped one of two steps: they never updated the entry-point plugin, or they restored from a backup that already contained the infection. We clear residual blocklist flags after a cleanup — we don't scan or clean the site ourselves — so when a flag returns, it's nearly always because the original hole was left open, not because the delisting failed. Reinfection is usually a process failure, not a sophistication problem.
This matters for blocklists specifically. Google's Safe Browsing protects billions of devices and rechecks sites it has flagged (Google Safe Browsing, 2024). If the malware returns, you go right back on the list — and a second flag is harder to clear than the first.
When we scan a domain, we check it across 124 active security vendors — 78 antivirus engines, 38 web blocklists, and a handful of RBL and search-engine sources — so a single returning payload can trip several lists at once.
We've written separately about how to stop a website getting blacklisted again from the blocklist side. This page is about the WordPress side — the actual hardening.
What's the single most important WordPress hardening step?
Keep everything updated. It's unglamorous, and it's the highest-impact thing you can do. Roughly 43% of all websites run on WordPress (W3Techs, 2024), which makes it the biggest target on the internet — and outdated software is the favorite way in. Most successful attacks exploit a flaw that already had a patch available.
Update core, plugins, and themes
Turn on automatic updates for WordPress core and for plugins you trust. The HTTP Archive's Web Almanac reported that a large share of WordPress sites still run an outdated core version (Web Almanac, 2022), which is exactly the gap attackers scan for. Set a weekly reminder to log in and apply anything that didn't auto-update.
A practical rhythm we recommend: enable auto-updates for everything low-risk, then manually review major plugin updates once a week so a bad release can't break your site silently. Updates aren't optional maintenance — they're the patch that closes the hole the malware used.
Remove what you don't use
Every installed plugin and theme is attack surface, active or not. A deactivated plugin can still be exploited because its files sit on your server. Delete — don't just deactivate — anything you're not actively using. Fewer plugins means fewer vulnerabilities to track and fewer doors to lock.
Why are nulled plugins and themes so dangerous?
Nulled plugins — pirated "premium" plugins shared for free — are one of the most reliable ways to get reinfected, because many ship with backdoors baked in. You're not just installing a feature; you're installing whatever the person who cracked it added. Sucuri has long warned that pirated extensions are a leading source of WordPress compromises (Sucuri Blog, 2021).
The trap is that the plugin works. It looks legitimate, performs its function, and quietly maintains a hidden entry point. You clean your site, get delisted, and the nulled plugin's backdoor lets the attacker right back in. Then you're flagged again — often within the same month.
Running unflag, we've watched owners spend weeks cleaning and requesting removal, then get re-flagged, only to discover a single nulled gallery or page-builder plugin was the source the whole time. Our dashboard shows the real sent, bounced, and failed count per vendor, so the dispatch side was clearly working — the problem was the residual backdoor we don't touch. Removing the nulled plugin ended the cycle immediately.
The fix is simple and absolute: if you can't afford the premium license, use a reputable free alternative from the official WordPress.org directory. Never run nulled code. The "free" version costs far more than the license once you count reinfection, lost traffic, and delisting headaches.
How do you lock down WordPress logins?
Strong login security blocks the brute-force and credential-stuffing attacks that hit WordPress constantly. Wordfence has reported blocking billions of malicious login attempts across the sites it protects (Wordfence, 2021), which tells you how aggressively the admin door gets rattled. Two layers fix most of it: a unique strong password and two-factor authentication.
Turn on two-factor authentication (2FA)
2FA is the highest-value login control you can add. Even if an attacker steals or guesses your password, they can't log in without the second factor — usually a code from your phone. Microsoft has stated that multifactor authentication blocks over 99.9% of account-compromise attacks (Microsoft Security Blog, 2019). Add it to every admin account, not just yours.
Apply least privilege
Give each person the lowest role that lets them do their job. Your content writer doesn't need Administrator; the Editor or Author role is plenty. Fewer admin accounts means fewer high-value targets. If a contributor's password leaks, a limited role contains the damage instead of handing over the whole site.
Other quick login wins
Rename the default admin username — it's the first one bots try. Limit login attempts so brute-force tools get locked out fast. And remove old accounts the moment someone leaves. Each dormant account is an unlocked door nobody's watching.
Does a WordPress site need a firewall (WAF)?
Yes — a web application firewall is the layer that blocks attacks before they reach your code. A WAF inspects incoming traffic and filters out exploit attempts, bad bots, and known-malicious requests. It's especially valuable in the window between a vulnerability being disclosed and you applying the patch. Patchstack reported thousands of new WordPress vulnerabilities added to its database in a single year (Patchstack State of WordPress Security 2023, 2024), so that gap is real and constant.
There are two main flavors. A cloud WAF (like Cloudflare or Sucuri) sits in front of your site and filters traffic before it ever hits your server. An endpoint/plugin WAF (like Wordfence) runs on WordPress itself. Cloud options also absorb DDoS traffic and speed up your site through caching — a nice bonus.
A WAF isn't a substitute for updating; it's a safety net for the days you can't patch immediately. Think of it as the smoke detector, not the reason to leave the stove on. From what we see running unflag, owners who treat it as "set and forget security" still get compromised through credentials and nulled code, which a WAF won't catch — and those are exactly the sites that come back to us for a second round of flags.
Why do backups matter for staying off blocklists?
Clean backups are your fastest recovery and your best insurance against reinfection — if they're clean. The catch most people miss: a backup taken after the infection contains the malware too. Restore it and you've reinstalled the problem, which puts you straight back on the blocklist. Sucuri and other vendors consistently rank reinfection from compromised backups among the top recovery mistakes.
Set up automated, off-site backups
Schedule automatic backups and store them somewhere separate from your hosting — cloud storage, not the same server. If your host gets compromised, on-server backups can be compromised too. Keep several versions going back weeks, so you can roll back to a point before the infection if you need to.
Test that you can actually restore
A backup you've never restored is a guess, not a safety net. Test the restore process at least once on a staging site so you know it works and you know how long it takes. The middle of a malware incident is the worst time to discover your backups are corrupt or incomplete.
Where does unflag fit in this?
unflag handles the part after you've cleaned and hardened your site: getting the security vendors to drop the flag. Once your WordPress install is fixed and locked down, unflag generates personalized removal-request emails and dispatches them to each flagging vendor for a one-time €39 per domain. We guarantee the dispatch — we send the requests on your behalf — but each vendor makes its own delisting decision on its own timeline.
To be clear about scope: unflag doesn't scan or clean malware, and it can't automate Google's review. Google Safe Browsing reviews are submitted manually through Search Console — there's no API for it — so it becomes a guided dashboard card with the exact text to paste in and a step-by-step guide. Vendors that only take web forms, like AVG and ESET, become guided cards too. For every vendor that accepts email, we generate a unique request — varied so they aren't identical spam — and dispatch them sequentially over a randomized one-hour window, each with your address as the reply-to so replies land straight in your inbox. If one bounces, we re-dispatch.
The order that works: clean the infection, harden with this checklist, then request delisting. Skip the hardening and you risk a second flag that's slower and harder to clear than the first.
Your WordPress hardening checklist
Here's the whole thing in one place. Work top to bottom; the items near the top stop the most attacks.
- Update core, plugins, and themes — enable auto-updates, review weekly.
- Delete unused plugins and themes — not just deactivate.
- Remove every nulled plugin or theme — replace with official free alternatives.
- Turn on two-factor authentication for all admin accounts.
- Apply least privilege — give each user the lowest role that works.
- Rename the
adminuser and limit login attempts. - Run a WAF — cloud (Cloudflare/Sucuri) or endpoint (Wordfence).
- Automate off-site backups and test a restore on staging.
- Use strong, unique passwords and a password manager.
- Keep PHP and your host's software current, too.
Hardening isn't a one-time task — it's a habit. But the bulk of the protection comes from the first few items: patch fast, ditch nulled code, add 2FA, and keep clean backups. Do those and the malware that got you flagged has nowhere to come back to.
If you've already cleaned the infection and you're ready to clear the flags, see how getting removed from a blocklist works and start the request. Harden first — then delist with confidence.
Start with updates: keep core, plugins, and themes current and delete anything unused. Then add two-factor authentication, remove all nulled plugins, apply least-privilege user roles, run a web application firewall, and keep automated off-site backups. These steps close the entry points attackers reuse, which is what stops malware flags from returning.
Usually because the original vulnerability was never patched, or a hidden backdoor survived the cleanup. Patchstack found 97% of WordPress vulnerabilities it tracked in 2021 came from plugins ([Patchstack](https://patchstack.com/whitepaper/the-state-of-wordpress-security-in-2021/), 2022). If you remove malware but leave the vulnerable plugin or a nulled extension, the door stays open.
Yes. Nulled (pirated) plugins frequently ship with hidden backdoors that let attackers back in after you've cleaned the site. Sucuri warns they're a leading source of compromise ([Sucuri](https://blog.sucuri.net/2021/01/nulled-plugins-and-themes-the-traps-behind-going-free.html), 2021). The plugin works normally while quietly maintaining an entry point, so always use official free alternatives instead.
Yes. A web application firewall protects you in the gap between a vulnerability being disclosed and you applying the patch — and Patchstack logs thousands of new WordPress vulnerabilities yearly ([Patchstack](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2023/), 2024). A WAF blocks exploit attempts before they reach your code, but it doesn't replace updating or removing nulled software.
Hardening prevents the reinfection that gets you re-flagged, but it doesn't remove an existing flag. You'll still need to request delisting from each vendor — Google Safe Browsing reviews go through Search Console manually. Clean the site, harden it, then request removal so a second flag doesn't appear later.