My WordPress site has been hacked: what to do, in 10 steps

If you are reading this in an emergency, start here: delete nothing, reinstall nothing yet. The most expensive mistake in the first half hour is not cleaning badly — it is erasing the evidence before you understand how the attacker got in. Without that, you will clean, and you will be reinfected within days, usually through the same door.

This guide gives the ten steps in order, with what to check at each one. It is written for someone who runs their own site without being a systems administrator. Allow two to four hours for a simple case; longer if the site is large or the hosting is shared and slow.

The symptoms that brought you here are probably one of these: the site redirects visitors to an unknown page, Google shows "This site may harm your computer", pages in a foreign language have appeared in search results, admin access is refused, or your host has suspended the account. All lead to the same protocol.

Contents

• Step 0: the first five minutes
• Step 1: back up the infected state
• Step 2: cut access without breaking everything
• Step 3: take back control of the accounts
• Step 4: end every open session
• Step 5: find what was modified
• Step 6: hunt for backdoors
• Step 7: clean or restore
• Step 8: close the way in
• Step 9: get the Google warning lifted
• Step 10: the duty people forget — personal data
• Stopping it happening again

Step 0: the first five minutes

Three reflexes, in this order.

Touch nothing from the machine that might be compromised. If your own computer is infected, changing passwords from it hands them straight to the attacker. Use a different computer, or a phone.

Do not erase the logs. Your host's access logs (often 7 to 30 days of retention) are the only thing that will tell you how they got in. Request them right away if your plan does not give you access: they expire.

Tell your host. Many have a dedicated team, and more importantly: if your server is sending spam, they will cut you off without notice. Having informed them changes that conversation.

Step 1: back up the infected state

Counter-intuitive, and essential. Take a complete copy — files and database — of the current, infected state, and keep it offline.

Three reasons: it is your safety net if the cleanup breaks the site; it is the only usable trace for understanding the attack; and if personal data is involved, it is what lets you document what happened (see step 10).

Name it clearly, with the date and the word "INFECTED", and never restore it by accident.

Step 2: cut access without breaking everything

If the site is serving redirects or malicious content, every extra visitor makes your situation worse in the eyes of Google and your host.

The right move is a maintenance page at server level, not deleting the site. You keep control of the content, visitors see an honest message, and search engines receive an HTTP 503 (temporary unavailability), which does not destroy your rankings — unlike a site returning errors for days.

Step 3: take back control of the accounts

Change every password, from a clean machine, in this order: hosting, FTP/SFTP, database, WordPress administrator accounts, associated email. A single omission is enough to start over.

Then open the WordPress user list and look for what should not be there: an administrator you do not recognise, a recently created account, or an existing account whose role has been raised to administrator. Do not delete them immediately — note their email address and registration date first; that is useful information about the way in. Then demote or delete.

Also check keys and access tokens: API keys, application passwords, connections to third-party services. These are the classic leftovers of a cleanup, and they stay valid after a password change.

Step 4: end every open session

Changing a password does not log out someone already signed in: their session cookie stays valid. An attacker with an open session keeps it.

The fix is to regenerate WordPress's security keys (the "salts") in wp-config.php. WordPress provides an official generator for these values. Replacing them invalidates every existing session at once, including yours: you will have to sign in again, and so will the attacker — except they no longer have the password.

Step 5: find what was modified

The goal is to separate what is yours from what was added.

WordPress core is verifiable. Core files have official checksums published by the project: any difference flags a modified file. Most scanning tools perform this comparison automatically — it is the most reliable check you have, because it does not rely on a list of virus signatures but on an exact reference.

Where to look first: wp-config.php, the root .htaccess (and those in subfolders), index.php, the wp-content/uploads folder — no .php file has any business living there — and wp-content/mu-plugins, which loads code automatically without ever appearing in the plugin list.

Sorting by modification date is your best ally: list the files changed in the days before the incident. A theme file modified on the day it all started, when you touched nothing, gives you your starting point.

Step 6: hunt for backdoors

This is the step people skip, and it is the one that explains reinfections.

A backdoor is a piece of code that lets the attacker return even after cleanup. It survives a password change, and often an update. The usual places:

• A plugin or theme you never installed — check inactive themes too, which are rarely inspected.
• A scheduled task that reinstalls the malicious code. List WordPress's scheduled tasks and look for names that match nothing you know.
• A quiet administrator account, created several days before the visible incident.
• Code injected straight into the database, often in the options table or in posts.

As long as the backdoor is there, every cleanup is temporary. If you are unsure, this is the moment to call a professional: that is not a failure, it is a cost decision.

Step 7: clean or restore

Two routes, and the choice hinges on one question: do you have a backup from before the infection?

If yes, restore it — but know that restoring alone is never enough. It puts the site back exactly as it was, including the flaw that let them in. You must restore and then apply step 8 immediately, before putting the site back online. A restore without a fix is a countdown.

If no, clean layer by layer: replace WordPress core with a fresh official archive, reinstall every plugin and theme from their official source rather than patching files one by one, and keep only wp-content/uploads by hand — after purging it of every executable file.

A word on backups, since they are the pivot of this step: a backup you have never tested is not a backup, it is an intention. The day of the incident is the worst possible moment to discover it was incomplete.

Discover AIFORYA Sauvegarde Intelligente

Step 8: close the way in

Cleaning deals with consequences. This step deals with the cause, and it is the only one that prevents a repeat.

• Update everything: core, plugins, themes, and your PHP version. A PHP version that no longer receives security fixes is a decision, not a fate — your host almost always lets you change it.
• Delete what you do not use. Every inactive plugin and unused theme is still code on disk, therefore exploitable. A deactivated plugin is not an absent plugin.
• Review user permissions. An author does not need to be an administrator. Most compromises run through an account that had more rights than it needed.

Step 9: get the Google warning lifted

If your site has been flagged, cleaning is not enough: the warning stays until you request a review.

In Search Console, open the security issues section. It states the type of compromise detected and often gives example URLs — use them to check you have missed nothing. Then request a review, describing what you fixed: a precise request clears faster than a vague one.

Expect a few days. Only request the review once you are genuinely clean: a rejection lengthens the delay.

While you are there, check your Search Console property owners: an attacker who adds themselves as an owner keeps visibility on your site long after the cleanup.

Step 10: the duty people forget — personal data

If your site held customer accounts, orders, form submissions or a mailing list, a hack is not only a technical incident: it is potentially a personal data breach.

In Europe, the GDPR requires the controller to notify the competent supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the individuals concerned — and to inform those individuals directly where the risk is high. The clock starts when you become aware, not when everything is fixed.

This paragraph is not legal advice and does not replace your data protection officer or your counsel. What matters: do not file this away as purely technical without asking the question, and document what you observed and did — which is exactly what the infected-state copy from step 1 is for.

Stopping it happening again

A site cleaned without any change in practice is a site that will be taken again. Three measures cover the vast majority of real cases, and they cost almost nothing.

Two-factor authentication on privileged accounts. This is the measure that makes password theft — still the most banal way in — useless.

Discover AIFORYA two-factor authentication (free)

Login page protection. Attempt limiting, blocking after repeated failures, watching addresses that keep trying: automated attacks are dumb and massive, and they stop at a door that counts.

Discover AIFORYA login security (free)

File integrity monitoring. This is the difference between finding the incident yourself within hours and learning about it from a customer or a Google warning three weeks later. The cost of a hack is not proportional to its technical severity: it is proportional to how long it went unnoticed.

Discover AIFORYA Sécurité IA

The four mistakes that cost the most

1. Deleting everything and starting over without understanding the way in. You lose the information, and the flaw stays.
2. Restoring a backup and going straight back online. The flaw is restored along with the rest.
3. Changing passwords without invalidating sessions. The attacker stays signed in.
4. Cleaning only what is visible. The visible redirects are the symptom; the backdoor is the disease.

FAQ

1. How long does it take to clean a hacked WordPress site? Two to four hours for a simple case with a clean backup. A day or more without one, or if the infection is old and has spread into the database. The longest part is almost never the cleaning: it is finding the way in.

2. Can I just reinstall WordPress over the top? That replaces core files, which helps, but touches neither plugins, themes, the database, nor files dropped into uploads — where most backdoors hide. It is a step, not a solution.

3. My host says it is my fault. Is that true? On shared hosting, the origin can also be a neighbouring site or a server-side flaw. That said, in the vast majority of observed cases the entry point is an outdated component or a weak password — that is, something within your control. Ask for the access logs: they settle it better than the argument does.

4. Should I tell my visitors? If personal data may have been exposed, the question is not only commercial but regulatory: see step 10. Otherwise, transparency is almost always cheaper than silence discovered later.

5. How do I know it is really over? Three signals: core files match the official checksums again, no unknown scheduled task remains, and nothing reappears after several days. The third matters most — reinfection usually happens within the week.

6. Can it happen again? Yes, if the cause was never addressed. No, in practice, if you did step 8 and put two-factor authentication, login protection and integrity monitoring in place. Automated attacks look for easy targets; they move on.

To go further on prevention rather than repair, read our guide to securing WordPress against automated attacks.