Your WordPress Site Got Hacked: What to Do, In Order

Finding out your website has been hacked is a bad afternoon. Customers see spam, Google may flag the site, and the hosting company sends an email full of words nobody explains. The good news: the response is a known sequence. Work through it in order and most WordPress compromises are fully recoverable.

This guide is written for the business owner, not the sysadmin. It assumes you own a WordPress site, something is clearly wrong, and you want to know what happens next and in what order.

• Contain first, investigate second. Do not start deleting files before you have a copy of the evidence.
• Cleaning the visible damage is the easy half. The job is finding how they got in.
• A restore from backup without finding the entry point usually means you get hacked again within weeks.
• Almost all WordPress compromises come in through an outdated plugin or theme, or a reused password - not through a clever attack on WordPress itself.
• Reputation recovery with Google and your email deliverability is a separate task from cleaning the site.

The instinct is to delete the bad thing immediately. Resist it for one hour. The moment you start deleting, you destroy the evidence that tells you how the attacker got in, and that evidence is the only thing standing between you and a repeat.

1. Take a full copy of the site as it is right now - files and database, infected and all. This is your evidence snapshot, not a backup you would ever restore.
2. Put the site into maintenance mode if it is serving spam, redirects, or anything that could harm visitors. Protecting customers outranks protecting traffic.
3. Download the server access logs before your host rotates them. These usually expire in days and they are the single most useful artefact you have.
4. Change passwords from a clean device - hosting, WordPress admin, database, FTP/SFTP, and the email account tied to the domain.
5. Revoke and reissue any API keys stored on the site, including payment and email-sending credentials.

One detail people miss: if you change your WordPress admin password but not your hosting or FTP password, and the attacker had file-level access, you have changed nothing. Assume every credential that touched that server is burned.

This is the step that gets skipped, and skipping it is why sites get hacked twice. WordPress core itself is maintained by a large security team and is rarely the weak point. The way in is almost always one of a small number of doors.

Your access logs will usually tell the story. You are looking for POST requests to files that have no business receiving them, requests to plugin paths immediately before the first sign of trouble, and admin logins from countries where you have no staff.

The spam links, the redirect, the strange popup: these are symptoms. Attackers who take the trouble to get in almost always leave a way back. A backdoor is a small piece of code that lets them return even after you clean everything visible.

Backdoors are deliberately boring. They get named things like wp-cache-index.php or hidden at the bottom of a legitimate theme file. Some sit in the database rather than in files. Some are added as a hidden administrator user.

• Compare every core, plugin, and theme file against a clean copy of the same version. Anything that differs is suspect.
• Check the users table for administrator accounts you do not recognise.
• Check scheduled tasks (WP-Cron) for jobs you did not create - a common way to re-infect a cleaned site.
• Check wp-config.php, .htaccess, and the uploads folder. Uploads should contain images, never PHP files.
• Check for modified or unexpected mu-plugins, which load automatically and are easy to overlook.

This is the part where a file-comparison approach beats a scanner. Security plugins catch known malware signatures. A custom backdoor written for your site has no signature, and a clean scan result does not mean a clean site.

There are two legitimate routes and the right one depends on how deep the compromise went and how well you can trust your backups.

A word on backups: restoring from a backup taken after the initial break-in simply restores the backdoor along with everything else. Before you restore, establish when the compromise actually started. That date, not the date you noticed, decides which backup is safe.

Cleaning the site does not automatically undo the reputational damage. Two systems need separate attention.

Hardening is what turns an incident into a one-off. None of this is exotic; it is the basic hygiene most sites never got.

• Remove what you do not use. Every deactivated plugin and unused theme is still code on your server. Delete, do not just deactivate.
• Update on a schedule rather than when something breaks. Most compromises exploit vulnerabilities that were patched months earlier.
• Two-factor authentication on every admin account. This alone removes the entire password-guessing category.
• Audit your users. Contractors and former staff should not keep administrator access.
• Put a firewall in front of the site. A WAF filters malicious requests before they reach WordPress, and bot filtering cuts automated login attempts sharply.
• Disable file editing from the dashboard. A single line in wp-config.php stops an attacker with a stolen login from editing PHP directly.
• Automated off-server backups with a retention window long enough to predate a slow-burning compromise.
• Least privilege. Staff who write posts should be Editors, not Administrators.

define( 'DISALLOW_FILE_EDIT', true );

Sometimes, and it deserves an honest answer rather than a sales pitch. The reason WordPress is targeted so heavily is its scale and its plugin model: a huge amount of third-party code, of varying quality, running on the server with full access.

A statically generated site removes most of that surface, because there is no PHP executing on request and no public database to reach. That is a genuine security benefit. But it is a different tool with different trade-offs, and it is the right answer only when the rest of the fit is right too. If you like your WordPress setup and it earns its keep, hardening it properly is a perfectly sound decision. Migrating purely out of fear, without addressing your password and update habits, moves the problem rather than solving it.