What to do if your website is hacked

• Website Security
• Updated: 4 October 2026
• About 11 min read

Incident response, step by step

1. 1

   Stay calm and verify the situation

   First, note down the symptom you have seen: what did you see, when, at which address, on which device? Take a screenshot. Is the problem really a compromise, or is it an expired certificate, a broken update or a third-party script? A few minutes of verification saves hours spent heading in the wrong direction. If there are other sites in the same hosting account, bear in mind that they may have been affected too.

   : Enlarge

2. 2

   Put the site into maintenance mode

   Take the site offline temporarily to stop visitors coming to harm and to stop the attacker continuing to use the site. The rule below returns a "503 Service Unavailable" response to everyone except your own IP address; this response tells search engines that the situation is temporary.

   .htaccess (Apache)

   # Add at the VERY TOP of the .htaccess file in the web root.
   # 203.0.113.10 is an example address; enter your own IP address.
   # A short plain-text message (for a styled page, show an HTML file
   # instead of the text: ErrorDocument 503 /bakim.html)
   ErrorDocument 503 "Our site is undergoing brief maintenance. Please try again later."
   
   RewriteEngine On
   RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
   RewriteCond %{REQUEST_URI} !^/bakim\.html$
   RewriteRule ^ - [R=503,L]
   
   <IfModule mod_headers.c>
       Header always set Retry-After "3600"
   </IfModule>

   On a site that takes payments, close the payment step first. Tell your hosting company what has happened; they may be able to help with access to the logs and with server-side scanning.

3. 3

   Record the evidence and the current state

   Before you start cleaning up, take a full copy of the site as it is right now: all the files (with their dates preserved), a database dump and all the logs you can get at (access, error, FTP, panel). This copy is not a clean backup; it is for finding the entry point and, if necessary, for use in legal proceedings. Store it off the server, in a separate and clearly labelled place; do not run the files inside it.

   Logs are deleted after a certain period, so do not put this step off.

   : Enlarge

4. 4

   Change all passwords and keys

   You do not yet know which account was compromised; change them all. Make the changes from a computer you are sure is clean.

   • The hosting panel and the account with the domain registrar.
   • FTP/SFTP and SSH accounts; delete accounts and SSH keys you do not recognise.
   • The database user's password (update the configuration file as well).
   • All of the site's administrator accounts; delete administrators you do not recognise.
   • Email accounts and SMTP passwords connected to the site.
   • The API keys in the configuration (payment, email, maps and so on) and the application's secret keys.

   End all open sessions. For passwords, see the guide Strong passwords and password managers.

5. 5

   Clean out malicious files and backdoors

   The most reliable clean-up is not to repair files one by one but to reinstall from a clean source:

   • Replace the files of the content management system, plugins and themes with clean copies downloaded from the official source.
   • For custom software, compare against the version in your source code repository or in a backup from before the attack; every file that is not in the repository and every difference is suspect.
   • There should be no script files in upload folders; remove any you find.
   • Check .htaccess, index.php and the configuration files line by line; look for added redirects and foreign code.
   • In the database, look for foreign scripts and links added to content, users you do not recognise and unfamiliar settings records.
   • Check the scheduled tasks (cron) and the redirect and email forwarding rules in the hosting panel.

   Do not rely on a signature-based scan alone; a backdoor the scanner does not recognise may be left behind. For the signs, see the guide File upload security and web shells.

   : Enlarge

6. 6

   Find and close the entry point

   If the site is reopened without finding out how the attacker got in, it will be compromised again by the same route. In the copy you saved, look at the creation and modification dates of the malicious files; examine the log entries from around that time.

   • Outdated software: Which plugin or library was out of date on the date of the attack?
   • Compromised account: Is there a login from an unfamiliar location in the FTP or panel log?
   • Upload form or code vulnerability: In the access log, which address did the request go to at the moment the malicious file was created?
   • Another site in the same account: Is there a forgotten trial installation or an old subdomain?
   • Infected computer: Could there be malware on the computer where the passwords are saved?

   If you have not been able to identify the entry point for certain, close all the possible routes: update all the software, remove unused components and disable execution in upload folders.

   : Enlarge

7. 7

   Consider restoring from a clean backup

   If you have a backup dating from before the attack that you are sure is clean, restoring the files from that backup is the quickest route. Points to watch:

   • The attack may be older than the moment it was noticed; confirm that the backup really dates from before the attack by checking the dates of the malicious files.
   • Restoring the database from an old backup wipes out the orders and records made in between. In most cases it is better to restore the files from the backup but keep the database and clean it.
   • Restoring from a backup does not close the vulnerability; the fixes and updates in the previous step are still needed.
8. 8

   Update, harden and reopen the site

   Before opening the site: update all software and plugins, delete the ones that are not used, fix the file permissions, remove unnecessary files from the web root and switch on two-factor authentication on administrator accounts. Then lift maintenance mode and check the site from different devices, without logging in, and by arriving from search engine results; some malicious redirects are shown only to certain visitors.

   In the first few weeks, check file changes and the logs every day. See Website backup and monitoring.

9. 9

   Get search engine and browser warnings removed

   If Google has detected malicious content on your site, a warning is shown in search results and in browsers. Verify your site in Google Search Console, fix the problems listed in the Security issues report and request a review from the same report. In the request, briefly describe what you found and how you fixed it. A review requested before the problem has been fixed is rejected and drags the process out.

   If foreign pages created under your site's name have been indexed, make sure those addresses return "not found" (404 or 410); they drop out of the index over time. If your site has ended up on email blocklists, follow each list's own removal process.

10. 10

    Inform those affected and, where required, the authorities

    If personal data such as user accounts, customer details or orders may have been affected:

    • Have users reset their passwords and tell them plainly what has happened: what occurred, which data may have been affected and what they need to do.
    • Under data protection law (e.g. the GDPR), the data controller has an obligation to report a personal data breach to the competent data protection authority and, where required, to the individuals concerned; under the GDPR the authority must be notified no later than 72 hours after becoming aware of the breach. Consult your legal adviser about the scope of the obligation.
    • If payment details may have been affected, inform your payment provider or your bank.
    • To report the crime, you can go to the police or the relevant law-enforcement cybercrime unit with the evidence you have saved.

    : Enlarge

11. 11

    Learn from the incident

    Write a short incident note: what happened, how was it noticed, what was the entry point, how long did it last, what was done? Then plan the lasting measures: an update routine, off-server backups, file integrity monitoring, two-factor authentication, personal accounts. For a ready-made list, use the Website security checklist guide.

Signs of a compromise

• Text, links, adverts or pop-ups on your pages that are not yours.
• Visitors being redirected to other sites, especially those arriving from a search engine or on a phone.
• A "deceptive site" or "malware" warning in the browser; a warning or foreign-language titles under your site in search results.
• A security issue notification in Google Search Console; a large number of pages in the index that are not yours.
• Administrator or FTP accounts you do not recognise; changed passwords.
• Unfamiliar files on the server, changed dates, unusual CPU and email usage.
• An abuse, spam or malicious content notice from the hosting company; the account being suspended.
• Messages from customers saying "I received a strange email from you" or "there is a suspicious transaction on my card".

What not to do

• Do not delete without taking a copy: The evidence needed to find the entry point is lost.
• Do not delete only the visible file and leave it at that: There is usually more than one backdoor, and the vulnerability is still there.
• Do not change passwords from a computer that may be infected.
• Do not run the malicious files, and do not open them in the browser out of curiosity.
• Do not hide the problem: Failing to inform affected users damages both trust and your legal position.
• Do not pay unknown people who demand a ransom or a "cleaning fee".
• Do not request a review before the problem has been fixed.

When should you bring in a specialist?

• If sensitive data such as personal data, payment details or health data may have been affected.
• If you cannot find the entry point, or the site is compromised again after being cleaned.
• If you suspect that the whole server (not just the site) has been compromised; in that case the server may need to be rebuilt from scratch.
• If you are thinking of starting legal proceedings; it is important that the evidence is preserved correctly.

Frequently asked questions

Related guides

• File upload security and web shellsSecure upload rules, disabling execution in the upload folder, signs of a web shell and what to do if you find one.
• Website backup and monitoringFile and database backups, restore drills, file integrity, logs and uptime monitoring.
• Website security checklistWeekly, monthly and yearly tasks; every item links to the relevant guide, and the list is printable.
• What is ransomware? The 3-2-1 backup ruleHow to protect yourself against ransomware, the 3-2-1 backup rule and what to do during an attack.