My WordPress site has been hacked: what now?

If your WordPress site has been hacked, the first thing you do is: do not touch anything. Do not log in, do not clean up, do not try to repair it yourself. That may sound counter-intuitive. But it is not caution — it is a technical reality: what you do at this point makes the subsequent investigation impossible.

You are probably here with a sinking feeling. The site is gone, defaced, or redirecting visitors to a place they should never end up. If you have already logged in or already tried something, that is not a disaster: from this point onwards, changing as little as possible is what matters. This article explains what happens now and what needs to happen next.

Why intervening yourself makes the problem worse

This is the crux. When an attacker gained access via a vulnerability, they leave traces in the logging. Those traces are needed to establish what the access route looked like. Cleaning up destroys precisely those traces.

What you are left with afterwards is a clean site with an open door. You have removed the symptom and left the cause in place. That explains why reinfection can follow so quickly after a self-repair attempt.

In our practice, an outdated plugin has been the access route in approximately 75 per cent of cases. But “outdated” does not tell you which plugin, which vulnerability, or which version. That precision comes from the traces, not from guesswork after the fact.

What people typically try first and why it does not work

Logging into WordPress. At the time of an active infection, the backend is often no longer accessible. It simply does not work.

Calling the hosting provider. Hosting can manage your server environment, but the infection is in the files and database of your site. That falls outside their scope. They are not negligent when they say they cannot resolve it. It is a matter of where their responsibility ends.

Updating plugins. Understandable, because an outdated plugin is often the access route. But updating does not remove the infection. The code that has already been injected remains in place. Moreover, updating destroys the traces needed to establish what was exploited. Too late for prevention, too early for recovery.

More about what can go wrong with self-removal attempts is covered in the article on WordPress malware removal.

What recovery involves: the process step by step

Even without access to the WordPress backend, recovery is possible in virtually all cases. Via the hosting environment or at server level there is almost always a way in. That is not reassurance to calm you down, but a fact about how recovery technically works.

These are the steps, and what each step should deliver:

Gaining access. To the site and the hosting environment, regardless of whether the WordPress backend is accessible.

Establishing where the infection is. Often it involves injected code in files or changes to the database. This gives a picture of the scope.

Establishing how the attacker gained access. For this, the server logging is examined, among other things. It shows what happened, when, and by which route. If the cause cannot be unambiguously traced from the logs, or if an internal cause cannot be ruled out, additional logging can be set up. This also makes visible whether the problem lies on the user side — for example, an infected computer belonging to someone with administrative access.

Closing the cause. Only after the access route has been established. This is the reason why step 3 comes before the cleanup. Anyone who cleans up first and investigates afterwards is closing a door that may not have been the only one.

Cleanup. Including reinstallation of the WordPress core and cleaning the database and files.

Handover. The site is clean and accessible again.

Structural maintenance. So that the site remains up to date and the vulnerability does not recur.

Recovery is a consideration, not an automatism

Not every infection warrants thorough investigation as the fastest or most sensible route. For a smaller site, exporting the content and republishing on a clean installation may be the better choice. We have done this with a site where the infection kept spreading: exported the content, rebuilt on a clean basis, client back online quickly. Thorough investigation would have been the more expensive and slower route in that case.

The consideration depends on the size of the site, its complexity, what integrations are active, and what the site needs to keep doing. That is precisely where experience matters.

Lead time and what determines it

Most sites are back online within a day. That is experience, not a commitment. What determines the lead time: whether there is an SLA in place, what capacity is available at that moment, the size of the site, the number of pages or products, and whether integrations have been affected. With an SLA, action is taken within four hours in the event of an emergency.

After recovery: what you can expect

At handover the site is clean. Recurrence can never be entirely ruled out.

In practice, reinfection rarely occurs after professional recovery, because the cause and preventive measures are discussed with the client, and structural maintenance follows afterwards. Prevention is a separate chapter, but it begins immediately after recovery. What that involves is explained in How do you secure WordPress preventively?

If customer data has been stolen

If the investigation reveals that personal data has been viewed or stolen, legal follow-up is required. The Information Commissioner’s Office (ICO) is the relevant authority in the United Kingdom. Deadlines, reporting thresholds, and precise obligations depend on the situation and change with the regulations. Consult a solicitor for this.

The full framework around security and recovery is described in WordPress security and recovering a hacked site, including the steps that precede recovery.

The decision is now yours: how long can your site be offline, what are the consequences of a day without availability, and who ensures that updates are maintained and maintenance is structurally secured after recovery? Anyone who has clear answers to those questions also knows what form of support is appropriate.

Frequently asked questions

What should I do first if my site has been hacked? Do not touch anything. Do not log in, do not clean up, do not update plugins. Any action on the site at this point can destroy traces needed to establish the access route. Bring in someone who can carry out the investigation before those traces are gone.

Can I try to remove the infection myself? That is inadvisable, and not only because it is technically complex. Cleaning up yourself destroys the logging that shows how the attacker gained access. Without that knowledge you cannot close the vulnerability, and the infection returns.

Can my site be recovered if I can no longer log in? Yes. Recovery does not need to go through the WordPress backend. Via the hosting environment or at server level there is almost always access available to start the recovery process.

How long does it take before my site is back online? Most sites are back online within a day, but that is based on experience, not a commitment. Determining factors include the size of the site, the severity of the infection, whether integrations have been affected, and whether there is an SLA in place. With an SLA, action is taken within four hours.

Is my site definitively clean after recovery? At handover the site is clean. Recurrence can never be entirely ruled out. Because the cause is established and closed during the recovery process, and structural maintenance follows afterwards, reinfection rarely occurs in practice.

What happens if customer data has been stolen? Legal follow-up is then required. The Information Commissioner’s Office (ICO) is the relevant authority in the United Kingdom. Deadlines and reporting obligations depend on the specific situation and the applicable regulations. Consult a solicitor for the actual advice.

Can my hosting provider resolve this? Usually not. The infection is in the files and database of your site itself, and that falls outside the scope of a hosting provider.