Recovering From a Hacked Website: First Steps, Cleanup and Hardening

The signs are usually unmistakable: your site redirects visitors somewhere disreputable, the browser warns it is dangerous, search results show pages you never wrote, or your host suspends the account and sends a malware notice. What you do in the first hour decides whether this becomes a bad day or a bad month. This guide gives the order of operations — and the order matters, because the instinctive moves (delete things quickly, restore the first backup you find) can destroy the evidence you need and reinstate the problem you are trying to remove.

Step 1: Contain, and do not panic-delete

Take the site offline or put it behind a maintenance page. A hacked site that stays live keeps harming visitors, keeps spreading whatever it is serving, and keeps damaging your search reputation. If your host has suspended the account already, that containment is done for you — annoying, but useful.

Then, before changing anything else: preserve evidence. Download a complete copy of the site’s files and database as they are now, and note the server and access logs if you can reach them. This infected copy is not for restoring — it is for answering the question every cleanup depends on: how did they get in? Delete first and you will never know, which means you cannot close the door they used.

Work from a clean device, and run a malware scan on your own computer too. If your machine is compromised, every new password you type is a gift to the attacker.

Step 2: Change the locks — in the right order

From the clean device, change passwords in this order: hosting account and control panel first, then your registrar and email (the accounts that can reset everything else), then the site’s admin accounts, database password, and FTP/SFTP/SSH credentials. Enable two-factor authentication wherever it is offered as you go.

Also revoke what passwords do not cover: application passwords, API keys, and — on WordPress — the security keys and salts in the configuration, which invalidates every logged-in session, including the attacker’s. Assume anything stored in the site (including keys inside configuration files) has been read.

Step 3: Find the entry point

Most small-site compromises come from a short list: an outdated plugin, theme or CMS core; a weak or reused admin password; a nulled (pirated) plugin or theme carrying a backdoor from the start; or credentials stolen from an infected computer. Look for the evidence: files modified around the incident date, administrator accounts you do not recognise, scheduled tasks and cron jobs you did not create, and log entries showing the first suspicious access. Your host’s security team or a malware scanner can help identify malicious files, but treat scanner output as leads, not gospel.

Step 4: Clean, or rebuild — honestly

There are two honest routes back:

Restore a known-good backup. If you have a backup from before the compromise — and you can date the compromise well enough to know the backup is clean — restoring it is the fastest safe path. Restoring a backup taken after the break-in restores the backdoor with the site. If you cannot be sure a backup predates the incident, it is not known-good.

Clean the installation. Replace the CMS core and every plugin and theme with fresh copies from their official sources (this alone removes most injected code, which hides in modified core and plugin files), then audit what cannot be replaced: the uploads directory (a classic hiding place — it should contain media, not executable code), custom code, the database (injected admin users, poisoned options and content), and configuration files. Delete anything you cannot account for; every legitimate file can be re-downloaded, while one surviving backdoor restarts the whole incident.

Whichever route you take, update everything to current versions as part of the recovery — returning with the same outdated component that let them in is an invitation.

Step 5: Go back online carefully

Before reopening: change the database password and update the configuration to match, confirm no rogue admin accounts exist, and review file permissions. Then bring the site up and check it as a visitor — the pages, the forms, the checkout if you have one. If search engines flagged the site, request a review through their webmaster tools once you are confident it is clean; asking before it is clean wastes the review. Tell your host what you found and did; hosts see the server-level picture you cannot, and a suspended account usually needs their sign-off to reopen.

If the compromise may have exposed customer data — names, emails, order details — take advice on your obligations to notify. That duty varies by jurisdiction, and guessing wrong in either direction is costly.

Step 6: Harden, so the post-mortem has a point

• Updates on a routine, not a hope. Core, plugins and themes updated promptly; unused ones deleted entirely — an inactive vulnerable plugin is still executable code on your server.
• Least privilege. Separate admin accounts per person, no shared “admin”, and two-factor authentication on admin logins.
• Backups you have tested. Automatic, kept off the server, with a restore you have actually rehearsed. Backups are what turn the next incident from a rebuild into a restore.
• A malware scanner or file-integrity monitoring, so the next change is noticed in hours, not by a customer.
• Close the specific door. Whatever the entry point was — a plugin, a password, a pirated theme — name the change that closes it. “Be more careful” is not a control.

When to hire help

Bring in professional cleanup help if the site takes payments, holds significant customer data, keeps getting reinfected after your cleanup, or if the steps above exceed what you can do confidently. Reinfection after cleanup almost always means a backdoor or the entry point survived — that is precisely the situation specialists exist for, and paying for it is cheaper than a second public incident.

After reopening: watch for reinfection

Reinfection in the first few days is the classic sign that something survived — a backdoor file, a rogue account, a credential you missed. For the first week, check the site daily: new admin users, recently modified files, and the scanner’s reports. Keep the evidence copy and your notes from the cleanup until that week has passed clean; if the site is hit again, the comparison between the two incidents is the fastest route to the hole you missed.

If it does come back, do not simply repeat the same cleanup louder. Escalate: that is the moment for professional help or for rebuilding the site from scratch — fresh installation, content exported and inspected, nothing executable carried over. A second reinfection is information, and it is telling you the problem lives somewhere your cleanup did not reach.

The bottom line

A hacked site is recovered in order: contain, preserve, lock out, investigate, rebuild clean, harden. The sites that suffer twice are the ones that skipped the investigation and restored the problem, or cleaned the files and left the door open. Do the steps in order and the incident becomes what it should be — a bad day with a written lesson attached, not the first of several.

Reviewed 25 October 2026. Steps described are the general recovery pattern for CMS-based sites such as WordPress; server-level incidents on a VPS add the operating system to the audit scope. What incident help Offshore Hosting support will provide is [TO BE CONFIRMED] — ask before you need it, not during an incident.

Related guides

• SSL Certificates and HTTPS Explained
• How to Back Up and Restore WordPress
• A Beginner VPS Security Checklist

Related service: Knowledge Base

← All guides · Knowledge Base