WordPress Hacked — What Now? A Step-by-Step Recovery Guide

The instinctive reaction the moment you realise your site has been hacked is usually the same: delete files at once, remove plugins, try to "clean" something. This usually makes things worse — you destroy the evidence of the attack and you miss the backdoor. The order below is arranged to keep the loss to a minimum.

1. Isolate first, don't delete

The first goal is to stop the damage, not to clean up. Put the site into maintenance mode or block access at server level, so that your visitors aren't exposed to malicious code and search engines don't flag your site as "harmful".

• Take the site offline temporarily (a maintenance page or a server-level access restriction).
• End all administrator sessions and change the passwords — including the dashboard, FTP, database and hosting account.
• If the site takes payments, notify your payment provider.

2. Take a forensic copy of the current state

It may sound excessive, but it is essential: take a backup in its hacked state and put it somewhere separate. This copy serves two purposes — it lets you analyse the vulnerability, and it lets you recover a legitimate file you delete by mistake during cleanup. Never restore this backup to production; it is for examination only.

3. Work out when they got in

To be able to roll back to a clean backup you need to know the date of the attack. Otherwise you'll restore a backup that also contains the malicious code and end up right back where you started. Where to look:

• File modification dates: list the most recently modified files; core files changed on an unexpected date are the first clue.
• Server access logs: suspicious POST requests and admin logins from IP addresses you don't recognise.
• New users: administrator accounts you did not create.
• Scheduled tasks: attackers leave cron entries behind for persistence.

4. Roll back to a clean backup from BEFORE the attack

Once you have the date, what to do is clear: restore a backup from before it. Two things are critical here.

First, you must be sure the backup really is clean. An attack often begins weeks before it is noticed; even "yesterday's backup" may contain malicious code. If your backups are scanned for malware you know which one is clean — that is the difference between guessing and knowing.

Second, restoring means data loss: orders, sign-ups and comments that arrived after the backup date are gone. So before restoring, consider exporting critical records such as orders from the current database.

5. Close the hole — otherwise it happens again

Rolling back to a clean backup only removes the effect ; if the cause is still there, the attacker walks back in through the same door. The most common ways in:

• An outdated plugin or theme: entered by automated scanning for known vulnerabilities. This is the most common cause.
• A weak admin password: broken by brute-force attempts.
• Abandoned plugins: a plugin not updated for years is an open door.
• Shared hosting neighbours: another site on the same server being compromised.

The first job after restoring: update the core, all themes and all plugins, delete the unused ones (deactivating isn't enough — as long as the files are there they can be exploited), change every password and turn on two-factor authentication.

6. Verify that it is clean

The job isn't done just because the site is back up. Backdoors are usually quiet. Run your new backups through a malware scan, review the administrator accounts and scheduled tasks again. If search engines flagged you as a "harmful site", submit a review request.

What not to do

• Don't pay the ransom. Paying doesn't guarantee the data comes back, and it makes you a target again.
• Don't just delete the file you can see. The backdoor is almost always somewhere else.
• Don't reuse the same passwords. The attacker may already have them.
• Don't overwrite your only backup. A new backup taken in a panic can overwrite the clean copy you still have.

Frequently Asked Questions