Website Hacked — What to Do? First Aid in 9 Steps

If your website has been hacked, the order of steps is what counts: first stop the attacker's access, then limit the damage, then restore cleanly — and only at the very end tidy up and prevent. The most common mistake is to panic and immediately "delete something": that destroys traces you will need later, and the attacker's backdoor usually stays in anyway.

This article walks you through the emergency in nine steps — from the first minute to the question of how to prevent a second incident. The good news up front: the vast majority of hacked business websites are not a targeted attack but automated mass-produced attacks that exploit outdated software. That doesn't make the incident any nicer, but it makes it very fixable.

How to recognize a hack in the first place

Many hacks go unnoticed for weeks because the homepage looks normal. Typical warning signs:

Unknown subpages: a Google search for site:yourdomain.com suddenly shows pages you never created — often spam for medication, betting providers, or counterfeit brand products, sometimes in foreign languages.
Redirects: visitors land on dubious third-party sites, sometimes only when arriving via Google search or only on mobile — the owner never sees any of it.
Browser and search warnings: the browser shows a red warning page before your site, or Google flags it in the search results as possibly hacked.
Ranking collapse: your positions drop for no apparent reason, because search engines factor the spam content into their assessment.
Technical anomalies: the site suddenly becomes slow, storage usage at your host climbs, unknown administrator accounts or modified files appear.
Mail from your host: many incidents are first noticed by the hosting provider, who sends a warning because of spam sending or malware reports — or suspends the site.

Even one of these signs justifies a thorough check.

The first-aid plan in 9 steps

1. Stay calm and document

Take screenshots of everything suspicious — unknown pages, redirects, warning messages — and note the date and time. That helps later with root-cause analysis, in dealings with your host, and in case the incident has to be reported. Delete nothing at this stage.

2. Change all credentials

The attacker has at least one access — take all of them away: the website's admin access, the hosting customer account, FTP/SFTP, the database, and, to be safe, the email inbox through which these accesses can be reset. New, long, unique passwords, ideally from a password manager. Also check whether unknown user accounts have been created, and remove them.

3. Take the site offline if necessary

If the website is actively spreading malware or redirecting visitors to scam sites, take it off the net temporarily — a plain maintenance page is better than a site that endangers your visitors and damages your reputation. Your host can help with this without evidence being lost.

4. Contact your host

Your hosting provider sees more than you do: server logs, the time of the break-in, affected files. Many hosts have standard procedures for compromised websites, provide log files, and can tell you whether other customers or neighboring systems are affected. The earlier you call, the more log data still exists.

5. Identify malware and foreign content

Now comes the investigation: which files were changed, which subpages created, which backdoors hidden? Clues come from files with recent modification dates, unknown scripts in upload folders, and your host's log files. On systems with a database, the content and accounts stored there belong under scrutiny too. If you don't feel up to this, bring in a professional at this point — half-removed backdoors are the main reason for repeat incidents.

6. Restore from a clean backup

The most reliable way back is a backup from a point in time before the break-in. That is why step 4 mattered: without the approximate time of the intrusion, you risk restoring an already infected backup. After restoring: re-add content created since then manually — never "copy over" files from the hacked state.

7. Close the gap

A restored backup with the same old vulnerability will be hacked again within days. So: bring the system, design templates, and all extensions fully up to date, completely remove what is no longer needed, and enable two-factor authentication for all admin accesses. Automated attacks specifically look for known vulnerabilities in outdated extensions — that is exactly where most break-ins come from.

8. Check Google Search Console and blocklists

Sign in to Google Search Console (if you haven't yet: set it up now) and check the sections for security issues and manual actions. If your domain is on a warning list, you can request a review right there after the cleanup — only then do browser warnings and search flags disappear. Also check that the spam subpages vanish from the Google index.

9. Check whether customers must be informed

If personal data was processed through the website — contact forms, customer accounts, orders — check whether data may have leaked through the incident and whether data protection notification duties toward the supervisory authority and information duties toward the people affected exist under the GDPR. That depends on the individual case and is partly bound to deadlines — clarify it promptly and, when in doubt, with expert support instead of sitting it out.

Note: This article is technical guidance, not legal advice. Whether and how an incident must be reported is something to clarify with your data protection officer or a specialized law firm.

Prevention: making sure there is no second time

The causes of almost all website hacks are banal — and the prevention is correspondingly banal:

Updates, updates, updates. Outdated systems and extensions are the number one entry point. If you don't want to update monthly, you need someone who does.
Strong, unique passwords for every access, managed in a password manager. A password that has already leaked somewhere else is not a password.
Two-factor authentication for all admin and hosting accesses — the single most effective step against stolen passwords.
Regular backups, automatic, with multiple versions and at least one copy outside the web server. A backup sitting next to the hacked site gets hacked along with it.
Less is more: every installed extension is potential attack surface. Whatever isn't needed gets removed.

The honest fundamental question: does your website even need an attack target?

To close, a thought that often gets lost in the cleanup: most hacks on business websites only work because a full content management system with a database, a login form, and dozens of extensions is running there — for a website whose content changes twice a year. A statically built website has none of that: no database, no login exposed to the internet, no extensions with security holes. There is simply almost nothing to hack, and updates all but disappear.

That is exactly why we build our client websites statically — you can see examples in the Showroom. If your website has to be rebuilt after an incident anyway, it is worth checking whether this is the right moment to switch; we broke down what a rebuild costs transparently in the article on website rebuild costs.

Frequently Asked Questions

How do I know how the attackers got in?

Usually through one of three doors: outdated software with a known vulnerability, stolen or weak credentials, or an insecure extension. Your host's server logs and the modification dates of the manipulated files narrow down the point in time — from that, the path can often be reconstructed. Without this analysis, any cleanup remains patchwork.

Is it enough to delete the visible spam pages?

No. Visible spam content is the symptom, not the cause. Attackers almost always leave hidden backdoors behind through which they return after the "cleanup". Without restoring from a clean backup or a thorough forensic check, the site is not clean.

How long does it take until Google removes the warning?

After a complete cleanup, you can request a review in Google Search Console. Processing typically takes a few days; the prerequisite is that really all malicious content has been removed — otherwise the request is rejected and the process starts over.

Do I have to report the incident?

That depends on whether personal data may be affected and how high the risk for those affected is. Check this promptly — data protection notification duties are partly bound to deadlines — and get expert advice when in doubt. A pure defacement of a website with no data involved is judged by different standards than a compromised customer account system.

Does a security plugin protect me reliably?

Security extensions can make attacks harder and raise the alarm, but they don't cure outdated software and are themselves code that can have vulnerabilities. The order of priority remains: up-to-date software, strong access with two-factor authentication, working backups — and only after that, additional protective layers.