If you’re here because someone told you “you need to secure your WordPress site” and you’re not sure where to actually start, this is written for you specifically. No jargon, no fear tactics, just the steps that matter, in the order they matter most.
The good news first: you don’t need to be a security expert. Most successful WordPress attacks aren’t clever, they’re automated bots checking thousands of sites for the same handful of easy, well-known weaknesses, an outdated plugin, a weak reused password, a login page with nothing slowing down repeated guesses. Close those off and you’ve already dealt with the overwhelming majority of real-world risk. This isn’t a theoretical exercise either, WordPress powers a huge share of all websites on the internet, which is precisely why it’s such a consistent target, the sheer number of sites running it means automated attack tools are built and continuously refined specifically against it.
1. Update everything, and don’t put it off
This is the single highest-impact thing on this list, and it’s not close. When a security patch is released for WordPress core, a plugin, or a theme, the vulnerability it fixes usually becomes public knowledge at the same time, sometimes in the patch notes themselves. That means attackers know exactly what to try against every site that hasn’t updated yet, and automated bots start scanning for unpatched sites within hours of a disclosure, not weeks. According to Wordfence’s own security research, plugin vulnerabilities account for the large majority of all WordPress security issues, not core WordPress itself, which is why “I keep WordPress updated” isn’t the same claim as “I keep everything updated.”
Go to Dashboard → Updates right now and update anything that’s behind. Turn on automatic updates for minor WordPress releases if your host supports it, WordPress.org’s own hardening guide specifically recommends this as a baseline. Set a reminder to check plugin and theme updates weekly if you can’t automate them, and if a specific plugin hasn’t been updated in over a year, that’s worth treating as a real warning sign on its own, an abandoned plugin stops getting security patches even for vulnerabilities that get discovered after the fact.
2. Delete what you’re not using
An inactive plugin or theme is still a plugin or theme, it’s still code sitting on your server, and if it stops being maintained, it stops getting security patches while remaining just as exploitable. This is a genuinely common mistake, deactivating something feels like it’s “off,” but the files are still there, still readable, and in some cases still directly reachable by URL even while deactivated. Go to Plugins → Installed Plugins and Appearance → Themes, and actually delete (not just deactivate) anything you’re not using.
Same goes for old admin accounts nobody’s used in months, a forgotten login is a forgotten door, and it’s worth a specific check for any account with an email address you no longer control, a former employee, an old contractor, since a compromised email associated with a still-active WordPress account is a password-reset attack waiting to happen. While you’re checking accounts, it’s also worth a quick look for any username that’s simply “admin,” a well-known default that automated login-guessing tools try first on essentially every WordPress site they hit, changing it to something less predictable removes one variable an attacker would otherwise get for free.
3. Use a password manager and turn on 2FA
A strong, unique password for every admin account is non-negotiable, and a password manager makes that genuinely easy rather than a chore, you never actually have to remember or type a complex password yourself, the manager does it. NIST’s own digital identity guidelines, the US government’s standard reference for authentication security, specifically recommend length over complexity rules, a genuinely long passphrase beats a short password stuffed with symbols nobody can remember anyway.
On top of that, two-factor authentication means a stolen or guessed password alone isn’t enough to get in, the attacker also needs a second proof, a code from your phone or authenticator app, or increasingly, a passkey. Require it for every administrator and editor, not just yourself, one weak account is enough for a site to get compromised, security is only as strong as the weakest login with real access.
4. Make sure HTTPS is actually on everywhere
If your site still loads over plain HTTP anywhere, logins, forms, checkout, anything typed on your site is traveling unencrypted, readable by anyone positioned to intercept it, an unsecured public WiFi network being the classic example. Most hosts offer free auto-renewing SSL certificates now, commonly through Let’s Encrypt, a nonprofit certificate authority that made this genuinely free and automated for the whole web, there’s rarely a good reason not to have this fully on. Check specifically that every page redirects to HTTPS, not just the homepage, a site with HTTPS on the login page but not elsewhere still leaves real gaps, and a mixed-content warning (some resources loading over HTTP even on an otherwise HTTPS page) is worth chasing down too, since browsers increasingly flag that visibly to visitors as a trust signal problem.
5. Limit login attempts
Without this, a bot can try thousands of password guesses against your login page with nothing slowing it down, WordPress itself has no built-in cap on failed attempts, an attacker can process 10,000 login attempts in a row and the software will happily work through every single one. Limiting how many attempts an IP gets before it’s temporarily blocked turns a fast automated attack into a slow, impractical one. This is table stakes, and it’s usually the first thing any security plugin adds, if a plugin you’re evaluating doesn’t offer this in its free tier, that’s worth treating as a real gap, not a minor omission.
Worth knowing the failure mode of an overly aggressive setting too, a lockout threshold set too low can genuinely lock out a real team member who’s simply forgotten their password, so a reasonable balance (a handful of attempts, a lockout measured in minutes rather than hours for a first offense) tends to work better in practice than the strictest possible setting.
6. Back up off-site, not just on the same server
A backup stored on the same server it’s protecting doesn’t help much if that server gets compromised or fails, the backup can go down with it. Use a plugin or host feature that stores copies somewhere else entirely, a separate cloud storage location, not just a folder on the same hosting account. The classic reliable pattern here is the “3-2-1” rule: at least three copies of your data, on two different types of storage, with at least one copy stored off-site. Test that a backup can actually be restored before you need it for real, an untested backup is a hope, not a plan, and the worst time to discover a backup is corrupted or incomplete is during an actual emergency.
Practically, that testing step is the one people skip most often, it takes real time and, on the surface, seems unnecessary if the backup plugin reports success every night. But “the backup ran” and “the backup actually restores a working site” are different claims, a corrupted database export, a backup that silently excluded the uploads folder, or a restore process that’s never actually been walked through once can all mean a backup that looks fine right up until the moment it’s genuinely needed. Set a calendar reminder to do a real test restore, ideally to a staging environment rather than your live site, every few months.
7. Get comfortable with the idea of a security plugin, as one layer
A security plugin isn’t a magic shield, and it’s worth understanding what it actually adds rather than treating it as a checkbox. What a decent one genuinely does for a beginner: brute-force protection, malware and file-integrity scanning, 2FA, and blocking the most common automated attack patterns, all without you needing to configure any of it by hand.
This is where SecondGate fits, if you’d rather not piece together five separate plugins to cover this checklist. Its free tier covers 2FA with passkey support and brute-force protection, no card required. File integrity scanning with auto-restore and blocking common attack patterns beyond brute force sit in a Pro tier at £39.99/year. It’s honest about what it isn’t too, it’s not a full web application firewall backed by a dedicated threat-intel team, and it doesn’t handle backups or WordPress core updates, those are still genuinely your job (steps 1 and 6 above).
8. Hide your login URL, carefully
Bots overwhelmingly target the default /wp-login.php. Changing it isn’t a cure-all, a genuinely targeted attacker can usually still find the real login page, this mostly removes you from blind automated sweeps rather than stopping a determined human. But that volume reduction is real and worth having.
Worth a specific, serious warning here: this is the one setting in most security plugins that can genuinely lock you out if misconfigured. Always test the new URL in a private browser window before logging out of your current session, don’t just trust that it worked. Know your emergency fallback too, most plugins that offer this feature also offer a way to disable it via a constant in wp-config.php if you ever get locked out and can’t reach the login page any other way.
9. Disable XML-RPC if you don’t use it
XML-RPC is a common target for brute-force and amplification attacks, since a single request to it can sometimes attempt multiple login combinations at once. Only turn it off if you’re not using the Jetpack plugin, the WordPress mobile app, or another tool that specifically needs it, disabling something you’re actually relying on breaks real functionality, not just theoretical risk.
10. Add security headers
A small, easy-to-overlook step: standard security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) tell browsers to enforce extra protections on your behalf, preventing your site from being embedded in a malicious iframe on someone else’s page, for instance, or stopping a browser from guessing at a file’s type in a way that could be exploited. Most security plugins can turn these on with a single checkbox, and there’s essentially zero downside or compatibility risk to having them on.
11. Check your user roles and lock down uploads
Not everyone who logs in needs to be an Administrator. Give people the lowest role that lets them actually do their job, an Editor role covers writing and publishing content without needing full site-level access, a Contributor can write without publishing, an Author can manage their own posts without touching anyone else’s. A common real-world mistake worth avoiding: making every team member or client contact an Administrator “just in case,” which quietly turns a single compromised low-privilege account into a full site takeover the moment its role is set too generously.
Separately, if your plugin offers it, blocking PHP files from executing inside your uploads folder closes off one of the most common real-world compromise routes, a malicious file disguised as an image, uploaded through a form or a vulnerable plugin, then requested directly to run. WordPress core has never needed PHP execution there, that folder is meant for media, not code, so there’s no functional downside to blocking it, this is one of those rare security steps with genuinely zero trade-off for a normal site.
A quick self-check before you start
Before working through the list, a two-minute gut check that tells you roughly how urgent this is: when did you last log into your WordPress dashboard and actually update something? If it’s been over a month, updates alone are likely already overdue. Do you know every email address that has admin access right now, off the top of your head, without checking? If not, that’s item 2 waiting for you. Could you tell someone your admin password right now without opening a password manager? If yes, that’s a real, immediate risk, not a hypothetical one, and item 3 should happen today, not this week.
None of that is meant to alarm, it’s meant to tell you honestly where to start, since not every reader is starting from the same place, and a site that’s already mostly on top of updates and passwords can move faster through this list than one that isn’t.
The honest summary
If you only do the first three items on this list today, updates, deleting unused plugins, and 2FA with unique passwords, you’ve already closed off the overwhelming majority of how WordPress sites actually get compromised. Everything after that is genuinely worth doing, but it’s improvement on a foundation, not a substitute for it.
A note on what this list deliberately doesn’t cover
This is a starting checklist, not a complete security program, and it’s worth being honest about the gap between the two. It doesn’t cover server-level hardening (firewall rules at the hosting level, file permission audits, PHP version management), which is either your host’s job on managed hosting or a genuinely more advanced topic if you’re self-managing a VPS. It doesn’t cover incident response, what to actually do if, despite all this, something does go wrong, that’s different enough to deserve its own dedicated walkthrough rather than a bullet point here. And it doesn’t cover compliance-specific requirements (GDPR, PCI-DSS for payment handling, industry-specific regulations), which layer real additional obligations on top of general security practice for sites that need them.
None of that is because those things don’t matter, it’s because a genuinely useful beginner checklist has to stay a checklist, a list of forty things “you should also consider” stops being actionable and starts being overwhelming, which defeats the actual purpose of writing this in the first place.
How to actually use this list, not just read it
Practical order of operations, since reading eleven items in one sitting and doing nothing is a common failure mode: block out twenty minutes today for items 1 through 3 specifically, updates, deleting unused plugins, and 2FA. Those three alone meaningfully change your risk profile and take less time than reading the rest of this article twice. Come back within the week for items 4 through 6, HTTPS, login limiting, and genuinely testing a backup restore. The remaining items are real, worthwhile improvements, but they’re not the difference between a vulnerable site and a reasonably protected one the way the first six are, treat them as an ongoing project rather than something that has to happen today.
If it helps to have a single sentence to hold onto: a WordPress site that’s fully updated, has unique strong passwords with 2FA everywhere, and has a genuinely tested backup, is already meaningfully safer than the overwhelming majority of WordPress sites currently online, most of which are missing at least one of those three basics. That’s not a low bar because security doesn’t matter, it’s a low bar because so few sites actually clear it, and clearing it puts you ahead of most of the automated attack traffic hitting WordPress sites at any given moment.
