My website has been hacked: what to do step by step (and how to stop it happening again)

You open your website and a page in another language appears, Google shows a security warning next to your name, or a customer writes to tell you they were redirected to a gambling site. Finding out your website has been hacked is deeply unpleasant, and the natural reaction is to rush: delete everything, reinstall in a panic or pay the first person who promises to fix it within the hour.

Take a breath. A hack can almost always be fixed, but the order in which you act matters a great deal. In this guide I explain how to confirm you’ve been attacked, what to do in the first few hours, how to clean up your website, how to win back Google’s trust, when you’re legally required to notify the Spanish Data Protection Agency (AEPD) and, above all, how to stop it from happening again.

Not every attack is obvious. Some deface the home page so you’ll notice; others try to stay hidden for as long as possible so they can exploit your website in the background. These are the most common signs:

• Strange redirects to gambling, pharmacy or adult websites, sometimes only on mobile or only when arriving from Google.
• Pages you didn’t create, often in other languages, that show up when you search site:yourdomain.es on Google.
• Security warnings in search results, or a red browser screen when trying to visit.
• Admin users you don’t recognise, or passwords that suddenly stop working.
• Your host warns you about unusual resource usage or mass email sending, or suspends the account outright.
• Your emails start bouncing or landing in spam because your server is being used to send spam.
• Recently modified files nobody has touched, or odd code at the top of files.

If you spot one or more of these signs, assume there’s a problem until proven otherwise. Waiting to see whether it sorts itself out is the worst strategy: the longer it goes on, the further the infection spreads and the more your reputation suffers.

The goal of the first few hours isn’t to make the website perfect, but to contain the damage, cut off the attacker’s access and preserve the information you need to understand what happened. Follow this order:

1. 1Document what you see: take screenshots, note the time and save the affected URLs. They’ll be useful for your host, for whoever helps you with the clean-up and, if needed, for a police report or a breach notification.
2. 2Change every password from a device you know is clean: hosting panel, website admin, FTP or SFTP, database, email and domain registrar. Turn on two-step verification wherever you can.
3. 3Tell your host: many providers have scanning tools, access logs and backups you can’t see. Besides, it’s better they hear it from you than from an automated alert.
4. 4Put the website into maintenance mode if it’s harming your visitors (redirects, malicious downloads or fake forms). Being offline for a few hours is better than continuing to infect people.
5. 5Find your backups and work out the date of the latest one you believe is clean. Don’t restore yet: first you need to know when the infection started.

Once the situation is contained, it’s time to clean up. There are two routes and they’re often combined. The first is to restore a backup from before the infection, update everything immediately and close the vulnerability: it’s quick if you have reliable backups and know when the attacker got in. The second is to clean the website by hand, which takes more work but is necessary when there are no clean backups or the infection is old.

A thorough clean-up usually includes:

• Reinstalling the core of the content management system (WordPress, for example) from the official source, without reusing its files.
• Reviewing plugins and themes: removing the ones you don’t use, reinstalling legitimate ones from their source and distrusting any “nulled” version or anything downloaded from dubious sites.
• Looking for suspicious or modified files, obfuscated code and executable files in folders where they don’t belong, such as the uploads folder.
• Checking the database: unknown admin users, content injected into pages and posts, and hidden redirects.
• Checking scheduled tasks, the .htaccess file and the server configuration.
• Regenerating the application’s security keys and closing all open sessions.

The most important thing is to identify how the attacker got in: an outdated plugin, a leaked password, a vulnerable form or a forgotten FTP account. If you clean up but don’t close the door, reinfection usually follows within days.

When Google detects that a website has been hacked or is distributing malware, it may show warnings in search results or a warning page in the browser before people get in. That sinks traffic and trust very quickly, so you also need to act on this front:

1. 1Verify your website in Google Search Console if you haven’t already. It’s free and it’s the channel Google uses to warn you about these problems.
2. 2Open the Security issues report: there you’ll see what Google has detected and examples of affected URLs.
3. 3Clean the website completely before taking the next step. Requesting a review while the problem is only half fixed just delays the next one.
4. 4Once it’s clean, request a review from the report itself, explaining what you did to fix it.
5. 5Deal with any junk pages that were indexed: make them return a 404 or 410 error and, if there are many, use the URL removal tool to speed up their disappearance.

Take the chance to check the performance report as well: if you suddenly appear for searches that have nothing to do with your business, that’s a sign of injected content you haven’t cleaned up yet.

This is the step many businesses overlook. If your website stores personal data (shop customers, contact forms, registered users, bookings) and the attack may have affected it, you’re dealing with a personal data breach. Article 33 of the GDPR requires you to notify the supervisory authority, which in Spain is the Spanish Data Protection Agency (AEPD), within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people’s rights and freedoms.

In practice, this means:

• Assessing the risk: what data has been exposed, how many people are affected and what the consequences could be for them.
• Notifying through the AEPD’s online portal if there is a risk. If you don’t have all the information within 72 hours, you can send an initial notification and complete it later; the Agency explains this on its page about notifying personal data breaches, where it also offers tools to help you decide.
• Informing the people affected when the risk is high, as Article 34 of the GDPR requires, so they can protect themselves (for example, by changing their passwords).
• Documenting the breach internally, whether or not you notify it: what happened, what effects it had and what measures you took.

If you want to review the rest of your website’s data protection obligations, they’re in the guide on how to comply with GDPR on your website. What matters here is not letting the deadline slip because you’re focused only on the technical side.

You don’t have to handle a hack alone. Besides your host and whoever maintains your website, in Spain you can call 017, the cybersecurity helpline run by INCIBE (the Spanish National Cybersecurity Institute): a free, confidential service that advises businesses, freelancers and individuals when they suffer an incident. On incibe.es you’ll also find guides and resources aimed at businesses.

If the attack involves extortion, theft of money or identity fraud, also file a report with the National Police or the Guardia Civil. And if someone demands a ransom to give you back control of your website or your data, don’t pay without getting advice first: paying doesn’t guarantee you’ll get anything back.

With the website clean, now comes the part that really makes the difference: making sure it doesn’t happen again. Attacks on small business websites are rarely personal; they’re usually automated and look for well-known open doors. Closing them is more about consistency than budget:

• Keep everything updated: core, plugins, themes and server software. Known vulnerabilities are one of the most common ways in.
• Less is more: remove plugins and themes you don’t use and avoid ones from dubious sources.
• Unique passwords and two-step verification on every login, backed by a password manager.
• Automatic backups, stored off the server and with several versions, and check from time to time that they can actually be restored.
• Minimum access: everyone gets their own user with only the permissions they need. No sharing the admin account.
• SFTP instead of FTP, and a serious host with isolation between accounts and protection against attacks.
• Monitoring: alerts if the website goes down, if critical files change or if unexpected new content appears.

All of this is exactly what good website maintenance includes. If you’re unsure whether it’s worth it, in the article on why your website needs maintenance I explain what it covers and which risks it prevents.

The difference between an afternoon’s scare and a week of chaos usually comes down to preparation. You don’t need a big-company protocol: a simple document, stored somewhere other than the website, with the essentials to hand is enough.

1. 1Logins: hosting, domain, website admin, email and Search Console, and who holds each one.
2. 2Contacts: your host’s support, the person who maintains the website and INCIBE’s 017 helpline.
3. 3Backups: where they are, how often they run and how to restore them.
4. 4Personal data: what data your website stores and who decides whether the AEPD needs to be notified.

Review this document a couple of times a year. If you ever need it, you’ll be glad you did.

Having your website hacked is a bitter pill, but it doesn’t have to be a disaster. If you stay calm, contain the damage without destroying the evidence, clean up thoroughly while closing the way in, win back Google’s trust and meet your data protection obligations, you can be back to normal in a short time. And with consistent maintenance, the chances of it happening again drop dramatically.

I’m Elmar Mamedova, a full stack developer based in Málaga, and part of my work is looking after websites so they never reach this point, and rescuing them when it has already happened. If your site shows any of these symptoms or you want to harden it before anything goes wrong, tell me about it and we’ll go through it together.