What to do when your website is infected with malware

Visitors are redirected to somewhere else, but only some of them, and usually not you — the injected code commonly checks for a search-engine referrer, a mobile user agent, or a visitor who has not been seen before, precisely so the owner keeps seeing a normal site.

Search results show pages you never wrote, often in another language, on paths that do not exist in your CMS. Google Search Console reports a security issue. Browsers show a red interstitial. Your emails start landing in spam because the domain's reputation has dropped.

Any one of these is enough to act on. Waiting to reproduce the redirect yourself wastes the hours that matter most, because the reputational damage compounds while you test.

Copy first. Snapshot the disk if you can, and take a copy of the web root and the logs to somewhere off the machine. This is the step people skip and the one that determines whether you ever learn how it happened.

Then reduce the harm. Putting the site into maintenance mode stops you serving malware to customers and stops the spam pages accumulating in the index. It feels drastic; it is far less costly than another day of a browser warning.

Do not start deleting. Every file you remove before understanding the intrusion is a lead destroyed, and the files that are easy to find are rarely the whole of it.

Work backwards from the earliest modified malicious file. Its timestamp gives you a window; the access logs for that window usually contain the request that created it. A POST to an upload endpoint, a request to a plugin path with a long query string, or a successful admin login from an unfamiliar address will normally be sitting right there.

Check the boring possibilities before the exotic ones: an outdated plugin or theme, a `.env` or configuration backup being served as a static file, an exposed `.git` directory, a database or admin panel reachable from the internet, or a reused FTP or SSH password.

If you genuinely cannot establish the vector, say so and treat everything the server could reach as exposed. That is a worse position, but an honest one, and it drives the right decisions about credentials and notification.

The reliable method is replacement, not removal: reinstall the CMS core, plugins and themes from official sources at current versions, and restore your own code from version control rather than from the live server. What remains to inspect by hand is then only your uploads directory and your database.

In uploads, anything executable is suspect — an image directory has no reason to contain a PHP file. In the database, look for injected script tags in post content and in options or settings tables, and for administrative users you did not create.

If your only backup is from after the infection date, it is not a clean state. Say that out loud before relying on it. This is the point at which many recoveries quietly become rebuilds, and it is better to know that at the start.

Assume everything the server could read was read. That means database credentials, SMTP and email API keys, payment gateway keys, storage keys, any third-party API token in a configuration file, all FTP and SSH credentials, and every administrative account on the site.

Rotate after you have removed persistence, not before — otherwise you hand over the new credentials along with the old ones. And rotate at the provider rather than just changing your local copy: a key that has been exposed has to be invalidated, not merely replaced in a file.

Where a key cannot be rotated without downtime, schedule it rather than skipping it. An unrotated exposed key is the reason for a second incident that looks unrelated.

Once you are confident the site is clean, request a review in Google Search Console under the Security Issues report, and submit the equivalent request to any other blacklist flagging you.

Do this once and do it properly. A review that fails because a single injected file remained resets the queue and adds days, and repeated failed submissions do not help. Before submitting, re-scan the whole site rather than the pages you happen to remember, and check that the spam pages now return a proper 404 or 410 rather than a redirect.

Expect the index to take longer to recover than the warning does. That lag is normal and is not a sign that the cleanup failed.

Close the vector you found, first and explicitly. Then reduce the surface that made it reachable: remove plugins and themes you are not using rather than leaving them deactivated, take administrative interfaces off the public internet, and stop serving anything from the web root that is not meant to be served.

Add the things that would have caught it earlier — file integrity monitoring on the web root, alerting on new files with executable extensions, and a backup you have actually restored from at least once.

The honest measure of a recovery is not that the site is up. It is that you can name the way in, show that it is closed, and say what would tell you if it happened again.