If you have just realised your WordPress site is hacked, the most useful thing you can do in the first hour is slow down. The instinct is to start deleting files and changing everything at once, and that instinct usually makes the cleanup harder. This is a calm, ordered playbook for that first hour: how to contain the problem, work out what you are actually looking at, preserve what an engineer will need, and change the locks, without destroying the evidence that explains how it happened.
First, do not delete anything yet
The single most common mistake is reaching for the delete key. You spot a strange file, an admin user you do not recognise, or a folder full of gibberish, and you remove it on sight. The problem is that a compromise is rarely one file. Deleting the visible pieces tips off nothing and removes the trail that shows how the attacker got in and what else they touched. You end up with a site that looks cleaner for an hour and reinfects itself by the afternoon, because the way in is still open. Leave the mess in place for now. Your job in the first hour is to contain and record, not to scrub.
Take the site out of harm’s way
Containment comes before cleanup. If the site is serving malware, redirecting visitors, or sending spam, every hour it stays live does more damage to your visitors and your reputation with Google. The calm move is to put the site into maintenance mode or take it offline at the hosting level, rather than half-fixing it in public. That stops the bleeding and buys you time to think. If you are on managed hosting, this is usually one setting or a message to support. If you are on a shared plan, taking the site offline also protects you from a compromise that may have spread from a neighbouring site on the same server.
Work out what you are actually seeing
Before you can fix anything, you need a plain description of the symptoms. Write down what is actually wrong, in specific terms, because it changes what the fix looks like. Common patterns include:
- Defaced pages, or a homepage replaced with someone else’s message.
- Visitors redirected to a site you do not control, often only on mobile or only from search results.
- Admin users, posts, or plugins you did not create, appearing in the dashboard.
- Your host or Google flagging the site, or a sudden spike in outbound email.
- Pages of spam content, often about pharmaceuticals or counterfeit goods, that you never published.
Note the first time you noticed each symptom. That timestamp matters later, because it helps you and any engineer choose a backup from before the compromise rather than one that already contains it.
Preserve the evidence before you clean
A compromised site is also a record of what happened, and that record is worth keeping. Before anyone starts removing files, take a full copy of the current state: the files and the database, exactly as they are now. This sounds counterintuitive when the files are the problem, but a snapshot of the infected site lets an engineer compare it against a clean version, find the entry point, and confirm the cleanup was complete. Save your access logs too, if you can reach them. The logs often show the exact request that got in, and without them you are guessing. Keep this copy somewhere separate from your live environment.
The goal of the first hour is not a clean site. It is a contained site, an honest description of the symptoms, and a preserved copy that tells you how it happened. Cleanup is easier and safer once those three are in place.
Change the locks
Once the site is contained and you have a preserved copy, start closing off access. Assume that any credential the attacker could have reached is now known to them. Rotate your WordPress administrator passwords, your SSH and SFTP passwords, and your database password. Change your hosting account password too, and enable two-factor authentication where it is offered. If other people have accounts on the site, their credentials need rotating as well, because a single reused password is often how the whole thing started. Do this after you have preserved evidence, not before, so you do not lock yourself out of logs you still need.
When to call an engineer
Some incidents are small and some are not, and it is worth being honest with yourself about which one you have. If the site is a simple brochure with a recent clean backup, you may be able to restore it and move on. If the site takes payments, holds customer accounts, has no recent backup, or keeps reinfecting after you clean it, that is the point to bring in someone who does this regularly. There is no prize for struggling alone through a compromise on a site that matters. An engineer-assisted cleanup is methodical: restore from a backup taken before the incident, rotate every credential, remove or replace the exploited component, and then check the logs to understand the entry point so it does not simply happen again. You can read how that process works on our malware cleanup page.
If the site handles personal data, remember that a serious breach can carry notification duties under the GDPR. That is not a reason to panic, but it is a reason to document what you find and, if in doubt, to check with whoever handles data protection for your organisation.
After the first hour
Getting through the first hour well means you have contained the damage and kept your options open. What it does not do is guarantee the problem stays gone. Malware comes back when the site is cleaned but the way in is left open, and when the same unpatched plugins sit on the same shared server they always did. The durable fix is a clean restore followed by managed updates, tested backups and monitoring, so the surface that let the attacker in is actually closed. That is the model behind our managed hosting: recovery and prevention are the same work, done properly once rather than repeated every few months. If you are in the middle of an incident right now, the fastest path is to talk to an engineer and let us take it from here.