What to Do When Your Website Is Hacked, in the Right Order

Resist the Urge to Clean It Up Immediately

The instinct when you discover a hacked website is to fix it as fast as possible — delete the strange files you can see, reinstall WordPress core, get the site looking normal again before anyone notices. Followed in that order, that instinct is a mistake. Deleting first destroys the evidence you need to find out how the attacker got in, which means you can end up cleaning the same site twice, a week or a month apart, because the actual entry point was never closed. There is a correct order to this, and it starts with slowing down, not speeding up.

Step 1: Isolate the Site Without Erasing Anything

Take the site out of public view first — maintenance mode, restricting access at the server level, or pointing the domain elsewhere temporarily — but don't start removing files yet. The goal at this stage is to stop the damage from spreading or getting worse (more spam pages indexed, more visitors served malware, more of your server's reputation burned with hosts and blocklists), not to clean anything. Isolation and cleanup are two different steps, and the second one only works properly once you've completed the step below.

Step 2: Take a Full Snapshot Before You Touch Anything

Copy the entire site — every file and the full database — exactly as it is in its compromised state, and store that copy somewhere separate from the live server. This is your evidence. It's what lets you compare "before" and "after" once you start cleaning, and it's what you'd need if you ever had to work out precisely what was accessed. Alongside the file copy, pull whatever server access logs and error logs your host gives you. These often show the actual mechanics of the break-in — unusual request patterns, a spike of failed login attempts, a file upload at an odd hour — that get lost the moment you start deleting things. Sucuri's own cleanup guide makes the same underlying point: back up the compromised state before you modify anything.

Step 3: Rotate Every Credential You Have

Once someone has had file-level or database-level access to your server, treat every credential stored anywhere on that site as read. That means: WordPress admin passwords, the database password, hosting control panel and SFTP/SSH credentials, and any API keys sitting in wp-config.php or in plugin settings. Rotate all of them, not just the WordPress admin password — a wp-admin password reset alone does nothing if the attacker also has your database credentials or an SFTP login. If any third-party services were connected (payment gateways, email providers, marketing tools), revoke and reissue those tokens too.

Step 4: Find the Entry Vector Before You Clean

This is the step skipped most often, and it's the one that actually prevents a repeat. Compare file modification timestamps against your last known-good backup or your deployment history to see what changed, and when. Cross-reference that date against your plugin and theme changelog — a lot of compromises trace back to a specific, disclosed vulnerability in a specific plugin version. Check for anything that looks like persistence: an unfamiliar Administrator account, an unexpected scheduled task or cron job, a plugin you don't remember installing. Google's own guidance for hacked sites points the same way, recommending a check of server logs for anomalies like unusual failed-login patterns and unknown user accounts as part of understanding what happened before you clean up.

If you skip this step and go straight to cleanup, you're removing the symptoms while leaving the actual vulnerability in place — and an automated scan will likely find it again.

Step 5: Clean or Rebuild — Now That You Know What You're Fixing

There are two realistic paths, and which one you take depends on what you have. If you have a backup taken before the compromise and you're confident it predates the infection, restoring from it is usually the fastest and cleanest option. If you don't, or you need to preserve data created since then, the manual route means comparing your WordPress core files against a fresh, official download, and going through custom or premium files by hand to remove injected code — the same process Sucuri's guide walks through in detail. Either way, this step only happens after Step 4: close the specific vulnerability you found before bringing the site back online, not after.

Step 6: Request a Review — Without a Guaranteed Timeline

If your site is showing a Security Issues report in Google Search Console, or a Safe Browsing warning to visitors, only request a review once the site is genuinely clean across every affected page and the vulnerability is closed. Search Console's own guidance is explicit that "fixing the issue on just some pages will not earn you a partial return to search results," and resubmitting a request while one is still pending can slow the whole process down rather than speed it up.

On timing: there is no fixed turnaround Google commits to. Some reports describe simple, confirmed-clean cases clearing within roughly 72 hours; Google's own Search Console documentation says most reconsideration reviews take several days to a few weeks, and more complex or repeat cases can take longer still. Don't promise a client — or yourself — a specific date. Plan around "as soon as it's actually clean," not "by Friday."

Why the Order Matters More Than the Speed

Every step above exists to protect information you'll need for the step after it. Delete first, and you lose the logs that would have told you the entry vector. Skip the entry-vector step, and you clean a site that's still vulnerable to the exact same attack. Request a review before you're actually done, and you burn time waiting on a review that was never going to pass. Going in this order is slower on day one and considerably faster overall.

---

Once a site is back up and the immediate fire is out, it's worth a second, calmer look to confirm the vulnerability really is closed and nothing was left behind — that's what our Essential System Review is for: RM1,500 (RM999 until 16 September 2026), a fixed-price technical audit with a written report. If you'd rather have ongoing monitoring so the next issue is caught before it becomes a full incident, JagaWeb Care starts at RM450/month.