Overview
WordPress powers a significant portion of the web, which makes it a constant target. WordPress security isn’t a one-time task — it’s a configuration baseline you set once and then maintain. The majority of compromised sites I’ve dealt with weren’t victims of advanced attacks; they had an abandoned plugin, a guessed admin password, or world-writable file permissions.
This guide walks you through practical hardening steps for WordPress in 2026, whether you’re running a shared hosting account, a VPS, or a managed environment. Some steps are done inside WordPress itself; others require SSH or file manager access.
If you’d rather skip the manual configuration work entirely, our Managed WordPress Hosting handles server-level hardening, automatic updates, and malware scanning as part of the service.
Prerequisites
- Admin access to your WordPress dashboard
- Access to your hosting control panel (cPanel, Plesk, or SSH)
- WordPress 6.4 or later (some settings differ on older versions)
- A recent backup of your site before making any changes — don’t skip this
- FTP/SFTP client or File Manager access if you’re editing config files directly
Step-by-Step: Hardening Your WordPress Site
Step 1: Update Everything
Before touching any security setting, make sure WordPress core, all plugins, and all themes are fully up to date. Most exploits target known vulnerabilities in outdated software — vulnerabilities that already have patches available.
In your dashboard, go to Dashboard > Updates and apply everything. If a plugin hasn’t been updated by its developer in over 12 months and has known CVEs, consider replacing it.
📝 Note: Premium themes and plugins sometimes need manual updates if they’re not connected to an active license. Check those separately.
Step 2: Use a Strong Admin Username and Password
The default admin username is literally “admin” — and attackers know this. If your account is still named that, create a new administrator account with a different username, log in as the new user, then delete the old “admin” account and reassign its content.
Use a generated password of at least 20 characters. WordPress’s built-in password generator is fine. Store it in a password manager, not a sticky note or your browser’s saved passwords on a shared machine.
Step 3: Enable Two-Factor Authentication
A strong password alone isn’t enough if it leaks in a breach. Add two-factor authentication (2FA) to all administrator accounts.
Install the WP 2FA plugin (free, actively maintained as of 2026). Once installed, go to Users > Your Profile and follow the 2FA setup wizard. Force 2FA for admin roles under WP 2FA > Policies.
Step 4: Limit and Protect wp-login.php
Brute-force attacks against wp-login.php are relentless. There are two things you should do here: rate-limit login attempts and optionally add an extra layer of HTTP authentication.
Install Limit Login Attempts Reloaded and configure it to lock out an IP after 5 failed attempts for at least 20 minutes. This alone stops the vast majority of automated attacks.
For higher-security sites, you can add HTTP Basic Auth in front of the login page. In cPanel, go to Security > Password Protect Directories, select your WordPress root, and enable protection. This adds a browser-level username/password prompt before WordPress even loads.
⚠ Warning: If you use XMLRPC for a mobile app or Jetpack, HTTP Basic Auth on the root directory will break those connections. Protect /wp-login.php specifically instead of the whole directory.
Step 5: Disable XML-RPC If You Don’t Need It
XML-RPC is a remote access protocol that WordPress enables by default. Most sites don’t need it. When it’s enabled, it becomes another attack vector — it allows credential stuffing and, in older setups, amplification attacks using the system.multicall method.
Add this to your .htaccess file (Apache) to block it entirely:
# Block XML-RPC
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>For Nginx, add this inside your server block:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}📝 Note: If you use Jetpack, it requires XML-RPC. In that case, restrict access to Automattic’s IP range rather than blocking it completely.
Step 6: Set Correct File Permissions
Incorrect file permissions are one of the most overlooked issues I see on compromised sites. World-writable files let malicious scripts modify your site’s core files.
The correct permissions for most WordPress installations are:
- Directories:
755 - Files:
644 wp-config.php:640or600
From SSH, you can fix permissions across your entire install with:
# Fix directory permissions
find /home/yourusername/public_html -type d -exec chmod 755 {} ;
# Fix file permissions
find /home/yourusername/public_html -type f -exec chmod 644 {} ;
# Lock down wp-config.php
chmod 640 /home/yourusername/public_html/wp-config.phpReplace /home/yourusername/public_html with your actual document root.
Step 7: Harden wp-config.php
Your wp-config.php file contains your database credentials. There are two quick wins here.
First, move it one directory above your document root if your host allows it. WordPress will find it automatically. This means it’s outside the web-accessible folder entirely.
Second, make sure your security keys and salts are set. If yours still have placeholder text like put your unique phrase here, generate new ones at https://api.wordpress.org/secret-key/1.1/salt/ and replace the corresponding lines in wp-config.php.
Also add this line to block direct PHP execution in config:
define('DISALLOW_FILE_EDIT', true);This disables the theme and plugin editor inside the WordPress dashboard, which is a common post-compromise persistence method attackers use.
Step 8: Install a Security Plugin
A dedicated security plugin handles malware scanning, file integrity monitoring, and firewall rules. Wordfence Security (free tier) or Solid Security (formerly iThemes Security) are both solid options in 2026.
After installing Wordfence, run an initial scan under Wordfence > Scan. Pay attention to modified core files — if wp-includes/functions.php or similar shows as modified when you haven’t touched it, that’s a red flag.
Step 9: Keep Backups Offsite
This isn’t a hardening step exactly, but it’s your recovery plan when hardening fails. Don’t rely solely on your hosting provider’s snapshots. Use a plugin like UpdraftPlus to push daily backups to an external destination (S3, Google Drive, Dropbox). If your site is compromised, you want a clean copy you can restore from independently.
Common Issues and Troubleshooting
Locked out of wp-admin after enabling 2FA
This happens when the 2FA app isn’t synced correctly or the backup codes weren’t saved. Connect via SFTP or File Manager, navigate to /wp-content/plugins/, and rename the WP 2FA plugin folder (e.g. from wp-2fa to wp-2fa-disabled). This deactivates the plugin without needing dashboard access. Log in, then re-enable and reconfigure 2FA properly.
HTTP 403 after modifying .htaccess
A syntax error in .htaccess causes Apache to return 403 or 500 errors sitewide. Access your file via File Manager in cPanel, check the file for mismatched tags or typos, and compare against a known-good template. The WordPress default .htaccess for pretty permalinks starts with # BEGIN WordPress — anything you add should go above or below that block, not inside it.
Wordfence scan shows modified core files after a WordPress update
This is usually a false positive immediately after a core update — Wordfence’s signature database sometimes lags by a few hours. Run the scan again after 24 hours. If files still show as modified, compare them manually against the official WordPress source at https://core.svn.wordpress.org/. Unexpected modifications to wp-includes or wp-admin files that you didn’t make warrant a full malware investigation.
XML-RPC block breaking WooCommerce mobile app or Jetpack
If you’ve blocked XML-RPC globally and a plugin stops working, you need to whitelist specific IPs rather than block everything. For Jetpack, Automattic publishes their IP ranges. Update your .htaccess rule to use Allow from <IP> exceptions inside the <Files xmlrpc.php> block.
Login page still accessible after Password Protect Directories in cPanel
cPanel’s directory protection creates an .htpasswd file and adds an AuthType Basic directive. If it’s not working, check that the .htaccess file in your WordPress root actually contains the auth block and isn’t being overridden by a parent directory’s config. Also confirm the path in the AuthUserFile directive is absolute, not relative.
FAQ
Frequently Asked Questions
What is the most common way WordPress sites get hacked?
Outdated plugins are the leading cause by a wide margin. Attackers scan for sites running vulnerable plugin versions and exploit them automatically. Keep everything updated, remove plugins you’re not using, and check for plugins that haven’t had a security release in over a year.
Do I need a security plugin or is WordPress secure by default?
WordPress core is reasonably secure when kept updated, but it doesn’t include login rate limiting, file integrity monitoring, or a web application firewall out of the box. A security plugin like Wordfence fills those gaps. It’s not optional for any production site.
How do I know if my WordPress site has already been hacked?
Common signs include unexpected admin accounts, strange files in wp-content, your site redirecting to spam pages, or Google Search Console flagging malware. Run a Wordfence scan and check your wp-admin user list under Users > All Users for accounts you don’t recognise.
Should I hide the WordPress login URL?
Renaming wp-login.php is a common recommendation, but I’d consider it a secondary measure rather than a real security control. Bots will find it eventually, and it creates its own problems if you forget the URL or lock yourself out. Rate limiting and 2FA on the default URL are more reliable.
Does Host & Tech's managed WordPress hosting include security features?
Yes. Our Managed WordPress Hosting includes server-level hardening, automatic core and plugin updates, malware scanning, and daily backups. It’s a good option if you want the security baseline handled for you without manual configuration.