Securing WordPress after a hack
A site that's cleaned but not hardened often gets reinfected through the same hole. Here's the security checklist to run right after cleanup to close the door for good.
Cleaning a site without hardening it is like closing a wound without disinfecting it: the attacker already knows the way in, and nothing stops them from coming back. Most reinfected sites are hit through the same hole, a few days or weeks after a sloppy cleanup. To really secure WordPress after a hack, the cleanup is only half the job. Here’s the hardening checklist to run right after, ordered by priority.
First things first: make sure the site is actually clean. If you’re not certain you removed everything, start with the complete guide to cleaning a hacked WordPress, then find and remove every last backdoor. Hardening a site that’s still infected is pointless.
Cut off the entry point: access and credentials
This is the top priority. In the vast majority of cases, the intrusion comes from a stolen credential or a vulnerable plugin. Start there.
Update everything, no exceptions. WordPress core, themes, plugins. An outdated version of a popular plugin is the number one cause of compromise. Go to Dashboard > Updates and bring everything to the latest version. Then turn on automatic updates, at least for the critical plugins.
Remove what you don’t use. Every inactive plugin and theme is still an executable PHP file on your server, so it’s an attack surface. Uninstall (not just deactivate) anything you aren’t using. And above all: immediately remove nulled plugins and themes (pirated premium versions). They almost always contain malicious code. That’s often where the whole thing started.
Strong, unique passwords everywhere. Change the passwords for every admin account, the database, FTP/SFTP, and the hosting login. One password per service, randomly generated, stored in a password manager. A single password reused across sites is enough to compromise the whole set.
Turn on two-factor authentication (2FA). On every admin account, no debate. Even with a stolen password, an attacker can no longer log in. Plugins like WP 2FA, Two-Factor, or the module built into a security plugin do the job in five minutes.
Regenerate the security keys (salts). If credentials leaked, stolen sessions and cookies can stay valid. Regenerating the keys invalidates all current sessions and forces everyone to log in again. Grab a fresh set from the official WordPress generator, then replace the matching block in wp-config.php:
define('AUTH_KEY', 'collez-ici-une-chaine-aleatoire-unique');
define('SECURE_AUTH_KEY', 'collez-ici-une-chaine-aleatoire-unique');
define('LOGGED_IN_KEY', 'collez-ici-une-chaine-aleatoire-unique');
define('NONCE_KEY', 'collez-ici-une-chaine-aleatoire-unique');
define('AUTH_SALT', 'collez-ici-une-chaine-aleatoire-unique');
define('SECURE_AUTH_SALT', 'collez-ici-une-chaine-aleatoire-unique');
define('LOGGED_IN_SALT', 'collez-ici-une-chaine-aleatoire-unique');
define('NONCE_SALT', 'collez-ici-une-chaine-aleatoire-unique');
Apply least privilege. Review the user list (Users > All Users). Delete unknown accounts, those of former contractors, and demote everyone to the minimum role they need. An editor doesn’t need to be an administrator. The fewer high-privilege accounts there are, the fewer targets.
Shrink the surface: login page and brute force
Once the accounts are clean, make life hard for the bots that hammer WordPress login pages around the clock.
Hide the login page. Everyone knows the admin lives at /wp-admin and /wp-login.php. Moving that page to a custom URL cuts off most automated attacks. A plugin like WPS Hide Login does this cleanly: you pick an address like /my-private-access and the old URLs return a 404.
Limit login attempts. Block an IP address after a few failures in a row. It’s the basic defense against brute-force attacks. Limit Login Attempts Reloaded or the equivalent module in your security plugin will do. Set a temporary block after 4 or 5 failed tries, for example.
Lock down the files
An attacker who gets a foothold then tries to write and run code. Take that option away.
Disable the dashboard file editor. By default, an administrator can edit theme and plugin code straight from the interface. If an admin account is compromised, that’s an open door to inject a backdoor in one click. Add this to wp-config.php:
define('DISALLOW_FILE_EDIT', true);
Set file permissions correctly. Permissions that are too open let a malicious process write where it shouldn’t. The classic rule:
# Folders: 755
find . -type d -exec chmod 755 {} \;
# Files: 644
find . -type f -exec chmod 644 {} \;
# wp-config.php: 600 (or 640 if your host requires it)
chmod 600 wp-config.php
wp-config.php holds the database credentials; it deserves the strictest lock your host will accept.
Block PHP execution in uploads. The wp-content/uploads folder should hold media only, never executable code. A backdoor dropped there is harmless if the server refuses to run the PHP inside it. Create an .htaccess file in wp-content/uploads/ (Apache servers):
<Files *.php>
deny from all
</Files>
On Nginx, the equivalent goes in the server config by refusing PHP execution under that path. This measure neutralizes a large share of backdoors, even ones you might have missed during cleanup.
Monitor and be able to roll back
Hardening reduces the risk, it doesn’t remove it. You need to detect fast and be able to restore.
Install a reputable security plugin. Wordfence, Sucuri Security, or Solid Security give you an application firewall (WAF), regular file scans, and alerts when something changes suspiciously. One is enough, don’t stack them. Run a full scan right after install to confirm the site is clean.
Set up automatic, off-site backups. A backup stored on the same server as the site disappears with it in a serious reinfection. Configure regular backups (files + database) sent to external storage: Google Drive, Dropbox, Amazon S3. UpdraftPlus or your host’s solution will do. Check from time to time that a restore actually works; a backup that’s never been tested isn’t one.
The monthly maintenance routine
Hardening isn’t an event, it’s a habit. Fifteen minutes a month is enough to keep a site healthy:
- Apply pending updates (core, themes, plugins).
- Run a full scan with your security plugin.
- Review the user list and delete accounts that no longer belong.
- Confirm a recent backup exists and is properly stored off-site.
- Glance at the login logs to spot any unusual attempts.
If your site had been flagged by Google, keep an eye on its reputation in Search Console until everything settles. The steps are spelled out here: remove the Google warning.
FAQ
Do I really need to change the salts keys after every incident?
Yes, as soon as there’s any suspicion of stolen credentials or sessions. It’s a thirty-second job that logs everyone out and invalidates hijacked cookies. No reason to skip it.
Does a security plugin replace manual hardening? No. A security plugin adds a firewall and monitoring, but it won’t fix a weak password, a nulled plugin, or file permissions that are too open. The two work together.
My site was already cleaned by a provider. Do I still need to harden it? If hardening wasn’t included, yes, and quickly. A cleanup that doesn’t close the entry hole leaves the site exposed exactly as before.
At WP-Detox, we never just strip out the malware: we harden the site in the same job and point you to the exact hole that was used to get in, so it can’t be reused. The scan is free, the cleanup takes about 30 minutes, it’s €149 all-in, with a 30-day reinfection guarantee and a refund if the job fails. If you’d rather not work through this checklist alone, we’ll handle it.