How do I fix a hacked website?
Step 1: Quarantine the site
Google's web.dev hacked site guide starts with stopping the damage. Take the site offline by stopping the web server, or point your DNS to a static page that returns a 503 status. Ideally that 503 page should be served from somewhere other than the compromised server.
Two things are not enough on their own. Returning a 4xx or 5xx code from the infected server does not protect visitors, and a robots.txt disallow only blocks search engine crawlers, not people.
- Tell your hosting company. If their systems were also affected, it helps them work out the scope.
- Check every user account. Note and delete any accounts the attacker created.
- Change every password: FTP, database, server administrator and CMS logins.
The NCSC also recommends turning on 2-step verification for important accounts and using a standard, non-administrator account for day-to-day work.
Step 2: Check Search Console
Verify the site in Search Console if you have not already. Open the Security issues report. It lists problems under hacked content, malware and unwanted software, and social engineering, with sample URLs for each. The samples are not a complete list, so treat them as a starting point. Also check the Manual actions report.
To find spam pages the attacker added, Google suggests running site-restricted searches for spam terms that should not be on your site.
Step 3: Find how they got in
If you clean the site without fixing the cause, it will probably be hacked again. Google's guide lists four common causes, the last of which covers open redirects and SQL injection:
- An infected administrator computer. Scan every device used to manage the site with more than one antivirus tool.
- Weak or reused passwords. Look in your logs for repeated failed admin logins and note when they started, because that tells you which backups are likely to be clean.
- Outdated software. Check the version of your server software, CMS, themes and plugins against published security advisories.
- Open redirects that send visitors to other sites.
- SQL injection. Search your database for ordinary text fields that now contain iframes or scripts.
Step 4: Clean or rebuild
What you do depends on your backups:
- Clean, current backup: restore it, apply all updates, remove unused components, fix the vulnerability and change all passwords.
- Clean but old backup: keep a copy of the infected site for reference, restore the backup, update everything, then carry over only content you have checked is clean.
- No backup: make two copies of the infected site, clean the copy rather than the live server, delete files the attacker created and clean infected database records.
Google recommends a clean installation of your software rather than just an upgrade, because leftover files can reinfect the site. Remove plugins and widgets you no longer use. If personal data may have been taken, review your legal obligations before you go further.
For spam pages the attacker created, make them return a 404 and use the Remove URLs tool in Search Console. Do not use that tool on your own good pages that were only damaged.
Step 5: Request a review
Before you ask, confirm the attacker's changes are gone, the vulnerability is fixed and the clean site is back online. Check your homepage and any modified URLs with a tool such as cURL, and make sure they are not blocked by robots.txt or a noindex directive.
Then open the Security issues report and select Request Review. Google says a good request explains the exact problem, the steps you took to fix it and the result. You will get an email when the request is received and when the review is complete. Asking before the problem is fully fixed makes the site stay flagged for longer.
To lower the risk of it happening again, Google advises regular automated backups, keeping all software up to date, checking third-party plugins before you install them, and strong passwords. The NCSC adds that backups should be kept on a device that is not left connected, and that you should check you can actually restore them.
Once the site is back up, our Security Audit can check your HTTP security headers, DNS, SPF, DKIM and DMARC records, and look for software versions with known CVEs. Its scoring was built to mirror Mozilla HTTP Observatory.
Sources
- web.dev: Quarantine your site
- web.dev: Identify the vulnerability
- web.dev: Clean and maintain your site
- web.dev: Request a review
- Search Console Help: Security issues report
- Search Console Help: Why is my site labelled as dangerous in Google Search?
- NCSC: Secure your important online accounts
- NCSC: Backing up your data
Frequently asked questions
How long does it take Google to remove a hacked warning?
It depends on the problem. Google's web.dev guide says a review for hacked spam can take up to several weeks, a malware review a few days, and a phishing review about a day. If the review is approved, browser and search warnings should be removed within 72 hours. Do not submit another request until you have a decision on the first, and only request a review once the problem is fully fixed, because asking too early can lengthen the next review.
Will my rankings come back after I clean a hacked site?
Not always straight away. Google's help page on sites labelled as dangerous says warnings can take a day or two to clear after an approved review, and rankings may stay affected for a while. Google's web.dev guide recommends using the Remove URLs tool only for spam pages the attacker created, and those pages should return a 404.