What to Do After a Hacked Website (Before You Panic)

You might find out from a browser warning, a strange redirect, an email from your host, or a customer asking why your homepage is suddenly selling something else. However it happens, the first few minutes matter less than doing the next steps in a sensible order. Rushing to delete files or restore a backup before you understand what happened can destroy the evidence you need to actually fix the problem.

First, confirm it is actually a hack

Not every scary warning means a break-in. A browser "deceptive site" flag, a search engine blocklist warning, or a spam-folder complaint can sometimes come from a false positive, an old cached scan, or even a compromised third-party ad or script embedded elsewhere on a page. Before assuming the worst, check your hosting account for any security notices, look at your site in an incognito browser window, and see whether the odd behavior (a redirect, injected content, unfamiliar admin users) is actually present right now rather than reported once.

If you do find defaced pages, unfamiliar files, unexpected admin accounts, or your host has already suspended the account for malicious activity, treat it as confirmed and move to containment.

Contain it before you do anything else

• Put the site into maintenance mode or take it offline if it is actively serving malware, spam redirects, or defaced content to visitors.
• Do not delete anything yet. Removing files destroys evidence you may need to understand how the attacker got in.
• Change the hosting account password immediately, since that is the master key to everything else.
• If you suspect the compromise reached your email, change that password too, from a different, uninfected device if possible.

Work out what actually happened

Look at file modification dates in your hosting file manager or via FTP, sorted by most recently changed. A cluster of files edited at the same odd hour, especially ones you did not touch, is a strong clue. Check your CMS user list for admin accounts you do not recognize, and check for scheduled tasks or cron jobs you did not create. If your host offers access or error logs, a spike in requests to an unfamiliar file, or repeated login attempts before the incident, can point to how the attacker got in, often an outdated plugin, a weak or reused password, or a vulnerable theme.

You do not need to become a forensic investigator. The goal is a rough answer to "how did they get in," because cleaning up without that answer usually means getting hacked again.

Clean up the right way

If you have a backup from before the compromise, and you have identified roughly when it started, restoring that backup is usually faster and more reliable than manually hunting down every injected file. Confirm the backup predates the intrusion, not just the point where you noticed it, since some malware sits quietly for days or weeks before doing anything visible.

Without a clean backup, a malware scanner built for your CMS can identify known malicious code patterns, but manual review of core files, themes, and plugins against fresh copies from the original source is still the most reliable way to catch anything a scanner misses. This is also a reasonable point to ask your hosting provider's support team for help; identifying and removing malicious files on a live server is exactly the kind of task hosting support teams handle regularly.

Change every credential connected to the site

• Hosting account and control panel login.
• CMS admin accounts, and any other user accounts with elevated permissions.
• Database username and password.
• FTP/SFTP credentials.
• Any API keys or third-party service tokens stored in the site's configuration.

Assume anything stored in plain text on the server was seen. It is faster to rotate a credential you did not strictly need to than to guess wrong about which ones were exposed.

Update everything before you bring the site back

Bring your CMS core, every theme, and every plugin fully up to date, and remove any that are inactive or no longer maintained by their developer. If the intrusion exploited an outdated component, restoring the site without updating it first just reopens the same vulnerability. This is also a good moment to check your PHP version and any other server-level software your hosting plan lets you manage, since old runtime versions carry their own unpatched issues.

Check for anything left behind

Attackers who gain admin access sometimes leave a second, quieter way back in: a hidden admin account, a small script disguised as an image or plugin file, or a scheduled task that re-adds malicious code on a timer. After cleanup, review your user list, scheduled tasks, and uploads folder once more a few days later, since some backdoors are designed to reactivate after the initial fuss dies down.

Tell the people who need to know

If customer data, order information, or stored passwords may have been exposed, you likely have an obligation to tell the affected people and possibly a regulator, depending on where your business and customers are located. This is a legal question, not just a technical one, and if there is any chance personal data was accessed, it is worth a short conversation with a lawyer familiar with data protection rules rather than guessing. Separately, if your domain was blocklisted by search engines or browsers, most provide a review process to request removal once the site is genuinely clean.

Reduce the odds of a repeat

• Turn on two-factor authentication for every admin account.
• Keep automatic or at least prompt-reminded updates for core software and plugins.
• Use a web application firewall to filter known attack patterns before they reach your site.
• Keep backups outside the website itself, so a compromise cannot delete your only recovery point.
• Remove plugins, themes, and accounts you are not actively using.

A hacked website is unpleasant but recoverable, and most small business sites are back to normal within a day once the right order of operations is followed. The lasting damage usually comes from skipping the "what happened" step, not from the incident itself.