WordPress site hacked: what to do in the first 24 hours

How a hack actually shows up

The hardest part about a hacked WordPress site is not the damage — it is that the owner does not notice for months. Modern attacks do not deface your homepage or leave a message. They quietly add hundreds of pages that exist only for Google and for visitors arriving from search, while showing a logged-in administrator an untouched site.

That technique is called cloaking, and it explains the sentence we hear almost every time: “but the site looks fine to me”. The malicious code reads who is asking — is this Googlebot, did the visitor arrive from Google, are they on a phone — and only then decides what to serve. Which is why you never check from your own logged-in browser.

Three checks that take two minutes

• Search site:yourdomain.com in Google. Page through to the end. Addresses and titles you never wrote mean the spam is already indexed.
• Google Search Console → Security & Manual Actions → Security Issues. This is the one source that tells you literally what Google found and where. If you do not have Search Console, add the domain now — it is free, and you will need it to request a review.
• Open the site in an incognito window and on a phone, arriving by clicking a Google result rather than typing the address. Cloaking most often triggers on exactly that kind of arrival.

Why this keeps happening to WordPress

Not because WordPress is badly written. Because it is the most widely deployed platform, so it is the most profitable target — and, far more importantly, because almost none of the vulnerabilities are in WordPress itself. They are in plugins and themes. The vulnerability databases that track the WordPress ecosystem have shown the same picture for years: the overwhelming majority of reported flaws come from third-party plugins, and only a small fraction from core.

That has a practical consequence. A typical business WordPress site runs somewhere between fifteen and thirty plugins. Every one of them is somebody else's code with full access to your database, maintained by a person you have never met who can abandon the project without notice. An abandoned plugin that is still installed is an open door nobody is going to close for you.

The most common entry points, ordered by how often we actually see them:

1. An outdated plugin with a publicly disclosed vulnerability. Attacks start within days of disclosure, automated, against every site running that plugin.
2. “Nulled” premium themes and plugins from piracy sites. The backdoor is the business model, not an accident.
3. A weak or reused administrator password with no two-factor login.
4. An infected computer belonging to someone with FTP access, with saved credentials stolen off it.
5. Shared hosting where a neighbouring site under the same account was breached.

The first 24 hours, in the order that saves rankings

The order is not arbitrary. Most lasting damage comes not from the hack itself but from the panicked response — deleting the evidence, restoring a backup over a still-vulnerable install, and asking Google for a review before the site is genuinely clean.

1. Capture the state before you touch anything

Take a full copy of files and database as they are and store it off the server. If you later need to work out when and how they got in — and you will, because that determines whether it happens again — this is the only source. Download your host's access logs too; they usually rotate within days and disappear exactly when you need them.

2. Close off access

Change everything, not just the WordPress password: hosting control panel, FTP/SFTP and SSH, the database user in wp-config.php, and every WordPress administrator. Then log out all active sessions in WordPress — otherwise the attacker stays signed in with an existing cookie despite the new password. Delete administrator accounts you do not recognise, but write them down first.

3. Find the entry point, not just the symptom

Compare file modification dates against when the first symptoms appeared. Check the places backdoors nearly always hide: PHP files in wp-content/uploads/ (PHP has no business being there), a modified .htaccess and wp-config.php, plugin folders that look like real plugins but have no listing in the WordPress directory, and scheduled tasks in WP Cron. Diffing against a clean copy of the same WordPress version and the same plugins will surface every modified file.

4. Clean first, then update

Remove the malicious code, delete every plugin and theme you do not use (an inactive plugin is still executable code on the server), then update WordPress, all plugins, the theme and your PHP version. If your theme was edited directly in the files, those edits are lost on update — one reason cleaning an older site so often turns into rebuilding it.

5. Check the database, not only the files

Injected links, redirects and scripts frequently live in the database, in wp_options and wp_posts. A site cleaned only at the file level will happily keep serving spam out of its own content.

6. Only now request a review from Google

Once you are confident it is clean, submit a review request under Security Issues in Search Console and describe what you did. Submit too early, Google finds the same spam again, and the next review takes longer. The warning usually clears within a few days; rankings take weeks and depend on how long the spam stayed indexed.

What not to do

• Do not delete the spam pages from Google and call it done. Removing them from the index does not remove the code generating them. They come back.
• Do not restore an old backup and stop there. The backup contains the same vulnerability they used the first time. Without updates and password changes, reinfection is a matter of days.
• Do not change only the WordPress password. If there is a backdoor on the server, it does not need your password.
• Do not install five security plugins at once. On a compromised system they are unreliable, they slow the site down and they conflict with each other.
• Do not leave the site online while it serves malware to visitors. A day offline costs less than a week on Google's blocklist.

Clean the old site, or build a new one?

This is the only decision where real money is won or lost, and the answer is not always “build a new one”. Cleaning is frequently the right call. Here is how we tell them apart when somebody calls us:

That last row matters: in a shop, the order and customer data is worth more than the code, so you stabilise what exists first. For a five-page brochure site the maths inverts — cleaning, updating and then maintaining it often costs more than a new static site with no database, no plugins and nothing to hack.

We covered that trade-off in more detail in WordPress vs custom websites.

Making sure it does not happen again

Whether you clean or rebuild, these six things cover most of the risk:

• Fewer plugins. Every plugin you remove is one vulnerability somebody else no longer has to patch on your behalf.
• Automatic security updates for WordPress and plugins, with a check that the site still works afterwards.
• Two-factor login for every administrator, and a separate account per person — never a shared “admin”.
• Least privilege. The person writing posts is an Editor, not an Administrator.
• Off-server backups, with an occasional test that they actually restore. A backup nobody has ever tested is not a backup.
• Disable file editing from the dashboard — define('DISALLOW_FILE_EDIT', true); in wp-config.php removes the easiest way to turn a stolen login into a permanent backdoor.