If you’ve spent an afternoon renaming wp-login.php, stripping the WordPress version number from your source code, and swapping wp_ for a random table prefix, you’ve done real work. It just didn’t buy you much security. These three steps show up in nearly every “harden your WordPress site” checklist floating around the internet, and none of them meaningfully stop a determined attacker. Let’s look at why, then spend the rest of this guide on what actually moves the needle.
Myth 1: Renaming the Login Page Stops Attacks
Moving your login form off /wp-login.php does one real thing: it cuts down the noise from the dumbest, most generic bots that blindly request that path on every WordPress-looking site they find. That’s a minor win for your server logs and maybe a small CPU savings on a busy site.
It does not stop credential stuffing. Attackers running real campaigns don’t rely on guessing your login path, they enumerate it through your sitemap, your REST API responses, login links in password reset emails, or simple brute-force path scanning. A custom login URL can also break things you don’t expect: password reset links, mobile app integrations, and some caching or security plugins assume the default path exists.
Myth 2: Hiding the Version Number Stops Fingerprinting
Removing the generator meta tag from your <head> feels like closing a door. In practice, your WordPress version is visible through half a dozen other signals: the readme.html file if it still exists, version query strings on core CSS and JS files, unique file structures introduced in specific releases, and even response header quirks. Automated scanners don’t need your stated version to try known exploits, they just try them and see what sticks.
More importantly, most real-world compromises target outdated plugins and themes, not WordPress core. Core gets patched fast and most attacks move on to less-maintained third-party code regardless of what your site claims its version is.
Myth 3: Changing the Table Prefix Stops SQL Injection
Swapping wp_ for something like xk29_ stops exactly one thing: the laziest, hardcoded automated scripts that assume every WordPress install uses the default prefix. If your site actually has a SQL injection vulnerability, an attacker can query information_schema to enumerate your real table names in seconds. The custom prefix adds a trivial extra step for a script kiddie and nothing at all for anyone who knows what they’re doing.
Why This Folklore Persists
These three tips survive because they’re easy, visible, and give you a satisfying sense of having done something. You can point at the changed URL or the renamed table and feel more secure. Real hardening work is less visible: patching on a schedule, auditing user roles, testing a backup restore. It doesn’t feel dramatic, but it’s the difference between a site that recovers from an incident and one that doesn’t.
What Actually Reduces Risk
- Strong, unique passwords plus two-factor authentication for every account with publishing or admin access, not just the main admin login.
- Limiting login attempts, either through a plugin or at the edge with something like Cloudflare’s rate limiting, so brute-force attempts get throttled before they reach your server.
- Disabling XML-RPC if you don’t use it for anything (no Jetpack, no remote publishing apps). It’s a common target for credential stuffing and pingback abuse.
- Setting
DISALLOW_FILE_EDITso the theme and plugin editors in wp-admin can’t be used to drop malicious code if an account is ever compromised. - Least-privilege user roles. Not every contributor needs Administrator. Audit this at least twice a year.
- Tested off-site backups. A backup you’ve never restored isn’t a backup, it’s a hope.
- Keeping core, plugins, and themes updated on a real schedule, not “whenever I remember.”
A Practical Hardening Pass With wp-cli
Most of this can be scripted or scheduled instead of clicked through manually. A few starting points:
wp core update
wp plugin update --all
wp theme update --all
wp user list --role=administrator --fields=user_login,user_email
That last command is worth running regularly. It’s an easy way to catch an admin account you forgot existed, or one that should have been demoted months ago.
Add this to wp-config.php to lock down the file editors:
define( 'DISALLOW_FILE_EDIT', true );
If you don’t use XML-RPC at all, you can disable it with a small snippet in a must-use plugin or your theme’s functions file:
add_filter( 'xmlrpc_enabled', '__return_false' );
Before you touch anything else, confirm your backups actually work by pulling one down and test-restoring it somewhere disposable:
wp db export backup-$(date +%F).sql
An export command that runs without error isn’t proof of a good backup. A successful restore is.
Where the Edge Helps
A lot of this hardening happens more effectively outside WordPress entirely. Putting Cloudflare in front of your site gives you a web application firewall, bot mitigation, and DDoS protection before requests ever reach your origin server, and keeping your origin IP unpublished matters a lot for resilience against direct attacks that try to bypass the edge. On managed hosting like ServerBorn, a fair amount of this, edge-level bot mitigation and hardened server configuration, is already handled for you, which frees up your time for the account-level hygiene that’s still your responsibility: passwords, roles, updates, and backups.
The Bottom Line
Renaming your login URL, hiding your version number, and changing your table prefix aren’t harmful, but they’re not where your time should go. The real risk to most WordPress sites comes from weak or reused passwords, outdated plugins, over-privileged accounts, and backups nobody has ever tested. Spend your hardening hour there instead, and let the folklore steps stay optional.