Your WordPress site has been hacked. What to do in the first hour.

Somebody rings us about this most months. It starts the same way. A customer said the site “looks funny”. Google is showing a warning underneath it in the search results. The hosting company has sent an email with the word suspended in it.

Your first instinct will be to start deleting things. Resist it. The order you work in matters more than which security plugin you install afterwards.

Stop it serving to the public

If the site shows spam, sends visitors somewhere else, or Google has flagged it, each extra hour it stays up costs you. Google’s warning takes days to clear after you clean the site, so the sooner you stop the bleeding, the sooner that clock starts.

Put up a holding page. Most hosts give you a maintenance mode, or a way to point the domain at a single HTML file. If yours does not, an .htaccess rule that returns a 503 to everyone but your own IP address will do. A 503 tells Google the outage is temporary and to come back later. A 404 tells it the page has gone for good, which is not what you want.

Do not take the site down by deleting it.

Delete nothing yet

This is the mistake that turns a bad morning into a lost site.

You will want to wipe the infected files and get back online. Until you know how they got in, cleaning the site means it gets hacked again next week through the same hole. We have picked up sites that three different people had “cleaned” three times, each of whom removed the symptom and left the door open.

Before you touch anything, take a copy. Files and database, both, as they stand right now. The copy contains the hack, which is the point: it is your evidence, and if the cleanup goes wrong it is your route back.

Then look at three things:

• When files changed. Sort the site’s files by modification date. A cluster of files all modified at 3am on a Tuesday tells you roughly when it happened and what it touched.
• The access logs. Your host has them. Look for repeated requests to a plugin path in the hours before those file dates.
• Which plugins are out of date. Cross-reference the list against a vulnerability database. Nine times in ten, the answer sits in that list.

Change the right passwords, in the right order

Most people change the WordPress admin password and stop there. That one matters least.

Change these, in this order:

1. Hosting control panel, and SSH or SFTP. If an attacker holds this, nothing else you do counts for anything.
2. The database user password. Update wp-config.php to match, or the site goes down.
3. WordPress admin accounts. All of them, not yours alone.
4. Anything sharing the same password elsewhere. Your email above all.

Then read your list of WordPress users. Attackers add an administrator account with a plausible name so they can walk back in after you clean up. An admin you do not recognise is not a coincidence.

While you are in wp-config.php, rotate the eight security keys, the AUTH_KEY and SECURE_AUTH_KEY lines and their neighbours. Changing them logs out every session, including whoever is currently signed in as you.

Clean, and be honest about what clean means

Two approaches exist and one of them works.

The one that does not work: run a scanner, let it remove what it finds, hope. Scanners match patterns. They handle known malware and go blind at anything custom.

The one that works: replace rather than clean. Download fresh copies of WordPress core and each plugin and theme from source, then overwrite. Core and plugin files should come out byte-identical to the official versions. Where a file differs, either the attacker modified it or a developer edited a plugin in place, and both are worth knowing about. Your uploads folder and the database need a human to read them, because no clean original exists to compare against.

In wp-content/uploads, treat anything ending .php as suspect. That folder holds images and PDFs. Code has no business being in it.

Close the hole

Now you can ask how they got in. The answer is one of four things:

• An out-of-date plugin with a published vulnerability. The most common by a distance.
• A weak or reused administrator password that a brute-force tool guessed.
• An out-of-date PHP version the host never prompted you to upgrade.
• Stolen SFTP credentials, often lifted from a developer’s infected laptop rather than from anything on your server.

Fix the one you found. Then set things up so it cannot happen the same way twice: automatic plugin updates, two-factor authentication on admin accounts, and backups that live somewhere other than the server they back up.

That last point catches people out. A backup stored on the same server as the site is a second copy of the problem.

Ask Google to look again

If Google flagged the site, a clean site is not enough. You have to tell them. Search Console has a “Request review” button under Security Issues, and the review takes a few days. Requesting one while the site is still infected resets the clock, so check your work before you click it.

The part nobody wants to hear

Most of the sites we get called about were not targeted. No human picked on a joiner in Skipton. A scanner found a version number, matched it against a list, and fired the exploit, alongside a few hundred thousand other sites that afternoon.

Which is oddly reassuring, because the fix is not clever security work. Keep things updated. Store backups somewhere else. Stop reusing passwords. Boring, and it works.

If you would rather not think about any of it, that is roughly what our Care & Hosting covers: updates, backups, monitoring, and the clean-up if it ever comes to that, for £49 a month.