After a WordPress Hack: Clean It, Update Everything and Set Up Wordfence Properly

A proper Wordfence setup is one of the last steps after a WordPress hack, not the first. Installing a security plugin on a site that still has a backdoor in it gives you a green dashboard and a false sense of safety. The order I follow is: confirm the site is actually clean, take a backup of that clean state, bring WordPress, plugins and themes up to date without breaking anything, and only then configure Wordfence so it protects the site from the moment WordPress starts loading. This post is that playbook, from a cleaned site to a hardened one.

If you are still in the middle of the incident itself, start with what to do when a WordPress site is hacked, which covers containment, backdoor hunting and the Google review. This post picks up where that one ends.

Step 1: Confirm the site is actually clean

First I re-run the integrity checks: every core file and wordpress.org plugin should match its published checksum, and whatever checksums cannot cover gets reviewed by hand.

# Core files against the official checksums for your installed version
wp core verify-checksums

# Every plugin from the wordpress.org directory
wp plugin verify-checksums --all

# Anything executable where it should not be
find wp-content/uploads -type f -name "*.php"
ls -la wp-content/mu-plugins/

Both checksum commands should finish without warnings. Premium and custom plugins have no public checksums, so I replace them with a fresh download from the vendor rather than trusting what is on disk.

Two more things I check at this stage, because they matter for the Wordfence step later: any existing .user.ini or .htaccess file in the web root, and any auto_prepend_file setting in them. Malware uses exactly the same PHP mechanism that the Wordfence firewall uses, to load a file before WordPress runs. If there is already an auto_prepend_file pointing somewhere you do not recognise, that is a backdoor, not a feature.

Step 2: Take a backup of the clean state

This backup is your fallback during updates and your baseline if the site is ever reinfected. Files and database, stored off the server, somewhere an attacker with access to the hosting account could not have reached.

wp db export clean-$(date +%F).sql
tar -czf clean-files-$(date +%F).tar.gz --exclude=wp-content/cache .
# then copy both somewhere that is not this server

Step 3: Update WordPress safely after malware removal

Hacked sites are often behind on updates, sometimes by years. Jumping everything to the current release at once on the live site is how a cleanup turns into a white screen. I do it on a staging copy first, in a fixed order.

1. Check the PHP version. Run wp --info or look under Tools → Site Health → Info → Server. If the host is on an old PHP branch, check that the current WordPress release and your plugins support the version you plan to move to before changing it.
2. Review plugins and themes. wp plugin list --update=available shows what is behind. For each plugin, check it is still maintained and compatible with the current WordPress release.
3. Replace abandoned and nulled plugins. A plugin that has not been updated in years, or has been closed on wordpress.org, is a risk even if it is currently clean. A nulled premium plugin has to go, full stop; buy the real one or find an alternative.
4. Update plugins and themes, then test.
5. Update core, run any database update, then test again.

# See what would change without changing anything
wp plugin update --all --dry-run

# Plugins and themes first
wp plugin update --all
wp theme update --all

# Then core and its database migration
wp core check-update
wp core update
wp core update-db

On large, old sites I update plugins one at a time rather than with --all, so when something breaks I know which plugin did it. After each round I test forms, checkout, login and search. If an update does cause a fatal error, the PHP error log on staging tells you which plugin and which line. When staging is clean and working, I repeat the same sequence on production, with the Step 2 backup ready.

Step 4: Install Wordfence and optimise the firewall

With a clean, current site, now Wordfence goes on. Install it from the plugin directory (wp plugin install wordfence --activate), register the free licence key it asks for, and then go straight to the firewall.

Out of the box, the Wordfence firewall runs in Basic WordPress Protection mode. It loads as a normal plugin, which means WordPress core and every plugin that loads before it have already run by the time it looks at the request. The dashboard shows a prompt to optimise the firewall; accepting it switches to Extended Protection. That works by setting PHP’s auto_prepend_file directive to a wordfence-waf.php file in your site root, so the firewall inspects every request before any WordPress code runs, including direct requests to vulnerable plugin files.

During the optimisation, Wordfence asks which server configuration you are on and offers to download a backup of the file it is about to change. Pick the right configuration and take the backup. What it changes depends on the setup:

• Apache with mod_php — it adds the directive to .htaccess.
• PHP-FPM or FastCGI, including Nginx — it writes a .user.ini file. PHP caches .user.ini settings, so it can take a few minutes before the firewall status changes to Extended Protection.

The caveat I run into most is PHP-FPM behind Nginx on a VPS. Nginx does not read .htaccess, and some setups do not honour .user.ini either. If the status still says Basic Protection after a while, set the directive in the PHP-FPM pool configuration yourself and reload PHP-FPM:

; in the site's PHP-FPM pool file, e.g. /etc/php/<version>/fpm/pool.d/example.conf
php_admin_value[auto_prepend_file] = /var/www/example.com/wordfence-waf.php

On Nginx I also add a location rule denying dotfiles so .user.ini cannot be downloaded. And note that the path in auto_prepend_file is absolute. If you later move the site to a different directory or server, update it, or PHP will fail on every request because the file it is told to load no longer exists.

Step 5: Let Wordfence learning mode run

After installation, the firewall starts in Learning Mode, by default for one week. It watches normal traffic, including your admin actions, and allowlists requests it would otherwise block, so page builder saves or form submissions do not trip the rules later. After the learning period it switches itself to Enabled and Protecting.

Use the site normally during that week: edit a page, save plugin settings, submit a form. You can also switch the firewall to enabled immediately and add allowlist entries if something legitimate gets blocked. Either way, check Firewall → All Firewall Options afterwards to see what was allowlisted and make sure nothing odd is in there.

Step 6: Wordfence settings after a hack: scans

Once, straight after cleanup, I run a High Sensitivity scan. It is slower and produces more false positives, which is exactly what you want on a site that was just compromised. Also enable the option to scan files outside the WordPress installation if other code lives in the same account. Go through every result. Anything you mark as ignored should be something you have actually looked at.

After that, I switch back to the Standard scan for scheduled scans, so the site is not doing heavy scanning every day and the alerts stay meaningful. On a previously hacked site, an alert about a modified core file or a new PHP file in uploads is often the first sign of a missed backdoor.

Step 7: Login security, 2FA and brute force limits

Stolen or guessed passwords are a common way back in, so I configure this part carefully.

• Two-factor authentication — under Login Security, require 2FA for the administrator role, and for editors or shop managers too if they can publish or see customer data. Every admin sets it up with an authenticator app and saves their recovery codes somewhere safe.
• reCAPTCHA — Login Security can add reCAPTCHA v3 to login and registration forms. It needs keys from Google; test that real users can still log in afterwards.
• Brute force protection — set a low number of failed logins and forgotten-password attempts before a lockout, and turn on immediate lockout for invalid usernames. Add admin and any other obvious names to the list of usernames that trigger an immediate block, as long as no real account uses them.
• Leaked passwords — enable the option that stops admins from using passwords known from data breaches.
• Rate limiting — the defaults are reasonable. I tighten the limits for crawlers and for 404s, which catch vulnerability scanners probing for plugin files, and leave verified search engine crawlers alone so SEO is not affected.

Step 8: Alerts, and free versus premium

In the global options, set the alert email to an address someone actually reads, not the default admin address from when the site was installed. I keep alerts for critical scan issues, admin logins from new devices, and Wordfence being deactivated. That last one matters: an attacker who gets admin access often disables security plugins first.

The difference between free and premium is mostly timing. The free version gets new firewall rules and malware signatures around 30 days after premium customers. Premium also adds a real-time IP blocklist and country blocking. Free is often enough for a small, well-maintained site. For a store, or a site already hacked once, that 30-day gap is when newly disclosed plugin vulnerabilities get exploited, so I usually recommend premium.

Do not stack security plugins, but do pair with Cloudflare

One security plugin per site. Two plugins each running a firewall, login limiter and scanner conflict, add load to every request, and make it hard to tell which one blocked a legitimate user. If the site already has another security plugin, I remove it cleanly, including any .htaccess rules or prepend settings it left behind, before setting up Wordfence.

A network-level firewall is a different layer, and it pairs well. Cloudflare’s WAF blocks a lot of junk before it reaches your server; Wordfence sees what happens inside WordPress. If the site is behind Cloudflare, configure how Wordfence gets visitor IPs so it reads the real client address rather than a Cloudflare IP, otherwise lockouts and rate limits hit Cloudflare’s edge instead of the attacker. Wordfence has a setting for this; fixing it at the web server level is better still. I set up the Cloudflare side as part of Cloudflare setup, and the WordPress side as ongoing WordPress security work.

Keeping it clean: updates, backups and monitoring

Routine maintenance is what stops the site drifting back into the state that let the attacker in.

• Automatic updates — WordPress applies minor core releases automatically by default; leave that on. For plugins from reputable developers I enable auto-updates too (wp plugin auto-updates enable --all), and keep manual updates, tested on staging, for the few plugins that have broken things before.
• Off-server backups — daily database backups and regular file backups, stored with a different provider, with restores tested now and then.
• Monitoring — uptime monitoring, Search Console security alerts, and the Wordfence emails. Someone has to read them.
• The rest of the hardening — disabling the file editor, least-privilege user roles and the other items in my WordPress security checklist.

This whole process, from verifying the cleanup through updates, Wordfence configuration and handover, typically takes a few hours on a standard site, longer if the update gap is large or plugins need replacing. If the site is still infected, start with my WordPress malware removal service, which ends with exactly this hardening. If updates broke something along the way, that is WordPress bug fixing, billed at $20/hour for small jobs.

Frequently asked questions