Here's something that doesn't show up in most security guides: the single most common injury people report after following WordPress security advice isn't a hack. It's locking themselves out of their own site.
It happens like this. You read that you should change your login URL, limit login attempts, and turn on two-factor authentication — all genuinely good advice. You install a plugin, flip a few switches, and close the tab feeling safer. Then you go to log in the next day and you can't. The new login URL didn't save the way you expected. Or the login-limiter decided your own IP address looked suspicious and locked it out. Or two-factor authentication is asking for a code from an app you never finished setting up.
None of this is rare. It's common enough that it shows up by name in reviews of WordPress security books — readers who did everything right and still ended up locked out of a site they own.
So before you touch your login page, set up one thing first: a way back in that doesn't depend on the login page working.
Your way back in, before you change anything
If you only take one idea from this: never make a change to your login page without first confirming you have a second way into your site that doesn't go through that login page.
For WordPress specifically, that second way in is file access — SFTP (or your hosting provider's file manager) to your site's files, and if needed, direct database access through your host's control panel. Here's why that matters: almost every WordPress lockout caused by a security plugin can be undone by renaming that plugin's folder over SFTP. WordPress deactivates a plugin automatically the moment it can't find the folder it expects — no login required. This is well documented by hosts and WordPress resources directly (see WPBeginner and Jetpack for two independent write-ups of the mechanism).
One important, easy-to-miss catch: if you can still log in to wp-admin while a plugin folder is renamed, don't visit the Plugins page. Doing so writes the "deactivated" state to the database, so simply renaming the folder back won't silently re-enable it — you'll need to reactivate it manually afterward. Harmless, just an extra step people don't expect.
Before you do anything else:
- Confirm you have working SFTP or file-manager access to your site, separate from your WordPress admin login. If you've never used it, log in now and just look around — find the wp-content/plugins/ folder and confirm you can see it. You're not changing anything yet, just confirming the door exists.
- If your host only offers FTP (not SFTP), that's a separate, smaller security gap worth fixing — plain FTP sends your password unencrypted. Ask your host if SFTP or SSH-based access is available; most providers worth using offer it.
- Write down — somewhere other than inside WordPress itself — the plain-language fix for a lockout: "rename the folder of whatever plugin I just changed, inside wp-content/plugins/, using SFTP. WordPress will deactivate it automatically. Don't visit the Plugins page in wp-admin until it's renamed back."
That's it. That one step is the difference between "I tried something and it didn't work" and "I'm locked out of my own site and need to call someone."
Now, the actual hardening
With your way back in confirmed, here's what to actually change, in order of how much it matters versus how likely it is to go wrong.
Enforce real passwords, every account, no exceptions. This is the lowest-risk, highest-value step in the whole list. WordPress already nudges toward strong passwords when you create one; the gap is usually an old account someone set up years ago with something short and memorable. Go to Users, open every account with publish or admin-level access, and reset anything that isn't a long, unique, randomly generated password. This cannot lock you out of anything — you're the one setting the new password, and you already know it.
Turn on login-attempt limiting — but set it generously at first. Limiting how many times someone can guess a password in a row is one of the single most effective defenses against the most common attack (automated bots trying thousands of common passwords). The lockout risk here is real but manageable: most tools let you set how many attempts are allowed and how long a lockout lasts. Start generous — say, 10 attempts before a 15-minute lockout — rather than an aggressive 3-attempts-forever-banned default. You can tighten it later once you've confirmed it isn't catching you or your own team by mistake.
Add two-factor authentication — and test it in a way that can't strand you. Two-factor authentication (a code from your phone, in addition to your password) is a genuinely strong defense, but it's also the step most likely to strand you if the setup goes wrong — lost phone, app not configured right, no backup codes saved. Before you make 2FA mandatory for your account: generate and save the backup codes your plugin offers (almost all of them provide a set of one-time backup codes for exactly this situation) somewhere safe and outside WordPress — a password manager, not a text file in the same hosting account. Only after you've confirmed you can log in successfully with the 2FA code once, and you have your backup codes saved, should you consider it actually turned on.
Change your login URL — last, and only if you've confirmed the above works. Moving your login page away from the default /wp-admin or /wp-login.php is a real, meaningful reduction in automated attack traffic, because most bots only ever try the default address. It's also the step most often reported as the direct cause of a lockout, usually because the reader changed it, then cleared their browser cache or switched devices, and genuinely couldn't remember the new address. If you do this: write the new login URL down in the same place as your recovery notes from earlier, not just in your memory or your browser's autofill.
The habit worth keeping
Every step above assumed something could go wrong, and built in a way back before making the change. That habit — confirm your way back in before you touch anything — is worth carrying into every other part of hardening a WordPress or WooCommerce site. It isn't about doing the maximum number of things; it's about doing the right things in an order that never leaves you locked out of something you own.
This article was drafted with AI assistance (Claude) from my own outline and technical direction, then reviewed and fact-checked by me before publishing — disclosed per DEV's AI content guidelines.
I'm considering putting together a longer, practical handbook along these lines, covering server-layer hardening, WooCommerce-specific risks, and a calm cleanup path if you're already compromised. If you have a WordPress or WooCommerce site: what's the security task you keep putting off, or the one that's bitten you before? Genuinely curious what's hardest for people actually running these sites.
Top comments (0)