How to remove malware from a website (2026)
Quick Answer
To remove malware from a website, first take the site out of harm’s way, preserve evidence, and confirm what has been changed. Then restore from a known-clean backup or manually replace infected core files, remove malicious code, reset credentials, update all software, and verify that search engines and security tools no longer detect compromise. If the attacker had server-level access, payment data may have been exposed, or you cannot identify every change, stop and use a qualified incident response or website security professional.
Safety first
- Treat a hacked website as a possible data breach until proved otherwise, especially if it stores customer, staff, or payment information.
- Do not enter new credentials from a computer you suspect may be infected; use a clean device first.
- Preserve backups and logs before editing or deleting files, because evidence may be needed for professional investigation, insurer requirements, or breach handling.
- If the site handles card payments, follow your payment provider’s incident procedures and stop self-cleaning if they require qualified forensic support.
- Avoid downloading and executing unknown files from the compromised server on your local machine.
- Restrict public access if the site is actively serving malware, phishing pages, or harmful redirects to protect visitors.
When to call a professional: Stop and consult a qualified website security professional, incident responder, or your managed hosting provider if any of these apply: you suspect server or root compromise; the site stores or processes personal, health, or payment data; payment pages may have been tampered with; you cannot identify the initial entry point; malware returns after one clean-up; backups are missing or may also be infected; the site is business-critical and downtime is costly; or you need help with evidence preservation, breach assessment, or search blacklist removal.
Overview
Website malware is usually introduced through outdated content management systems, plugins or themes, stolen passwords, insecure hosting, vulnerable custom code, or an infected administrator computer. The safest approach is not to delete files at random, because that can break the site while leaving the attacker’s access in place. Instead, contain the incident, make a full backup of the current state for evidence and recovery, identify the scope of compromise, clean the site from a known-good source, and then harden everything so the infection does not return. In practice, that means putting the site into maintenance mode or otherwise restricting public access, checking hosting and application logs, comparing current files against clean originals, reviewing user accounts, and scanning both files and the database for injected code, rogue admin users, spam pages, or malicious redirects. For many sites, restoring a clean backup taken before the compromise is faster and safer than hand-editing infected files, provided you also patch the original weakness. After cleaning, rotate all passwords and keys, update the CMS and extensions, check scheduled tasks and server configuration, and request a review if Google or another service has flagged the site. If you handle customer data or online payments, treat the incident as a potential data breach and escalate promptly.
Who this is for
Website owners, administrators, developers, and small businesses troubleshooting a hacked or malware-infected website on shared hosting, VPS, or managed CMS platforms.
What you’ll need
- administrator access to the hosting control panel, server, CMS, and domain/DNS account
- access to recent backups and file/database restore tools
- clean copies of the CMS core, plugins, themes, or application code from original sources
- access to hosting logs, malware scan results, and any search engine security warnings
- a clean local computer and browser for admin work
- a secure place to store notes, timestamps, and copies of affected files
Before you start
Use a clean device, because an infected administrator computer can reintroduce malware or leak new passwords. Record what was observed: redirects, spam pages, warnings, changed files, new users, and relevant timestamps. Check whether the site processes personal or payment data, because that changes your reporting and professional support needs. Do not overwrite evidence before saving a full file and database backup of the compromised state.
Step-by-step
- 1
Contain the incident and preserve evidence
Put the site into maintenance mode, restrict access by IP, or temporarily disable the affected application if needed. Save a full backup of website files, the database, and available server logs before making changes. If your host provides snapshots, preserve the most relevant one.
Why: Containment limits further harm to visitors and search visibility, while preserved evidence helps you find the entry point and supports any later professional investigation or breach response.
- 2
Confirm the scope of compromise
Check for symptoms such as defacements, spam pages, injected links, redirects, browser warnings, rogue admin users, changed configuration files, unfamiliar scheduled tasks, or unexpected outbound mail. Review web server, CMS, and authentication logs for suspicious logins, file changes, or requests to vulnerable components.
Why: You need to know whether the problem is limited to website files, includes the database, or extends to the server or hosting account. Cleaning only one layer often leads to reinfection.
- 3
Identify the likely entry point
Check whether the CMS core, plugins, themes, server software, or custom code were outdated. Review user accounts for weak, reused, or stolen credentials and disable anything unfamiliar. Check file permissions, exposed backup files, and any recent code uploads or changes made through the admin editor, FTP, or SSH.
Why: Removing malware without closing the original weakness usually results in the attacker coming back.
- 4
Restore or replace compromised code from known-clean sources
If you have a verified clean backup from before the compromise, restore the site from that backup, then immediately patch software and credentials. If not, replace CMS core files, plugins, themes, and application files with fresh copies from the original vendor or repository, keeping only necessary custom content after inspection. Review the database for injected scripts, spam content, rogue users, malicious options, or modified configuration values.
Why: Known-good files are more reliable than trying to spot every backdoor manually. Malware often hides in multiple locations and can survive partial clean-ups.
- 5
Remove persistence and reset access
Delete rogue administrator accounts, unknown SSH or FTP users, unauthorised API tokens, and suspicious scheduled tasks or cron jobs. Rotate all passwords for hosting, CMS admins, database users, FTP/SFTP, SSH, email accounts tied to the domain, and the domain registrar account. Replace application secrets and salts where the platform supports it.
Why: Attackers often leave backdoors or stolen credentials behind. If you do not remove persistence, the site can be compromised again even after files are cleaned.
- 6
Patch, harden, and scan again
Update the CMS, plugins, themes, server software, and any libraries or dependencies. Remove unused extensions, disable file editing in the CMS if appropriate, enforce strong unique passwords and multi-factor authentication where available, and confirm least-privilege permissions. Run fresh malware scans and review the site manually in a browser and with developer tools.
Why: Patching and hardening reduce the chance of repeat compromise. A second check helps confirm that no malicious code, redirects, or warnings remain.
- 7
Check external warnings and request review if needed
If Google Search Console, your host, or a browser safe browsing service flagged the site, fix the issue first and then follow their review or reinclusion process. Monitor logs, file integrity alerts, and search indexing closely for a period after clean-up.
Why: Security warnings can continue even after the site is cleaned until the relevant service verifies the fix. Monitoring helps catch residual or repeat compromise quickly.
Why this works
Website malware survives by combining an initial weakness, malicious payloads, and a way back in. Effective removal breaks all three: it removes the payload, closes the vulnerability or stolen-access route, and verifies externally that the site is no longer serving harmful content.
Common mistakes to avoid
- Deleting suspicious files without taking a backup or saving logs first
- Changing only the CMS password and forgetting hosting, database, registrar, SSH, or email credentials
- Restoring a backup but not patching the vulnerability that allowed the hack
- Trusting a site is clean because the homepage looks normal while hidden spam pages or redirects remain
- Cleaning website files but not checking the database, cron jobs, server configuration, or rogue users
- Working from an infected administrator computer
Troubleshooting
The malware returns after clean-up
Assume a missed backdoor, stolen credential, or unpatched vulnerability. Review all admin and hosting access, cron jobs, uploaded files, database injections, and outdated extensions. If you still cannot find the source, escalate to a professional.
Google or browsers still warn that the site is dangerous
Confirm that all malicious content is removed, then use the relevant review process, such as Search Console for Google-related warnings. Keep records of what was cleaned in case the review asks for detail.
You cannot tell which files are legitimate
Compare against clean vendor originals or restore a known-clean backup. For custom code, use version control or a developer-maintained source copy. Avoid guessing in production.
The site breaks after replacing files
Restore from the backup you took at the start, then re-clean more carefully. Check for version mismatches between the application, plugins, themes, and database schema.
Spam pages remain indexed after the site is clean
Remove the malicious pages from the site, return correct HTTP responses for deleted URLs, update your sitemap if needed, and use the search engine’s webmaster tools to monitor reindexing.
Compare your options
Restore from a known-clean backup
Best for: Sites with reliable backups from before the compromise
Pros: Usually faster, more complete, and less error-prone than manual clean-up
Cons: You can lose recent content or orders, and the site may be reinfected if the original weakness is not fixed
Manual clean-up and file replacement
Best for: Sites without usable clean backups or with important recent data that must be preserved
Pros: Can preserve the latest content and allows targeted investigation
Cons: Easy to miss hidden malware or persistence mechanisms; requires stronger technical skill
Professional incident response or website security service
Best for: Business-critical sites, repeat infections, server-level compromise, or possible data exposure
Pros: Better forensic investigation, safer remediation, and clearer breach-response support
Cons: Higher cost and may require temporary service restrictions during investigation
| Option | Best for | Pros | Cons |
|---|---|---|---|
| Restore from a known-clean backup | Sites with reliable backups from before the compromise | Usually faster, more complete, and less error-prone than manual clean-up | You can lose recent content or orders, and the site may be reinfected if the original weakness is not fixed |
| Manual clean-up and file replacement | Sites without usable clean backups or with important recent data that must be preserved | Can preserve the latest content and allows targeted investigation | Easy to miss hidden malware or persistence mechanisms; requires stronger technical skill |
| Professional incident response or website security service | Business-critical sites, repeat infections, server-level compromise, or possible data exposure | Better forensic investigation, safer remediation, and clearer breach-response support | Higher cost and may require temporary service restrictions during investigation |
Alternatives
- Migrate the site to a fresh, fully patched hosting environment and import only verified clean content
- Use a managed hosting or managed CMS provider with malware cleanup and monitoring included
- Rebuild the site from version-controlled source and a clean database export after review
Pro tips
- Keep one offline or immutable backup strategy if your platform supports it, so a compromise cannot silently alter every backup.
- Use file integrity monitoring or version control to spot unauthorised changes faster.
- Remove unused plugins, themes, and sample applications; inactive components can still be vulnerable.
- Check administrator email accounts and the domain registrar account, because control of those can let an attacker regain access.
- Document every change you make during clean-up so you can roll back or explain the incident later.
Legal & regulatory notes
If personal data may have been accessed, altered, or exfiltrated, data protection and breach-notification duties may apply depending on your country and sector. If you take payments, card scheme or payment processor rules may also require specific incident handling. Use this guide for technical containment and clean-up only; get legal, regulatory, or professional compliance advice for breach reporting and evidence handling.
What this guide does not cover: This guide gives general website malware clean-up and containment advice. It does not provide platform-specific commands for every CMS or hosting environment, full digital forensics, legal breach-reporting advice, PCI or other compliance determinations, or guaranteed detection of every backdoor or stolen datum.
Cost considerations
Costs vary with the site’s complexity, whether clean backups exist, and whether the compromise reached customer data, payment systems, or the whole server. The cheapest-looking option is not always the lowest-cost overall: incomplete clean-up can lead to repeat infections, lost search visibility, reputational damage, and higher recovery costs later.
Frequently asked questions
Can I just delete the suspicious file and move on?+
Usually not. Website malware often includes multiple files, injected database content, altered users, and a way back in. Remove the payload and fix the root cause together.
Is restoring a backup enough?+
Only if the backup is from before the compromise and you also patch the vulnerability, remove stolen access, and verify that no warnings or backdoors remain.
How do I know whether the database is infected too?+
Look for injected scripts, spam posts or pages, unfamiliar administrator users, changed options, or malicious redirects stored in content and settings. Many compromises affect both files and the database.
Should I tell my hosting company?+
Yes, especially if you suspect account-level or server-level compromise, outbound spam, abuse complaints, or repeated reinfection. Hosts can often provide logs, snapshots, and containment help.
When is manual clean-up too risky?+
If the site handles payments or sensitive personal data, if you suspect root or server compromise, if the infection keeps coming back, or if you cannot confidently identify all changes, use a qualified professional.
Sources & references
Guidance on this page is traced to documented sources. Last checked 25 September 2026.
- Google Search Console Help - Fix hacked site · official
Supports the overall clean-up flow: quarantine, contact hosting provider, assess damage, identify vulnerability, clean the site, request review, and monitor.
- NIST Computer Security Incident Handling Guide · government
Supports incident handling principles such as containment, evidence preservation, eradication, recovery, and post-incident learning.
- National Cyber Security Centre - Mitigating malware and ransomware attacks · government
Supports practical prevention and recovery measures including patching, backups, least privilege, and reducing reinfection risk.
The core response process changes slowly, but platform-specific attack methods, plugins, review tools, and hosting controls change regularly.