My Website Was Hacked: What to Do in the First 24 Hours

You open your site in the morning and find pharmacy ads in a language you do not speak. Or a "this site may harm your computer" warning appears under your listing in Google. Maybe your hosting provider emailed you about malware in your account. This article is for exactly that moment: what to do, in the right order, without panicking.

First, know this: on a hacked site, rushing is the most expensive mistake. Most people start by deleting the malicious files. That destroys the evidence and leaves the attacker's back door in place — the site breaks again a few days later. Order matters.

Was It Really a Hack? The Symptoms

• Content, links or redirects you never added — typically gambling, pharma or counterfeit brands
• Your title or description in Google differs from what you wrote
• Visitors on mobile get redirected elsewhere while desktop looks normal
• Admin accounts you do not recognise
• File timestamps updated in bulk to the same date and time
• Mass email leaving your server, your domain landing on blocklists

"The site got slow" or "I see a white screen" alone is not evidence of an attack; those are usually plugin conflicts or server resource problems.

The Right Order for the First 24 Hours

1. Do not take the site down — contain it

Killing the domain entirely makes Google drop your pages. Put the site into a temporary maintenance state instead: visitors see an informative screen and search engines receive a "temporarily unavailable" signal. Malicious content stops being served while your rankings stay intact.

2. Change passwords, in the correct order

Server and control panel first, then the database, then site admin accounts, and FTP last. Do it in reverse and the attacker, still inside, simply reads your new credentials. When you reset admin accounts, terminate all active sessions too — a password change alone does not evict someone with an open session.

3. Take a backup before deleting anything

It sounds backwards, but keep a copy of the compromised state. It is the only way to find how they got in. Cleanup without finding the entry point produces the same result within days.

4. Replace, do not clean

Picking malicious code out of files by hand is exhausting and unreliable. The correct method is to reinstall the core, themes and plugins from official sources. Your own files are the uploads directory and custom development — those are what actually need inspecting.

5. Hunt the back doors

Attackers leave small files behind so they can return. They usually carry innocent names and sit deep inside the uploads directory. An executable file inside an image folder is suspicious on its own. Scheduled tasks, admin tables in the database and code appended to the end of theme files all need checking.

6. Close the hole

The job is not finished until you know how they came in. The three most common doors: an outdated plugin, a weak admin password, and another neglected site sitting on the same server. That third one gets missed constantly — a forgotten test site from years ago can take down the live site next to it.

7. Tell Google it is clean

If a warning appeared in search results, you must submit a review request in Search Console after cleanup. Skip this and the warning can linger for weeks on a perfectly clean site.

When to Stop and Call a Professional

• The site holds customer data, orders or personal information — this is no longer only technical, it is a data breach notification matter
• You cleaned it and the malicious content came back (the back door is still open)
• Mass spam is leaving your server
• You have no backup, or you suspect the backup is infected too
• It is an e-commerce site with a payment integration

How We Handle It

We run recovery in three stages. Diagnosis: a copy of the site is moved to an isolated environment and we identify the entry point and every affected file. Repair: core and plugins are reinstalled clean, custom code is reviewed line by line, back doors are removed, credentials and access are reset. Hardening: login attempt limits, corrected file permissions, closing unnecessary entry points, a real backup routine and a restore test to prove the backup actually works.

We documented a similar rescue on an education site step by step in this case study. The first month after an incident is the critical window, and the site should be monitored throughout it.

Most of these incidents never happen on sites under real maintenance. Updates tested before going live, backups verified by restore, and login attempts monitored all shrink the attack surface substantially. We explain what our maintenance and support subscription covers on its own page.

How Did It Start? The Five Most Common Entry Routes

The most valuable output of a recovery is not a clean site but a known entry route. The five we see in practice:

• An outdated plugin or theme. When a vulnerability is published, automated scanners sweep the entire internet. The attack was not aimed at you; a door was simply found open.
• A weak or reused admin password. A password leaked on another site gets tried on yours. Reusing credentials is the most expensive habit there is.
• A forgotten old site on the same server. An unmaintained test install falls, and the attacker moves sideways into neighbouring directories. The most frequently missed scenario.
• An uploads directory that can execute code. If code can run where images are uploaded, your file upload feature becomes the attack surface.
• A compromised workstation. Malware on the machine that connects to the server leaks credentials. The site itself can be flawless and the breach still happens.

Cleanup without finding the route sends the same invoice again within weeks, which is why we never skip the investigation stage.

If Customer Data Was Affected: The Legal Side

Most guides skip this, yet for a business it is more binding than the technical part. If your site holds names, phone numbers, emails, addresses or order details and those were accessed without authorisation, you have a data breach.

The required steps run in parallel with the technical response: establish the scope and how many people are affected, document the incident, assess your notification obligations to the supervisory authority, and decide whether affected individuals must be informed. That assessment belongs with your legal advisers; the technical team's job is to answer "what could have been accessed".

The practical consequence: the records we keep during recovery are not only technical. Which files were accessed and when, which accounts were taken over, and how long the intrusion lasted are the evidence base for the notification decision. A cleanup that begins by deleting evidence destroys that basis too.

What Would It Cost If We Fixed It?

You do not have to guess, and you do not have to ask us. Tick the items you need in the calculator on our site and the total appears instantly. No forms, no waiting for a quote.

Calculate your price in one minute →