How to Fix a Hacked Website Safely
A hacked website can expose customer data, damage search visibility, and trigger browser or antivirus warnings.
This guide explains how to fix hacked website safely, contain the breach, remove malicious code, and restore your site with minimal risk.
The key is to work methodically: preserve evidence, stop active abuse, clean the infection, then harden the environment so the attacker cannot return.
First, contain the damage
Before changing files or reinstalling anything, reduce the attacker’s access and protect visitors.
A rushed cleanup can overwrite evidence, miss a hidden backdoor, or reinfect a fresh install.
- Put the site in maintenance mode if possible.
- Change passwords for hosting, FTP/SFTP, SSH, CMS admin, database, and email accounts linked to the site.
- Enable two-factor authentication on all accounts that support it.
- Contact your hosting provider if you see server-level compromise, unusual outbound traffic, or unfamiliar accounts.
- Take a full backup of the current infected state before deleting anything, so you can review files and logs later.
If the site handles payments, customer records, or sensitive data, assume the incident may have regulatory implications and involve legal or compliance support early.
Identify how the website was compromised
Cleaning the visible malware is not enough if the original entry point remains open.
Attackers usually exploit weak credentials, outdated software, vulnerable plugins, insecure themes, or exposed server services.
Common intrusion paths
- Reused or stolen passwords on WordPress, cPanel, or hosting logins.
- Outdated CMS core files, plugins, or themes with known CVEs.
- Malicious file uploads through forms, media libraries, or poorly configured permissions.
- Compromised developer accounts, Git repositories, or deployment pipelines.
- Infected local computers used to upload legitimate-looking files.
Review access logs, recent file changes, admin user additions, and plugin install history.
If you can identify the vector, you can close it before restoring the site.
Scan the site for malware and backdoors
A safe cleanup requires both automated scanning and manual review.
Security scanners can flag known patterns, but attackers often hide backdoors in legitimate-looking files, database entries, scheduled tasks, or unused directories.
What to inspect
- Core files for unexpected modifications.
- Theme and plugin directories for injected PHP, obfuscated JavaScript, or unusual includes.
- Uploads folders for executable files that should never be there.
- .htaccess, web.config, cron jobs, and server startup scripts.
- Database content for injected redirects, spam links, or hidden admin users.
Look for common obfuscation techniques such as base64 encoding, long random variable names, eval-like execution, or scripts that pull code from remote domains.
Also review file timestamps, since newly created files in old directories are often suspicious.
Restore from a known-good source when possible
The safest way to fix hacked website safely is often to replace compromised code with clean files from a trusted source.
If you have verified backups from before the intrusion, use them selectively rather than restoring blindly over the entire environment.
Prefer these sources, in order of trust:
- Fresh copies of CMS core files from the official project.
- Original theme and plugin packages from the vendor or repository.
- Clean database backups taken before the compromise.
- Filesystem backups with confirmed integrity checks.
Before restoring, compare backup dates with the suspected infection window.
A backup taken after the attacker gained access may already contain malicious code.
Remove malicious files and repair the database
Delete malicious files only after you have documented them.
In many cases, the better approach is to replace entire core directories rather than trying to patch individual infected files.
Safe cleanup workflow
- Export or archive suspicious files for analysis.
- Replace CMS core files with clean versions.
- Reinstall plugins and themes from trusted sources.
- Remove unknown admin users, API keys, cron jobs, and scheduled tasks.
- Search the database for spam links, injected scripts, and phishing redirects.
- Clear all caches, including page cache, object cache, CDN cache, and browser cache.
If the site is built on WordPress, Magento, Joomla, Drupal, or another CMS, use platform-specific cleanup tools where available.
For custom applications, check application logs and deployment history to determine whether the compromise is in the codebase, configuration, or database.
Check for SEO spam and search engine abuse
Many attackers inject hidden pages, doorway pages, and spam content to rank for unrelated terms.
This can trigger Google Safe Browsing warnings, manual actions, or index bloat that lingers after the site is cleaned.
Inspect the site for:
- Spam pages not linked from your navigation.
- Foreign-language keyword stuffing.
- Hidden text or cloaked content shown only to search engines.
- Malicious redirects on mobile or specific referrers.
- Injected canonical tags, meta refresh rules, or rogue sitemaps.
After cleanup, review Google Search Console for security issues, manual actions, and indexed URL anomalies.
Submit a clean sitemap only after you are confident the site is free of malicious content.
Harden the environment to prevent reinfection
Cleaning a site without fixing the weakness that enabled the attack usually leads to repeat compromise.
Hardening should cover accounts, software, server settings, and monitoring.
High-value security controls
- Update the CMS core, plugins, themes, and server packages.
- Remove unused extensions, user accounts, and dormant admin roles.
- Use least-privilege file permissions and separate deployment credentials.
- Enforce strong passwords and password managers for all admin users.
- Enable a web application firewall, such as Cloudflare WAF or a hosting-level WAF.
- Restrict file editing from the CMS dashboard if the platform supports it.
- Set up malware monitoring and file integrity alerts.
Also review server exposure: close unused ports, disable risky services, and ensure SSH keys and credentials are rotated if compromise may have reached the host.
Recover trust with users, browsers, and search engines
Once the site is clean, recovery is not only technical.
Visitors may have seen warnings, and search engines may temporarily distrust affected URLs.
Fast, clear remediation helps restore confidence.
- Publish a brief incident notice if customer impact was possible.
- Reset passwords for all users after the breach.
- Notify payment processors or partners if required.
- Request a review in Google Search Console if you had a security warning or manual action.
- Monitor server logs, uptime, and security alerts closely for several weeks.
If you used a CDN, reverse proxy, or caching layer, confirm that stale malicious content is not still being served from edge nodes.
Many reinfections appear to persist simply because cached copies were not purged.
When should you bring in a security professional?
Not every breach can be handled safely in-house.
Professional incident response is worth considering when the compromise is complex or business-critical.
Bring in outside help if you see any of the following:
- Repeated reinfection after cleanup.
- Suspicion of database exfiltration or credential theft.
- Custom malware, rootkits, or server-level persistence.
- Multiple sites on the same host appearing compromised.
- Payment, health, or personal data exposure concerns.
A qualified incident responder can preserve evidence, trace the initial access point, and verify that the environment is truly clean before you restore normal operations.
What to document during the cleanup?
Good documentation makes recovery faster and supports future prevention.
Keep a record of what was changed, what was removed, and what likely caused the incident.
- Date and time the compromise was discovered.
- Observed symptoms, such as redirects, defacements, or warnings.
- Files, users, and database records modified during cleanup.
- Passwords rotated and systems patched.
- Root cause analysis and follow-up actions.
This record becomes especially valuable if the incident affects compliance, insurance claims, or vendor support cases.