How to Restore a Website After a Hack
If your site has been compromised, speed and methodical cleanup matter more than panic.
This guide explains how to restore website after hack incidents, recover safely, and reduce the chance of another breach.
First: Contain the damage
Before making changes, stop the attack from spreading and preserve evidence.
If the site is still online, put it into maintenance mode or temporarily take it offline so visitors do not encounter malware, phishing pages, or defacement.
- Change the hosting control panel password immediately.
- Disable compromised admin accounts and create new credentials from a secure device.
- Rotate passwords for FTP, SFTP, SSH, database, CMS, and email accounts.
- Notify your hosting provider so they can review server logs and isolate affected resources.
If you run WordPress, Joomla, Drupal, Magento, or another content management system, assume any reused password may also be compromised elsewhere.
Confirm the breach and identify the scope
Restoration is faster when you know what was affected.
Review recent changes, suspicious logins, unfamiliar files, redirects, injected JavaScript, and new admin users.
Check whether the compromise is limited to one application or includes the hosting account, database, email inboxes, or connected subdomains.
Common signs of a hacked website
- Unexpected redirects to spam, gambling, or phishing sites
- Search engine warnings or browser security alerts
- Modified homepage content or injected hidden text
- Unknown files in uploads, themes, plugins, or webroot directories
- Outbound spam from contact forms or mail scripts
- Sudden drops in traffic, indexing issues, or ranking losses
Log files from Apache, Nginx, LiteSpeed, Cloudflare, and your CMS can reveal where the intrusion started.
When possible, preserve copies before cleaning so you can review attacker activity later.
Restore from a clean backup
The safest way to restore website after hack damage is usually a verified backup created before the intrusion.
A clean restore gives you a known-good baseline and is often faster than manually repairing every file.
What makes a backup safe to restore?
- It was created before the earliest sign of compromise
- It includes both files and database content
- It was stored separately from the infected site
- It has been scanned or reviewed for malware
- It does not contain outdated vulnerabilities that caused the hack
Restore the backup to a clean environment, not over the infected installation.
After that, compare the restored version with current plugins, themes, and configuration files to confirm no malicious code remains.
Remove malware from files, database, and server settings
If no safe backup exists, clean the site manually or with professional incident-response tools.
Attackers often hide code in places that are easy to overlook, including template files, scheduled tasks, configuration files, and the database.
Where malicious code often hides
- WordPress core files, wp-config.php, functions.php, and mu-plugins
- Theme and plugin folders, especially recently modified files
- Uploads directories containing PHP, JS, or disguised file extensions
- .htaccess, web.config, cron jobs, and auto-prepend settings
- Database tables storing post content, widgets, options, or scripts
Reinstall the CMS core from an official source, then reinstall themes and plugins from trusted repositories or vendor downloads.
Avoid reusing files copied from an infected server unless they have been verified clean.
Reset access and close the entry point
Cleaning the site without fixing the vulnerability leaves it open to reinfection.
Identify how the attacker entered, then remove that path before bringing the site back online.
- Update the CMS, plugins, themes, and server software to current versions.
- Delete unused extensions, inactive themes, and abandoned admin accounts.
- Review file permissions so writable directories are limited to what is necessary.
- Disable risky features such as PHP execution in upload folders when possible.
- Enable multi-factor authentication for administrator and hosting logins.
For larger environments, review web application firewall rules, rate limits, and login protection.
Tools such as Cloudflare, Sucuri, Wordfence, ModSecurity, and server-level WAFs can help block common exploit patterns.
Scan everything before relaunching
Before you publish the site again, scan files, databases, and endpoints for remaining threats.
Use at least one reputable malware scanner and, if possible, verify with a second method so you are not relying on a single detection engine.
What to verify during pre-launch testing
- No suspicious redirects or injected scripts
- All forms, checkout flows, and login pages work normally
- XML sitemaps, robots.txt, canonical tags, and metadata are intact
- There are no unauthorized admin users or scheduled tasks
- Database content does not contain hidden spam links or spammy anchor text
Check the site on desktop and mobile, and test from different browsers and network locations.
If you use a CDN or reverse proxy, purge cached infected pages so old content is not served again.
Notify search engines, users, and security services
Once the site is clean, take steps to recover visibility and trust.
If Google Search Console or Bing Webmaster Tools reported malware or hacked content, request a review after you have confirmed remediation.
- Submit updated sitemaps to search engines.
- Use Search Console’s Security Issues and Manual Actions reports to check for warnings.
- Ask your hosting provider or security vendor for blacklist removal assistance if needed.
- Inform users if passwords, payment data, or personal information may have been exposed.
If the breach involved sensitive data, legal or regulatory reporting obligations may apply depending on your location and industry.
Strengthen security after recovery
Recovery is not complete until the site is harder to compromise than before.
The best post-incident improvements focus on account security, software hygiene, monitoring, and recovery readiness.
Security controls that matter most
- Automatic backups stored offsite with regular restore testing
- Strong unique passwords stored in a password manager
- Multi-factor authentication for admins, hosting, and email
- Least-privilege access for editors, developers, and contractors
- File integrity monitoring and uptime alerts
- Regular patching for CMS cores, plugins, themes, and server packages
For business sites, add logging retention, change tracking, and an incident response checklist.
These controls make it easier to detect compromise early and reduce downtime the next time a problem occurs.
How long does website recovery usually take?
Recovery time depends on the severity of the attack, the quality of backups, and whether the vulnerability is known.
A small WordPress site with a recent clean backup may be restored in hours, while a heavily infected eCommerce platform or custom application can take days.
Speed improves when you already have a documented backup strategy, a clean staging environment, and a clear list of plugins, extensions, domains, and service credentials.
Even in a fast recovery, do not skip validation; reinfection often happens when cleanup is rushed.
What to do if you cannot clean it yourself
Hire a specialist if the hack affects payment data, customer records, enterprise systems, or repeated reinfections.
Website incident-response teams can analyze logs, remove persistence mechanisms, and harden the server while preserving evidence for forensic review.
When choosing help, look for experience with your platform, transparent remediation steps, and post-clean verification.
Ask whether they will review the root cause, patch the vulnerability, and provide a written summary of what was removed and what was changed.