Your WordPress Site Has Been Hacked - Now What?

You've just found out your WordPress site has been hacked. Maybe it's redirecting visitors to a spam site. Maybe Google is showing a "this site may be hacked" warning. Maybe you've spotted admin users you didn't create, or pages full of content you didn't write. It's stressful, but it's recoverable. I've helped businesses in Bath, Bristol, and Wiltshire through exactly this situation - here's a practical guide to what to do, in what order.

Signs Your Site Has Been Compromised

Some hacks are obvious - defaced pages, spam redirects, a Google warning in search results. Others are subtler: a new admin user you didn't create, unfamiliar files in your uploads directory, a sudden drop in search traffic, or your hosting provider emailing about unusual resource usage. If your site is sending spam email, that's another strong signal. The longer a hack goes unnoticed, the more damage it does - to your search rankings, your reputation, and potentially your customers' data.

Step 1: Take the Site Offline

First, limit the damage. Put up a maintenance page or take the site offline entirely so visitors aren't being redirected to spam, served malware, or seeing defaced content. Every hour a compromised site stays live is more reputational damage and more risk to your visitors.

Before you change anything else, take a full backup of the compromised site. Yes, back up the hacked version. You'll need it to investigate what happened and how deep the compromise goes.

Step 2: Find the Root Cause

This is the step that drives everything else. Before you start cleaning or restoring, you need to understand how the attacker got in. Without this understanding, you can't be certain you've addressed the problem, and you'll likely get hacked again pretty soon.

Common entry points:

• Outdated plugins or themes - by far the most common. A single vulnerable plugin is enough. This is closely related to the perils of plugin stacking - the more plugins you run, the larger your attack surface.
• Weak or reused passwords - on admin accounts, FTP, database, or hosting panels.
• Compromised hosting - shared hosting where another site on the same server was the initial target, giving the attacker access to your files too.
• Abandoned plugins or themes - still installed but no longer maintained or receiving security patches.

Your hosting provider's access logs and error logs can often help pinpoint the entry point. File modification dates, unexpected PHP files in upload directories, and database changes all tell a story.

Step 3: Assess the Full Scope

This is critical, and it's where many recoveries go wrong. The root cause tells you not just what happened, but how deep the compromise could go. You need to think about what could have been accessed - not just where you can see obvious evidence of tampering.

If the attacker had WordPress admin access, they could have modified any file WordPress can write to, added backdoors anywhere in the theme or plugin directories, and accessed anything in the database - including customer data. If they had hosting-level access (FTP, SSH, or a control panel breach), the scope widens to every site on that account. If the server itself was compromised, every site on that server could be affected.

This scoping matters because it determines your recovery strategy. A compromised plugin on an otherwise well-maintained site is a different problem from a compromised hosting account with multiple WordPress installs. Think about worst-case access, not just confirmed damage - that's how you make sure you've removed every potential way back in, not just the ones you've found so far.

Step 4: Restore and Recover

With the root cause and scope understood, you can choose the right recovery approach.

Restoring from a clean backup - one from before the compromise - is usually the fastest and most reliable route. You know the backup is clean, you know the codebase is intact, and you can focus on closing the entry point and hardening rather than hunting through every file. This is why good backup practices matter so much (more on that below).

The catch with backup restores is data created since the backup. For a brochure site, that's rarely a problem. For an e-commerce site running WooCommerce, you may have orders, customer accounts, or content changes that happened between the backup date and the compromise. In those cases, you restore the clean codebase and then carefully reconstruct the legitimate data from the compromised database - separating real transactions from injected junk. It's painstaking but it's better than leaving backdoors in place.

If you don't have a clean backup, manual cleanup is harder but possible: replace WordPress core files entirely, audit every plugin and theme directory for files that shouldn't be there, scan the database for injected content and rogue users, and check .htaccess and wp-config.php for modifications. Tools like Wordfence and Sucuri help with scanning, but manual review is often necessary - especially for targeted attacks rather than automated bot compromises.

Step 5: Harden the Site

Once the site is clean and the entry point is closed, harden it so the same thing can't happen again:

• Update everything - WordPress core, every plugin, every theme. If a plugin or theme hasn't been updated in over a year, consider replacing it or removing it.
• Remove what you don't use - deactivated plugins and unused themes are still attackable. Delete them.
• Change all passwords - WordPress admin, database, FTP, hosting panel. Use strong, unique passwords. If the scope extended beyond WordPress, change hosting and server credentials too.
• Add two-factor authentication - on every admin account. Plugins like Wordfence or a dedicated 2FA plugin make this straightforward.
• Review user accounts - delete any you don't recognise. Downgrade permissions where full admin isn't needed.
• Consider a web application firewall - Cloudflare, Sucuri, or Wordfence's firewall can block common attack patterns before they reach your site.

I've written about WordPress performance separately, but there's overlap - a well-maintained, lean WordPress site is both faster and more secure.

Backups: The Safety Net You Need Before This Happens

Good backups turn a disaster into an inconvenience. Daily backups with at least two weeks of retention, stored off-site (not just on the same server), mean you can restore quickly and confidently. Test your backups periodically - a backup you've never restored is a backup you can't trust. If your current setup doesn't include this, fix it now, before you need it.

When to Clean Up vs When to Rebuild

Most hacked sites can be cleaned and recovered. A rebuild is worth considering when: the site has been compromised multiple times and you can't confidently close the entry point; the codebase is a tangle of old plugins and custom code that's too hard to audit with confidence (see plugin stacking); or the site has outgrown WordPress and a custom application would be more secure and maintainable long-term. For businesses in Bath, Bristol, and Wiltshire that rely on their site for leads or operations, that's a practical decision - not just a technical one.

After Recovery: Check Google Search Console

If Google flagged your site, you'll need to request a review in Search Console once the site is clean. Check for manual actions, security issues, and any URLs that were indexed while the site was compromised. It can take a few days for warnings to clear. If the hack injected spammy pages, you may need to remove those URLs or submit updated sitemaps.

If your WordPress site has been compromised and you need help recovering it - or you want to harden your site before it happens - reach out. I do WordPress security and recovery work for agencies and site owners across Bath, Bristol, Wiltshire, and the UK.