My website’s been hacked: first steps to take

Finding out your website has been hacked is stressful, but panic leads to mistakes. What you need is a clear sequence of steps, done in the right order, so you contain the damage, find out what actually happened, and get back online without leaving the door open for round two. This is a general checklist that applies regardless of what platform or hosting setup you use.

1. Stay calm and assess before you act

Before touching anything, take stock of what you’re seeing. Is the site redirecting visitors to another domain? Is it serving pop-ups or fake login pages? Has your homepage been defaced? Or did you simply get a warning from your browser, search engine, or hosting provider? The symptoms tell you how urgent the next steps are. A site actively serving malware to visitors needs to come offline immediately. A quieter compromise, such as a hidden backdoor file with no visible symptoms yet, gives you a little more room to investigate before acting.

2. Take the site offline or into maintenance mode if it’s actively harming visitors

If the site is redirecting users, serving malicious downloads, or hosting phishing pages, your first priority is stopping harm to your visitors, not preserving uptime. Put the site into maintenance mode, restrict access to it, or take it offline entirely until you understand what’s happened. This also stops search engines from indexing malicious content and triggering a “this site may be hacked” warning, which is far harder to get removed once it appears.

3. Change every password and API key immediately

Assume that anything an attacker could have read, they now have. That means changing passwords for every account connected to the site: the admin panel, database, FTP or SFTP, hosting control panel, email accounts tied to the domain, and any third-party services with API keys or tokens stored in the site’s configuration. Rotate API keys rather than just changing passwords where you can, since a leaked key is often more useful to an attacker than a login. Do this from a device you trust is clean, not the potentially compromised server itself, and use unique, strong passwords rather than variations of the old ones.

4. Identify the entry point using your logs

Cleaning up visible damage without understanding how the attacker got in is a temporary fix at best. They will simply come back through the same route. Work through the evidence available to you:

• Web server access logs: look for unusual requests, repeated failed login attempts, or requests to files that shouldn’t exist.
• File modification timestamps: files changed or created around the time the compromise started are a strong clue.
• Application or CMS logs: plugin, theme, or extension activity, and any unexpected new admin users.
• Known vulnerabilities: check whether any software you’re running (CMS core, plugins, themes, libraries) had a disclosed vulnerability around the relevant dates.

Common entry points include outdated plugins or software with known vulnerabilities, weak or reused passwords, compromised third-party scripts, and misconfigured file permissions. Write down what you find; you’ll need it later to make sure the fix is complete rather than partial.

5. Restore from a known-good backup

If you have backups taken before the compromise, restoring from one is usually faster and more reliable than trying to manually strip out every injected file and altered database row. Attackers frequently plant more than one backdoor precisely because they expect the obvious one to be found and removed while others remain hidden. Choose a backup from a date you’re confident predates the attack, based on what your log review turned up. If you’re not certain when the compromise started, err on the side of an older backup rather than a more recent but riskier one.

6. Run a thorough malware scan

Whether or not you restore from backup, scan the site and server for malicious code before bringing anything back into public view. This includes scanning uploaded files, theme and plugin directories, and the database itself, since injected content sometimes lives in post content or configuration tables rather than in files. If you restored from backup, scan the restored copy too; there’s no guarantee the backup predates every piece of malicious code if the attacker had access for a while before you noticed.

7. Update everything before you go back online

Before you lift maintenance mode, update your CMS core, all plugins, themes, and any other software to their latest versions. If you identified a specific vulnerability as the entry point in step four, confirm it’s actually patched, not just that an update is available. Remove any plugins or themes you don’t actively use; unused software is still a potential vulnerability even if it’s inactive. This is also the point to double-check file permissions and remove any admin accounts you don’t recognise.

8. Consider whether you need to notify affected users

If the compromise exposed personal data, such as customer details, payment information, or account credentials, you may have a legal obligation to notify affected individuals and, in the UK, potentially the Information Commissioner’s Office (ICO) if the breach is likely to result in a risk to people’s rights and freedoms. This is a decision worth taking seriously rather than skipping because it’s uncomfortable; being upfront early is almost always better received than users finding out from someone else. If you’re unsure whether a notification is required, this is a good point to get advice, since data protection obligations depend on what was exposed and how.

Summary

A website compromise is unpleasant, but it’s manageable if you work through it in order: stop active harm first, lock out the attacker by rotating credentials, find out how they got in, restore clean content, scan for anything left behind, patch before you reopen, and be honest with anyone whose data may have been affected. Skipping steps to get back online faster is usually what leads to a second, more damaging compromise a few weeks later.