WordPress security works in three layers: the network in front of your site, the software running on it, and the people who hold logins. Most advice covers the first two. Most of the trouble starts with the third.
The dramatic version of a hacked website has someone defeating a firewall. The ordinary version is duller. A password got reused on a forum that later leaked. A plugin sat eighteen months past a published vulnerability. An administrator account still belongs to a contractor who stopped working there in 2019 and was never removed.
Most WordPress sites are not broken into. They are logged into.
That distinction decides where your effort is worth spending. Start at the outside and work in.
Cloudflare filters traffic before it reaches your host
Cloudflare sits between the public internet and your web server. You point your domain’s DNS at Cloudflare, it passes legitimate requests along to your host, and a lot of the rest stops there.
Three things it does well:
- Absorbs volume. Automated scanners and denial of service traffic hit Cloudflare rather than your hosting account, so your server never spends resources on them.
- Drops obviously hostile requests at the edge, before any PHP runs.
- Hides your origin. Once traffic runs through the proxy, the public sees Cloudflare’s addresses instead of your server’s, which makes it harder for anyone to go around the filter and hit the host directly.
The free tier covers the proxy, the denial of service absorption and a basic managed rule set, which is enough for most small business sites. Caching comes along with it, so pages get faster as a side effect.
Now the limits, because this is the part people get wrong.
Cloudflare cannot tell a real login from a stolen one. Someone typing a correct username and password taken from a leaked list is making a valid request, and passing valid requests through is exactly what a proxy is built to do. It behaves correctly and you still lose the site.
It is also not a backup. Cloudflare caches copies of pages, it does not keep a restorable copy of your website. If someone modifies your files, Cloudflare will serve the modified version quickly and reliably.
Wordfence runs inside WordPress and knows what WordPress looks like
Cloudflare sees web requests. It does not know what a WordPress plugin is. A security plugin does, and that is the useful difference between the two layers.
Wordfence is the common choice. You get a firewall with rules written for WordPress specifically, so it can block a known attack against a particular plugin or theme. You get a malware scan that compares your core, plugin and theme files against the originals and flags anything altered or unfamiliar. You get login rate limiting, which cuts off password guessing after a few failures instead of letting it run all night. And the free version includes two-factor authentication for admin accounts.
Two honest caveats. It runs inside WordPress, on every request, so it costs some performance. On a small site that cost is small, on a busy one it is worth measuring rather than assuming. And a scanner is retrospective by nature. It tells you about a compromise that has already happened, which is worth knowing, but it is not prevention.
The part I value most is the least dramatic one: it tells you when a plugin you have installed gets a published vulnerability. Plugins with known, already-patched vulnerabilities are the ordinary way sites get taken. Nobody targets you personally. A scanner sweeps the web looking for sites still running the vulnerable version, and finds you because you are still running it.
That changes what an update is. Updating plugins is not housekeeping you do when you get around to it, it is the security control. The gap between a vulnerability being published and being patched on your site is the window you are exposed in, and the length of that window is the one variable you fully control. Worth knowing: Wordfence’s free version receives new firewall rules 30 days after paying customers, so the free tier does not close the window as quickly.
Which argues for running fewer plugins, since each one is another thing to watch, and for treating an abandoned plugin, one with no update in a couple of years, as a liability rather than a convenience. The general rhythm of updates and backups is a separate subject, and I covered it in what WordPress maintenance actually involves.
Most WordPress security failures are login failures
This layer gets the least attention and returns the most, and almost none of it is technical.
Use a password manager, and a different password everywhere. The attack this defeats is credential stuffing. Someone takes username and password pairs from an unrelated breach at a retailer or a forum and tries them against your website, your host and your email. It works often enough to be worth their time, and it costs nothing to defeat. Unique passwords keep a leak somewhere else from becoming a problem here.
Turn on two-factor in four places rather than one. The WordPress admin is the obvious one. Add your hosting account, your domain registrar, and above all your email account. Email is the master key. Anyone holding it can reset the other three, so locking down WordPress while the mailbox sits on a reused password protects very little.
Give everyone their own account. One shared “admin” login used by four people cannot be traced or revoked. You cannot tell who changed a page, and when one of the four leaves you have to change the password on all of them. Named accounts fix both problems at once.
Remove accounts when people leave. This is the most common thing I find on sites I take over: live administrator accounts belonging to a former employee, a freelancer whose project ended years ago, or the agency that built the original site. Nobody was careless. Removing the account was simply never anybody’s job. Attach it to whatever you already do when someone stops working with you, alongside the keys and the email forwarding.
Hand out the smallest role that works. WordPress ships with roles for a reason. An Editor can write, edit and publish every page on the site, and cannot install a plugin or create a user. That covers most of the people who ask you for access. Administrator is the account worth stealing, so keep the number of them small and be able to name every one.
Be suspicious of email about your website. Phishing aimed at site owners is plain stuff: your domain is expiring, your site has a critical error, please confirm your login. The habit worth building is to never act from the link. Go to the site you already know, sign in the way you always do, and see whether the thing is actually true.
Do I need Cloudflare if I already have a security plugin?
They do different jobs, so most small business sites end up running both. Cloudflare filters traffic before it reaches your hosting account, which means junk requests never consume your server’s PHP and database resources. A plugin like Wordfence only sees requests that have already arrived, but it understands WordPress well enough to recognize an attack aimed at one specific plugin. The free tier of each is enough for a typical small business site. Neither of them stops somebody signing in with a password that is genuinely yours, which is why unique passwords and two-factor authentication matter more than either.
If something has already gone wrong
Work in this order, and take your time with it.
- Change passwords, starting with the email account, then the host, the registrar and WordPress. If the mailbox is compromised, changing anything else accomplishes nothing.
- Work out when it started. Host access logs and file modification dates will get you close. You need the date before you can tell which backup is still clean.
- Restore from a backup taken before that date rather than cleaning files in place.
- Find how they got in, close it, then update everything.
Two things worth saying plainly.
A backup you have never restored from is a hypothesis. Plenty of sites have a backup plugin that has run for years, writing files nobody has ever opened. Restore one to a staging copy on a calm afternoon and you will find out whether you have backups or a scheduled task. That one test is worth more than anything on the plugin’s settings page.
And cleaning up without finding the entry vector means it comes back. Removing injected code removes the symptom. If the way in was a vulnerable plugin, or a password that is still valid somewhere else, the same visitor returns the following week and everyone concludes the site is cursed.
If customer data or payments were involved, this stops being a website question. Get help, and preserve what you have rather than deleting it.
The cheap part is the effective part
Add up what is actually being recommended here and it is a free Cloudflare account, a security plugin, a password manager, two-factor in four places, and an accurate list of who can log in. The money involved is close to nothing. What it costs is attention, mostly paid once and then kept up.
Patrick Iverson builds and looks after custom WordPress websites from Santa Fe, and if you want somewhere to start this week, start with the least technical thing on the list: open your users list and read every name on it out loud.
