Hacked website: what to do right now, step by step

Finding out you have a hacked website is one of those heart-racing moments: redirects to shady pages, a red Google warning scaring your visitors, worried emails from customers. The good news is that you almost always get everything back, as long as you work methodically and in the right order. This is a hands-on emergency guide: no panic, just concrete steps.

In this article we look at how to tell whether the site is really compromised, the first moves to limit the damage, how to find and remove the problem, restoring from a clean backup, recovering your reputation on Google and — if personal data is involved — what the GDPR requires. We close with the part that matters most: how to avoid ending up here again.

Take two minutes to read to the end before you touch anything. Moving with a plan is the difference between an hour of work and a lost weekend.

How to tell whether your site is really hacked

Before you panic, check. A slowdown or an error doesn't automatically mean an attack. But if you notice one or more of these signs, you probably do have a hacked website.

The most common signs of a compromised site

• Strange redirects: anyone opening your domain ends up on gambling sites, online pharmacies, adult content or scam pages. The redirect often fires only on mobile, or only for visitors arriving from Google, so it slips past your own checks.
• Google warnings: the classic red screen "The site ahead contains malware" or the "This site may be hacked" label in search results.
• Spam in your content: new pages you never created, links in Japanese or Chinese (so-called "Japanese SEO spam"), ads appearing out of nowhere.
• Unauthorised outgoing email: your domain starts sending spam and lands on blacklists. You usually notice when your legitimate emails stop being delivered.
• Unusual traffic spikes: sudden surges towards URLs that don't exist, typically a sign of scanning or bots exploiting a flaw.
• Recently modified files: modification dates on system files you never touched, or files with random names (x7f2a.php, wp-conflg.php) inside your site folders.
• New admin users you didn't create, or logins from countries where you don't operate.
• The site is slow or goes down for no reason, because server resources have been diverted to the attacker's activity.

Quick checks you can run right now

1. Open the site in private browsing and from a smartphone on mobile data (not your own Wi-Fi): many attacks only show themselves to visitors who aren't "recognised" as the owner.
2. Search Google for site:yourdomain.com and look for junk pages among the results.
3. Check your security status in Google Search Console, under "Security issues".
4. Look at the last modification date of your files over FTP or in your hosting file manager: sort by date and look for anything that changed without your input.

If even one of these checks confirms your suspicion, act immediately. From here on you'll find the sequence of what to do with a hacked website, without skipping steps.

First moves to limit the damage

The goal of the first few minutes isn't to "fix everything", it's to stop the bleeding: prevent the attacker from carrying on and stop the damage spreading to your visitors or your reputation.

1. Put the site into maintenance mode (or take it offline)

A maintenance page protects visitors from the malware and gives you room to work calmly. You don't need to delete anything: just route traffic to a static "We'll be back soon" page. If you're not sure how, your host almost certainly offers one-click maintenance mode.

Don't leave the compromised site online and visible: every extra hour raises the risk of ending up on blacklists and makes the SEO recovery harder.

2. Change every password and key

Assume every credential is compromised. In order of priority:

1. Hosting control panel and FTP/SFTP account passwords.
2. Database password.
3. Site administration credentials (CMS, backend, admin area).
4. API keys and tokens (payments, transactional email, third-party services): if they were written in plain text in the code or a config file, treat them as burned and regenerate them.
5. Mailbox passwords tied to the domain.

Use long, unique passwords and turn on two-factor authentication wherever you can. If you reused the same credentials across services, change them everywhere.

3. Isolate and snapshot the current state

Before deleting anything, take a "dirty" backup of the site exactly as it is now (files + database). It sounds counter-intuitive, but that copy serves two purposes: understanding how you were attacked, and giving you a way back if you break something during the cleanup. Label it clearly as "compromised – do not restore".

If you have other sites on the same hosting account, check them too: infections often spread between sites sharing the same space.

Finding and removing the problem

Now that the bleeding has stopped, the investigative part begins: working out what was modified and removing the malware from the site.

Malware scanning and hunting for infected files

Start with an automated scan. Most hosts offer a built-in scanner (often based on ImunifyAV or similar); alternatively there are dedicated scanners for your CMS. The scan gives you the list of suspicious or modified files.

What to look for manually, if you want confirmation:

• Files with obfuscated functions such as eval(base64_decode(...)), gzinflate, str_rot13.
• .php files in folders where they have no business being (the uploads or images folder, for instance).
• Injected lines of code at the top or bottom of otherwise legitimate files.
• Scheduled tasks (cron jobs) you didn't create that quietly reinstate the infection.

Reviewing users, permissions and access logs

Open the list of administrator accounts and delete any you don't recognise. Check your host's access logs to identify which IPs broke in and when: they often reveal the entry point (a vulnerable endpoint, an outdated plugin, an unprotected form).

Also check file permissions: folders set to 777 or config files writable by anyone are an open invitation. Typical safe values are 644 for files and 755 for folders.

The specific case of a hacked WordPress site

If you have a hacked WordPress site, the logic is the same but with some extra care, because WordPress is the world's most attacked platform precisely because it's everywhere:

• Replace the core files with a clean copy downloaded from the official site: the core should never be modified, so any difference is suspicious.
• Update — better still, reinstall — themes and plugins from official sources. Abandoned or "nulled" plugins (pirated paid versions) are the number one cause of infections.
• Check wp-config.php, .htaccess and index.php: attackers love them for injecting redirects and backdoors.
• Regenerate the security keys (salt keys) in wp-config.php to invalidate every active session.

Want a systematic way to check your site's state? The guide on how to check website security has an ordered checklist you can follow once the incident is over too.

Restoring the site from a clean backup

Often the fastest and safest way to recover a hacked website isn't chasing every single infected file, but starting again from a backup taken before the attack.

How to pick the right backup

Don't just grab the most recent backup: it may already contain the malware. You need the last copy taken before the signs of compromise. If you noticed the first redirects on the 10th of the month, look for a backup from the 5th or earlier, and verify it.

After restoring, don't switch everything back on immediately: update the CMS, themes and plugins, double-check that no backdoors remain, and only then put the site back online.

What if you don't have a backup?

It happens, especially with projects built in a hurry. In that case the cleanup is manual: starting from the scan, remove the injected files, restore system files from official copies and rebuild the damaged parts. It takes longer, but it's doable. It's also the moment to finally set up daily automated backups stored off the server: next time they'll save you.

Cleaning up your reputation: Google and blacklists

Removing the malware isn't enough: if Google or antivirus vendors have already flagged your domain, the site will keep showing warnings until you request a new review.

1. Google Search Console – Under "Security issues", once everything is clean, submit a review request. Google rescans the site and, if it's clean, usually removes the warning within a few days.
2. Blacklist removal – Check whether your domain or IP has ended up on anti-spam blacklists. If your domain was sending spam, request removal from the main reputation services once the cause is fixed.
3. Google Safe Browsing – The database behind the red warnings in Chrome and Firefox. It updates automatically after the Search Console review.
4. Reindexing – Ask Google to recrawl the cleaned pages and watch the spam pages disappear from the results.

Over the following days keep an eye on logs and traffic: suspicious activity coming back means a backdoor survived the cleanup.

Personal data involved? Your GDPR obligations

Here's the layer many people forget. If the compromised site processed personal data — even just newsletter subscriber emails, customer names or order details — the attack may qualify as a personal data breach, and the GDPR sets out specific obligations.

• Risk assessment: you must determine whether the breach poses a risk to the rights and freedoms of the people involved.
• Notifying the authority: if there is a risk, the breach must be reported to the supervisory authority (your national data protection authority) as a rule within 72 hours of becoming aware of it.
• Informing data subjects: if the risk is high (passwords or payment data leaked, for example), you must also tell the people affected, in plain language.
• Breach register: every breach must be documented internally, even when you decide not to notify, recording the reasoning.

This isn't box-ticking for its own sake: handling the communication well protects your users' trust and shields you from penalties. If you don't know where to start with the documentation, keep it in mind for the prevention section below.

Prevention: how to avoid another hacked website

Once the emergency is over, the work that really counts begins: making sure it doesn't happen again. Most attacks aren't targeted — they're bots scanning the web for known flaws. Closing those flaws takes you out of the firing line.

The basic good habits

• Constant updates: CMS, themes, plugins and libraries always on the latest version. The vast majority of compromises exploit vulnerabilities that were patched long ago.
• Unique passwords and 2FA on every critical login.
• Automated daily backups, stored off the server and tested (a backup you've never tried restoring isn't a backup).
• Less attack surface: uninstall plugins and themes you don't use, delete unnecessary users.
• Correct file permissions and config files that aren't publicly accessible.

For a full overview of the measures worth putting in place, the guide on how to build a secure website pulls it all together into an ordered path.

The blind spot for anyone who built their site "with AI"

More and more sites and apps are born through vibe coding: you describe what you want to an AI assistant and the code appears, often without whoever publishes it having a technical background. It's extremely powerful, but it introduces classes of vulnerability that go unnoticed: API keys written in plain text in the code, endpoints with no authentication, no rate limiting, guessable IDs in the URL that expose other users' data, missing security headers, cookies and privacy notices that aren't compliant.

The problem is that these defects don't throw errors: the site "works". They sit there, silent, until a bot finds them. If your project started this way, dig into the typical risks in the dedicated guide to vibe coding: recognising them is the first step to closing them.

Checking for vulnerabilities upstream

The most important lesson from any incident is this: it's far cheaper to find a flaw before the attacker does than to clean up afterwards. A periodic vulnerability check should become part of your routine, just like backups.

This is where a tool like Appurai earns its place both after an incident and in prevention: it runs an automated security and GDPR compliance scan and tells you, in plain language, where the holes are — exposed keys, open endpoints, missing headers, guessable IDs, privacy issues out of line. Running it over a freshly cleaned site confirms that the door the attacker came through is actually shut.

Want to set up a recurring check? The guide on website security testing explains how to make verification a habit rather than an emergency measure.

Frequently asked questions

How can I know for sure whether my site is hacked?

Cross-reference several signals: redirects to suspicious pages, Google warnings, spam pages in search results (site:yourdomain.com), files modified without your input, unauthorised outgoing email. Always open the site in incognito mode and from mobile data, because many infections only show themselves to "unrecognised" visitors. If even one of these checks comes back positive, treat the site as compromised.

How long does it take to recover a hacked website?

It depends on the situation. With a recent clean backup you can be back online within hours. Without a backup, doing a manual cleanup, it takes from half a day to a few days. Removing Google's warnings, after a review request, generally takes one to a few days.

My WordPress site is hacked: where do I start?

Put the site into maintenance mode, change every password and the salt keys, then replace the core files with a clean official copy. Reinstall themes and plugins from official sources, deleting anything abandoned or pirated, check wp-config.php and .htaccess, and remove unknown admin users. Finally, restore from a pre-attack backup if you have one.

Do I have to tell anyone if personal data was exposed?

Yes. If the site processed personal data and there's a risk to the people involved, the GDPR requires you to notify the supervisory authority as a rule within 72 hours, and to inform the data subjects when the risk is high. Either way, document what happened in your breach register, even if you decide not to notify.

Is removing the malware enough to be safe again?

No. Cleaning removes the effect, not the cause. If you don't close the flaw that let them in — a vulnerable plugin, an open endpoint, an exposed API key — you'll be reinfected. After the cleanup, update everything, rotate credentials and run a vulnerability check to confirm the entry point is closed.

How do I stop my site being hacked again?

Always update your CMS, themes and plugins, use unique passwords with two-factor authentication, set up tested automated backups, cut unnecessary plugins and users, and check for vulnerabilities regularly. Prevention costs a fraction of the time that recovering a compromised site does.

Conclusion

A hacked website is a scare, but rarely a catastrophe if you act in the right order: check the signs, stop the bleeding, remove the problem, restore from a clean backup, recover your reputation and, if personal data is involved, handle the GDPR obligations. Then — the part that makes the real difference — close the door they came in through.

Because security isn't a one-off job: it's a check that repeats. Looking for vulnerabilities upstream, regularly, is what turns an emergency into an isolated episode instead of a recurring problem.