My WordPress Website Has Been Hacked: An Emergency Recovery Guide for UK Businesses

If you have just found out your WordPress site has been hacked, this guide walks through the eight steps we use to move from initial panic to a fully recovered site. It covers what needs technical access you may not currently have, and how to make sure the same attack cannot succeed again next month.

Our security team recovers hacked WordPress sites for UK SMEs regularly, and although each one has its own specifics, most of them follow a fairly narrow pattern and trace back to one of a small handful of root causes. That means recovery, while it needs to be done properly, is a fairly predictable process rather than a mystery to be untangled from scratch.

What to do before you touch anything

Before doing anything else, it is worth resisting the reflex to start deleting files or reinstalling WordPress before confirming what has actually happened. Overwriting the evidence too early makes the original entry point almost impossible to find later, and missing the entry point is one of the main reasons a freshly-cleaned site ends up reinfected within days. Focus on these four things and leave the rest alone until you are ready:

1. Confirm that the site really has been compromised, rather than misbehaving because of a display glitch or a DNS issue.
2. Take a full snapshot of the current state exactly as it is.
3. Write down every symptom you can see, including defaced pages, unexpected redirects, admin users you do not recognise, and spam pages appearing in search results.
4. If anyone on your team has admin access, ask them to change their WordPress and hosting passwords straight away.

Step 1: Confirm you have actually been hacked

Not every unusual behaviour on a WordPress site is a compromise, and it is worth confirming what you are looking at with two independent signals before you commit to a full recovery. The signals most often present when a site has genuinely been hacked include:

• A search for “site:yourdomain.com” on Google returning pages you did not create, which are often pharmaceutical, gambling or spam pages.
• The homepage redirecting to an unfamiliar URL when opened in a private browsing window, since attackers commonly exclude logged-in users from the redirect and only trigger it for anonymous visitors.
• A security notice appearing in Google Search Console.
• An admin user visible in Users → All Users that nobody in the business created.
• An email from your host reporting that malware has been detected on the account.

If none of the above applies, what you are looking at may be a plugin conflict or a caching issue rather than a compromise, in which case our guide to common WordPress errors is likely to be more useful than continuing with this recovery process.

Step 2: Take the site offline properly

Once you have confirmed a genuine compromise, the next task is to take the site offline in a way that preserves your search engine rankings. The correct approach is a maintenance-mode page returning HTTP 503 rather than a hard block that returns HTTP 500, because a 503 signals to search engines that the site is temporarily unavailable and leaves your rankings intact, whereas a 500 tells them the site is broken and, over time, causes real ranking damage.

If you do not have the technical access to configure this cleanly, a temporary maintenance-mode plugin will do the job, and most managed hosting providers can put a coming-soon page in place at the server level within a few minutes of being asked. What is important is that the compromised site should not be left publicly accessible while you recover, because every hour it remains reachable is an additional hour of reputational damage and, potentially, ICO exposure if user data is at risk.

Step 3: Preserve evidence and take a forensic backup

Before cleaning anything, take a complete backup of the current state and save it somewhere that cannot be overwritten by later work, such as an external drive or a separate cloud folder. This backup is not intended for restoration; it is forensic evidence that you will need in step 4 in order to identify how the attacker got in. A useful forensic backup includes all WordPress files and folders, the database exported in full, and the last 30 days of web server logs covering both access and error entries.

Step 4: Identify the entry point

Identifying the entry point is one of the most important steps in the whole process, and it is also the one most commonly skipped when the pressure is on to get the site back online. Skipping it tends to mean the same attacker returns through the same hole within days, so it is worth taking the time to look properly. The things to look for include:

• Recently modified files, which on a Unix host can be listed with “find ./ -mtime -30 -type f”. Anything inside wp-includes or wp-admin should not have changed recently, so any changes in those directories are worth investigating.
• Suspicious PHP files inside wp-content/uploads, which is a directory where PHP execution should be blocked entirely.
• New admin users created recently, particularly with generic-looking email addresses.
• Access log entries showing POST requests to wp-login.php, xmlrpc.php or wp-admin/admin-ajax.php from a single IP in unusual patterns.
• Any plugin or theme that has not been updated in six months or more, especially if the version installed has known vulnerabilities listed against it.

In the vast majority of the UK SME sites we recover, the root cause turns out to be one of three things: an unpatched plugin with a publicly known vulnerability, a reused password on an admin account without MFA, or an exposed xmlrpc.php endpoint being brute-forced. If your investigation surfaces one of those, you have almost certainly found the entry point.

Step 5: Clean the malware

Once you know how the attacker got in, the next step is to remove what they left behind. That usually involves removing any admin users you did not create, deleting every suspicious file added since the compromise, restoring wp-includes and wp-admin from a clean copy of the WordPress core (downloaded fresh from WordPress.org and used to replace those two folders wholesale), reinstalling every plugin from the WordPress repository rather than simply updating it, reinstalling your theme from a clean copy, scanning the database for suspicious rows in wp_options, wp_posts and wp_users, and resetting the WordPress salts in wp-config.php.

This is the step at which DIY recovery most commonly goes wrong, because if a single malicious file is missed the site tends to be reinfected within days. Professional malware removal typically combines signature-based scanners with manual review of every modified file, and if there is any doubt about whether every planted file has been found it is generally worth pausing here and getting help before bringing the site back online.

Step 6: Reset every credential

Every credential connected to the site should be treated as compromised, which means resetting the WordPress admin passwords for every user (not only your own), the database password in both wp-config.php and the hosting control panel, the FTP and SFTP passwords, the hosting control panel password itself, any API keys stored in plugins for payment gateways, email services or analytics tools, and any secrets held in .env files if you have them. Multi-factor authentication should then be enabled on every admin account without exception, and if a plugin or host makes this awkward to configure, replacing that tool with one that supports MFA properly is generally the right response.

Step 7: Restore, test and harden

The site should come back online in stages rather than all at once. Restore access to your team first, using either an IP restriction or a maintenance-mode bypass, and use that window to test every core function including checkout, contact forms and login. Once you are satisfied that the site is behaving normally, remove the maintenance page and monitor closely for 48 hours, watching access logs for repeat attempts from the original attacker’s IP range.

At the same time, harden whatever let the attack succeed in the first place. If the entry point was an unpatched plugin, subscribing to a vulnerability alerting service and setting a written policy for how quickly security updates are applied will materially reduce the chance of a repeat. Our WordPress security checklist covers the seven things every UK business should have in place as a baseline.

Step 8: Notify anyone who needs to know

If the compromised site processed personal data, whether through customer accounts, contact form submissions or ecommerce orders, you may have an ICO notification obligation. Under UK GDPR, a business has 72 hours from becoming aware of a personal data breach to report it if there is a risk to individuals, and it is worth taking that obligation seriously and consulting a data protection specialist if there is any doubt about whether it applies.

Depending on the nature of the site, you may also need to notify Google (by submitting the site to Search Console for a security review), your payment processors (if any card data may have been exposed), and any customers whose data was directly accessed.

When to stop DIY and call in an expert

A DIY recovery is realistic if you have full hosting access, are comfortable working with SFTP or SSH, can read PHP well enough to spot obvious backdoors, and have the time to work carefully through each step without rushing. If any of those things are not the case, or if the site handles payments or personal data, professional help is usually the more sensible option, since the cost of an hour of expert time is almost always lower than the cost of missing a backdoor and having to recover the site again a week later.

One recent example from our own case work is a UK client whose site had been reinfected three separate times before we were called in. The root cause turned out to be a single plugin dating from 2019 with a well-known unauthenticated file upload vulnerability, and two hours of forensic work followed by an hour of clean recovery and ongoing maintenance was enough to close the issue for good. The full detail is written up in the case study. Our article on the hidden cost of an unmaintained website sets out why this pattern is so common.