Your homepage has been replaced with someone else’s message. Or Google is showing a red “Deceptive site ahead” warning when customers click through. Or your search results are suddenly full of pages selling things you have never sold, or the site redirects to somewhere dodgy, but only on a phone, or only when you arrive from Google.

First, take a breath. A hacked WordPress site feels like a disaster and is almost always recoverable. Your content is nearly always still there. What you need now is a calm order of operations, because the panicked things people do in the first hour (deleting files, restoring the first backup they find, installing three security plugins at once) are what turn a bad day into a bad month.

This is the order I would work in. It is written for a business owner or a site manager, not a security specialist, and every step says what it is for. If you only have ten minutes, do Steps 1 to 3 and then decide whether to call someone, which is covered at the end.

Before you start

You will need access to your hosting control panel, because that is the one login that does not depend on WordPress working. Some steps also use SFTP (a way of connecting to your server’s files with a program such as FileZilla) or SSH. If either of those is new to you, the File Manager in your hosting panel does the same jobs in a browser.

Do all of this from a computer you trust. If the attacker got in because your own laptop has something nasty on it, changing passwords from that laptop gives them the new ones too. If in doubt, use a different device for the password changes in Step 3.

Step 1: Work out whether it really is a hack

Not every strange problem is an attack. A white screen is usually a plugin fatal error, and a broken layout is usually an update gone wrong. Those are fixable in minutes and have nothing to do with a criminal.

These are the signs that point to a genuine compromise:

  • A defaced homepage, or a ransom or “hacked by” message.
  • Google or your browser warning visitors that the site is deceptive, dangerous or may be hacked.
  • Administrator users you do not recognise, or a user list that has changed.
  • Search results showing pages or products you never created, often in another language.
  • Redirects to unrelated sites, particularly ones that only fire on mobile, or only for visitors arriving from a search engine. The attacker is hiding it from you on purpose.
  • Your host emailing you about malware, spam sent from your account, or a suspended site.
  • Files you did not put there, especially .php files inside wp-content/uploads, which should only ever hold images and documents.

One or two of these and you should treat it as a compromise until proven otherwise. If it turns out to be a plugin glitch, you have lost twenty minutes being careful. If it is a hack and you assumed a glitch, you have given the attacker a head start.

Step 2: Take a copy of everything, as it is now

Before you change a single thing, copy the site exactly as it stands: all the files, and the database. Download it somewhere that is not the same server.

This feels backwards. Why back up an infected site? Three reasons. It is evidence: how the attacker got in is usually written into those files and logs, and cleaning destroys it. It is a safety net: if a cleanup step breaks something, you can put it back. And it holds your content, which is the one thing that is hard to recreate. Your hosting panel probably has a one-click backup, and my guide to backing up a WordPress database covers the database half if you need it.

Label the copy “infected, do not restore” so nobody uses it as a clean backup later.

If the site is actively harming visitors, serving malware, showing a phishing page or redirecting people, then take it offline once the copy is made. Your host can usually put up a holding page, or you can ask them to suspend the site briefly. A few hours of “back soon” is much cheaper than a Google blacklisting.

Then tell your host you have been hacked. Do not be embarrassed about it, they see this daily. Many will have server logs, malware scan results and sometimes a clean backup history that you cannot see yourself.

Step 3: Lock the doors

An attacker who has been in once often has more than one way back. Changing passwords closes the ones you know about. Do all of these, not just the WordPress one:

  1. Every WordPress administrator password. Make each one long, random and unique, from a password manager.
  2. Your hosting control panel password. This is the master key.
  3. SFTP, FTP and SSH passwords.
  4. The database password. Change it in your hosting panel, then update the matching line in wp-config.php so the site can still connect. Do this carefully, because a mismatch gives you an error establishing a database connection.
  5. The email account tied to the administrator login. If someone controls that inbox they can reset any password you set.
  6. The security keys in wp-config.php. These are the long random strings WordPress uses to sign your login cookies. Replacing them logs every user out everywhere, including the attacker. WP-CLI does it in one line, wp config shuffle-salts, or you can generate fresh ones from the WordPress secret key service and paste them over the old block.

Then look at Users in the dashboard, filter by Administrator, and delete any account you do not recognise. If you cannot log in at all, the database holds the answer, and changing a password directly in the database gets you back in.

That is the end of the first ten minutes’ work. The attacker’s current sessions are dead and their stolen passwords are useless. They may still have a backdoor, which is the next part.

Step 4: Do not restore a backup blindly

The instinct is to roll back to last week’s backup and call it done. Sometimes that works. Often it quietly does not, for two reasons.

First, a restore puts back the same hole the attacker came through. If the way in was an outdated plugin and you restore a backup that has the same outdated plugin, they are back inside within hours, because bots hit the same weakness again automatically.

Second, you do not know when the infection started. Quiet compromises can sit for weeks before anything visible happens. The backup you restore might already contain the attacker’s files, and now you have “cleaned” the site by reinstalling the malware.

A restore is a perfectly sound move when you know the date the problem began, you have a backup from before it, and you update everything straight afterwards. What is risky is restoring on a guess. If you are not sure, carry on with Steps 5 and 6, which work from what is actually on the server.

Step 5: Find out how they got in

Cleaning without finding the entry point is the most common reason a site is hacked a second time. The way in is almost always one of four things:

  • An outdated plugin or theme with a published vulnerability. By far the most common. Flaws are published in public databases in enough detail to attack, and bots scan for sites on old versions within hours.
  • An abandoned plugin nobody has updated for years, where the flaw will never be fixed.
  • A “nulled” premium plugin or theme, meaning a pirated copy of a paid one. These are a favourite way to plant malware, and free downloads of paid software are rarely free.
  • A stolen or reused password, often from an unrelated breach.

Here is how to look. If you have SSH access and WP-CLI installed, run these from the site’s root folder. Each one only reads; none of them changes anything:

# Compare WordPress core against the official copy. Any file listed here has
# been modified, or is not part of WordPress at all.
wp core verify-checksums

# Same check for every plugin hosted on wordpress.org. Premium plugins and
# anything custom are not covered, so a clean result is not a clean bill.
wp plugin verify-checksums --all

# Who are the administrators? Anyone you do not know is a problem.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# PHP files changed in the last 14 days, skipping the cache folder.
# Adjust the number to roughly when you think it started.
find . -type f -name "*.php" -mtime -14 -not -path "./wp-content/cache/*"

# PHP files inside uploads. There should be none.
find wp-content/uploads -type f -name "*.php"

Without SSH you can do the same by hand in the File Manager, sorting by “last modified” and looking at what changed around the time things went wrong. Pay particular attention to four places attackers like to hide:

  • wp-content/uploads, for any .php file.
  • wp-content/mu-plugins, a folder of “must-use” plugins that run automatically and do not appear on the normal Plugins screen. If you did not create it and it exists, look closely.
  • .htaccess, for redirect rules you did not write.
  • wp-config.php and index.php, for long lines of unreadable code stuffed in at the top or bottom.

Your host’s access logs, if they will share them, show the actual requests made to the site around the time of the attack. A burst of requests to one plugin’s file, followed by a new file appearing, usually tells the whole story. This is the point where many people reasonably decide to hand it over, and there is nothing wrong with that.

Step 6: Clean, then rebuild from known good copies

You can clean an infected file, but you cannot be sure you found every infected file. Reinstalling is more reliable than hunting.

  1. Core. Reinstall WordPress itself from a fresh download. With WP-CLI it is wp core download --force --skip-content, which replaces core files and leaves your wp-content folder alone. Without it, upload a fresh copy over the top from wordpress.org.
  2. Plugins and themes. Delete each one and install a fresh copy, from wordpress.org for free ones and from the vendor’s own site for paid ones. Do not copy files across from the infected install. Remove anything you no longer use, and anything pirated, permanently.
  3. Uploads. Delete any .php file in the uploads folder. Real media stays.
  4. The theme’s functions.php and any custom code. Read it. Injected code is often a single dense line, and it is the most common place for a backdoor to survive a cleanup.
  5. The database. Check for spam posts, hidden administrator users, and links injected into widgets or post content. This is the part where scanners help, but treat their results as a lead rather than a verdict.

If you are tempted to run a scanner plugin and trust it, I would resist that. They are a useful second opinion and they catch a lot of the common infections, but a clean scan does not prove a clean site, and an attacker’s tidy backdoor is designed to look like normal code. A scanner is a smoke detector, not a structural survey.

Once the site is rebuilt, update everything that remains, then check it from a phone, from a search result, and from a private browser window, since that is where the hidden redirects show up.

Step 7: Get Google’s warning removed

If Google flagged your site, cleaning it does not automatically clear the flag. Open Search Console for your site and look at the Security issues report. It lists what Google found. Once the site is genuinely clean, use the option there to request a review, and explain briefly what you fixed. Reviews are not instant, so allow some time, and do not request one until you are sure, because a rejected review costs you time.

Check how your pages look in search too. Search for site:yourdomain.co.uk and scan the results for pages or titles that are not yours. Spam pages the attacker created may need removing and may need their URLs returning a proper “gone” response so they drop out of the index.

Step 8: Tell the people who need telling

If your site collects personal information, customer accounts, order details, enquiry forms or bookings, then a hack may be a personal data breach under UK GDPR. If it is likely to put people’s rights and freedoms at risk, you generally need to report it to the ICO within 72 hours of becoming aware of it, and you may need to tell the people affected. I am a developer, not a lawyer, so read the ICO’s guidance on reporting a breach, and if there is real doubt, ask. The clock matters, which is another reason not to leave it for a week.

For a simple brochure site that holds no customer data, this is much less likely to apply. Do check though, rather than assume.

When to call a developer

Most owners can do Steps 1 to 3 themselves, and that alone limits the damage. After that, I would be honest with myself about whether to carry on. Hand it to someone who does this regularly if:

  • The site takes payments, or holds customer accounts or other personal data.
  • You have cleaned it once and it came back. That means the way in is still open.
  • You cannot find the entry point, or the site is too tangled to rebuild from scratch.
  • You are not comfortable in the file system or the database. A wrong move there causes more damage than the hack did.
  • The site is how the business makes money, and every hour offline is costing you.

This is part of what I do when I fix hacked and broken WordPress sites. I isolate the site, remove the malware, find and close the hole, harden what is left and deal with Google’s warning. Hack cleanups get a fixed quote before I start, and I can work out of hours for genuine emergencies, at a rate we agree up front. If your site is down right now, get in touch and tell me what you are seeing.

There is also a middle option. If the site is old, heavily patched and has been compromised before, a rebuild is sometimes the cheaper path overall. I wrote about how to judge that in repair or rebuild your WordPress site.

Making sure it does not happen again

Once the site is clean, the work that prevents a repeat is mostly dull, which is exactly why it gets skipped:

  • Keep core, plugins and themes updated, and delete the ones you are not using. This stops the large majority of attacks.
  • Put two-factor authentication on every account that can install plugins or edit files.
  • Give each person the lowest role that lets them do their job.
  • Keep backups somewhere other than the web server, enough history to get behind a quiet infection, and test a restore.

The WordPress security hardening checklist goes through all of it in order of effect, and the maintenance checklist turns it into a routine. If you would rather not carry that yourself, that is the job of a maintenance plan: updates tested before they go live, backups that restore, and monitoring that tells me before it tells you.

Common questions

Can I clean a hacked WordPress site with a plugin?

A scanner plugin is worth running as a second opinion and will catch common infections. It will not reliably find a hand-placed backdoor, and it cannot tell you how the attacker got in. Use it to find leads, then rebuild from known good copies as in Step 6.

How did my WordPress site get hacked?

Most often an outdated or abandoned plugin with a known vulnerability, a pirated plugin or theme, or a weak or reused password. It is usually an automated bot scanning thousands of sites for one known weakness, rather than someone targeting you personally.

Will being hacked hurt my Google rankings?

It can, particularly if Google flags the site or the attacker created spam pages. Both are recoverable. Clean the site properly, request a review in Search Console, and remove any spam pages. Do it quickly, because the longer the warning stays up, the more visitors and trust you lose.

Should I just restore my latest backup?

Only if you know when the problem started and your backup predates it, and only if you update everything immediately afterwards. Otherwise you risk restoring the infection or the same weakness. Step 4 explains how to decide.

How long does cleaning a hacked site take?

It varies a great deal. A simple infection on a small site can be sorted quickly, and a site with several backdoors, a large database or customer data to consider takes longer. Anyone promising an exact time before they have looked is guessing.

What to do in the next hour

Make a copy of the site as it is. Change every password, from a device you trust. Delete administrators you do not recognise. Tell your host. Then work out whether you are comfortable going further, or whether this is the moment to ask for help.

If you are reading this with a site that is down or flagged right now, tell me what you are seeing and I will say honestly whether it is a quick job or a bigger one.