WordPress powers roughly 43% of the web. That market share is exactly why it’s the most targeted CMS for automated attacks. Most successful compromises aren’t sophisticated — they exploit outdated software, weak credentials, or default configurations that nobody changed at setup. This guide covers the ten most impactful things you can do to harden a self-hosted WordPress installation in 2026. None of these require a security background. They require about two hours and the willingness to actually do them.
:::note[TL;DR]
- Never use “admin” as your username — create a new administrator and delete the default
- Hide your WordPress version number and delete
readme.html - Disable XML-RPC unless you actively use it — it’s a brute-force magnet
- Set file permissions to 755 for directories, 644 for files
- Add two-factor authentication to every admin account
- Install Wordfence or Sucuri and leave it running :::
Why is WordPress such a common attack target?
Because it’s open-source and the version number is usually visible in the page source. Automated bots scan millions of sites for outdated WordPress installs, known vulnerable plugins, and default configurations. When they find a match, the attack is also automated. You don’t get attacked by a person — you get attacked by a script that found your site in a list.
The good news: most of these attacks are opportunistic. Basic hardening puts you below the threshold of easy targets.
The Scenario: Your WordPress blog hasn’t been touched in eight months. You log in one day to find spam links injected into old posts, redirecting your visitors to a pill pharmacy. No one targeted you specifically — a bot found your outdated plugin version and exploited it. The fix would have taken five minutes. The cleanup took three days.
What is the first thing to change after installing WordPress?
Change your username. When you install WordPress, the default admin account is called admin. Every automated attack script tries admin first. It’s not a secret.
Create a new user with a random username and administrator role, log in as that user, then delete the original admin account. WordPress will prompt you to reassign any posts to the new account.
You can also use Jetpack’s single sign-on to log in with a WordPress.com account instead of a local password — useful if you want to centralize login management.
The Scenario: Your login page gets 200 brute-force attempts per day (Wordfence will show you this). Every single one is trying
adminas the username. Rename it to something obscure and all 200 attempts fail before they even try a password.
How do I hide my WordPress version number?
WordPress embeds the version number in the <head> of every page as a <meta> tag. It also sits in readme.html at the root of your install. Attackers use this to prioritize targets — an unpatched 6.2 site is a known vulnerability list.
Remove it from the <meta> tag by adding this to your theme’s functions.php:
remove_action('wp_head', 'wp_generator');Delete readme.html from your WordPress root directory:
rm /path/to/wordpress/readme.htmlDo both. The meta tag removal alone still leaves the file.
How do I lock down WordPress file permissions?
Incorrect file permissions are a common way attackers write malicious files to your server. Run these two commands in your WordPress directory to set correct permissions across the board.
For directories (755 = owner can write, everyone else can read and execute):
find /path/to/wordpress/ -type d -exec chmod 755 {} \;For files (644 = owner can read/write, everyone else can only read):
find /path/to/wordpress/ -type f -exec chmod 644 {} \;To audit which directories currently allow world-write access:
find . -type d -perm -o=wAny directory that shows up in that list is writable by anyone on the server. Fix it with chmod 755.
:::warning
wp-config.php should be even more restrictive. Set it to 600 (owner read/write only): chmod 600 wp-config.php. Never leave it world-readable.
:::
The Scenario: A poorly configured plugin creates a temp directory with 777 permissions during install and never cleans it up. A bot finds it via path scanning and uploads a PHP shell. Auditing permissions catches this before it’s exploited.
Should I disable directory browsing?
Yes. If a directory doesn’t have an index.php or index.html file, most web servers will list its contents by default. That exposes your plugin names, theme files, and upload structure to anyone who looks.
Add this line to the top of your .htaccess file in the WordPress root:
Options -IndexesOne line. Done. Anyone trying to browse /wp-content/uploads/ will now get a 403 instead of a file listing.
How do I disable XML-RPC in WordPress?
XML-RPC is a remote publishing protocol built into WordPress. In 2026 almost nobody uses it intentionally, but automated brute-force tools love it — it allows hundreds of password attempts in a single HTTP request, bypassing per-attempt rate limits.
Disable it entirely by adding this to .htaccess:
# Disable XML-RPC
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Or use a plugin like Disable XML-RPC if you prefer not to touch .htaccess.
:::warning The Jetpack plugin uses XML-RPC to communicate with WordPress.com. If you’re running Jetpack, disabling XML-RPC will break Jetpack features. Check your usage before blocking it. :::
How do I change the default table prefix?
If you installed WordPress with default settings, every database table starts with wp_. SQL injection attacks often assume this prefix. Changing it to something random removes an easy assumption attackers can make.
Use a plugin like Change Table Prefix (search the WordPress plugin directory). It handles the rename and updates wp-config.php in one step — don’t try to do it manually unless you know exactly what you’re touching.
After renaming, verify the $table_prefix value in wp-config.php matches the new prefix.
The Scenario: A plugin on your site has a known SQL injection vulnerability. The attacker’s automated exploit assumes
wp_users. Your tables are namedx7k_users. The exploit returns nothing and moves on.
How do I update WordPress security keys?
WordPress uses secret keys and salts stored in wp-config.php to secure cookies and sessions. The default installation puts placeholder strings there. Replace them with real random values.
Generate fresh keys here: https://api.wordpress.org/secret-key/1.1/salt/
Open wp-config.php and replace the entire block of define('AUTH_KEY', ...) lines with the freshly generated ones.
Doing this immediately invalidates all existing login sessions. Anyone who had an active session — including anyone who had unauthorized access — will be logged out.
How do I enable two-factor authentication on WordPress?
Two-factor authentication (2FA) is the single most effective protection against credential theft. Even if an attacker has your password, they can’t log in without the second factor.
Recommended plugins for 2026:
- WP 2FA — straightforward setup, TOTP (Google Authenticator, Authy) and email codes
- Two Factor (by Plugin Contributors) — lightweight, official WordPress plugin repository
- Wordfence — includes 2FA as part of its broader security suite
Set it up for every account with editor access or higher. Subscriber accounts are lower risk, but admin and editor accounts are the target.
The Scenario: Your password appears in a data breach. The attacker tries it on your WordPress login. Without 2FA, they’re in. With 2FA, they hit a wall — they’d need your phone to proceed. The breach becomes a non-event.
How do I hide the WordPress login page from bots?
The default login URL is yoursite.com/wp-login.php. Bots know this and hit it constantly. Moving it to a non-standard URL cuts automated login attempts to near zero.
Plugin: WPS Hide Login — lets you set any custom URL (e.g., /site-access). The default wp-login.php returns 404.
Password-protecting wp-admin with .htaccess adds a second layer — even authorized users see a server-level password prompt before reaching the WordPress login form:
# .htaccess in wp-admin/
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/.htpasswd
Require valid-userGenerate the .htpasswd file with htpasswd -c /path/to/.htpasswd username.
How do I enable WordPress error logging?
Error logs expose a lot — failed database queries, missing file requests, PHP errors from plugins. They’re valuable for spotting suspicious activity before it becomes a breach.
Add this block to wp-config.php:
define('WP_DEBUG', true);
if (WP_DEBUG) {
define('WP_DEBUG_DISPLAY', false);
@ini_set('log_errors', 'On');
@ini_set('display_errors', 'Off');
@ini_set('error_log', '/path/to/error.log');
}Replace /path/to/error.log with a path outside your web root — a directory not accessible from the browser. If you put it inside /public_html, the log is publicly readable.
The Error Log Monitor plugin displays the log as a dashboard widget and can email you digests. Useful if you don’t want to SSH in to check logs manually.
Which security plugins are worth installing?
You don’t need five security plugins. Pick one comprehensive one and configure it properly.
Wordfence Security — the most widely deployed. Malware scanner, login protection, firewall rules, 2FA, and real-time traffic monitoring. The free tier covers most sites. It compares your core files against the official WordPress repository and flags any modifications.
Sucuri Security — strong on monitoring and incident response. Logs every file change, failed login, and plugin update. The paid version adds a CDN-level web application firewall (WAF) that blocks attacks before they reach your server.
iThemes Security (now Solid Security) — good for hardening defaults quickly. Has a one-click “Security Check” that applies sensible settings automatically.
The Scenario: Wordfence sends you an email at 2am: “Core file modified —
wp-includes/functions.phphas changed.” You didn’t deploy anything. Someone injected a backdoor into a core file. You restore from backup, update everything, and regenerate your security keys. Wordfence caught it before the backdoor was used.
How do I check who has logged into my WordPress server?
At the Linux shell level, last shows every login to the server along with IP addresses:
last -iTo see login history for a specific user over a longer window, grouped by IP:
last -if /var/log/wtmp.1 | grep USERNAME | awk '{print $3}' | sort | uniq -cReplace USERNAME with your actual shell username. Any unfamiliar IP is worth investigating before assuming it’s benign.
To find files modified in the last 3 days (useful for spotting injected files):
find . -type f -mtime -3 | grep -v "/Maildir/" | grep -v "/logs/"Change -mtime -3 to -mmin -60 to see files modified in the last 60 minutes.
Summary
- Username: Delete
admin, create a randomized username - Version hiding: Remove the
wp_generatormeta tag and deletereadme.html - File permissions: 755 directories, 644 files, 600 for
wp-config.php - XML-RPC: Disable it unless Jetpack requires it
- 2FA: Enable on every account with editor access or above
- Login page: Move with WPS Hide Login, optionally
.htaccess-protectwp-admin - Security keys: Regenerate them — it logs out all active sessions
- Monitoring plugin: Wordfence or Sucuri, configured and actually checked
FAQ
Do I need to do all of these? The high-impact ones are: update regularly, change the username, enable 2FA, install Wordfence, and disable XML-RPC. The rest add layers — do them when you have time. Partial hardening is still much better than none.
How often should I update WordPress? Immediately for security releases (WordPress marks them clearly). For major version updates, give it a week for plugin compatibility to catch up, then update. Outdated installs are the number one vector.
Can I use a managed WordPress host instead of doing this myself? Yes. Hosts like WP Engine, Kinsta, and Flywheel handle most of this at the infrastructure level. If you’re self-hosting on a VPS, all of this is your responsibility.
Is two-factor authentication really necessary? Yes. Password breaches are constant. Credential-stuffing attacks try known email/password combos from other breaches against WordPress logins. 2FA stops this cold — the password alone isn’t enough.
What should I do if my WordPress site is already hacked? Don’t just delete the visible malware — backdoors are usually planted separately. Best path: restore from a clean backup, update everything, change all passwords and security keys, and run Wordfence’s full scan on the restored version before going live again.
What to Read Next
- How to Set Up SSH Keys for GitHub
- Burner Emails: When and How to Use Them
- Install DuckDuckGo on Any Device
