How to Restore a WordPress Backup After a Hack
If your WordPress site has been hacked, restoring a clean backup is often the fastest way to get back online.
The real challenge is doing it without bringing the malware back with you.
This guide explains how to restore WordPress backup after hack, how to verify the backup is clean, and what to secure before and after the restore so your site does not get compromised again.
Before You Restore: Stop the Damage First
Do not rush straight into restoration without isolating the incident.
A backup can only help if you prevent the hacked environment from reinfecting the site or overwriting a clean restore.
- Put the site in maintenance mode if possible.
- Change passwords for WordPress admin accounts, hosting control panel, FTP or SFTP, database, and email accounts tied to the site.
- Notify your hosting provider that the site has been compromised.
- Scan the server for suspicious files, unfamiliar admin users, and recent changes.
- Disconnect any integration that may still have valid access tokens, such as API keys or deployment tools.
If you have not already done so, take a full snapshot of the current hacked site.
Even a compromised state can be useful for forensic review and for comparing files later.
Choose the Right Backup to Restore
The best backup is usually the most recent one created before the hack, but only if it is trustworthy.
A backup made after the attack or after suspicious file changes may already contain malware, backdoors, or injected spam content.
What to look for in a clean backup
- A backup date that predates the breach.
- Files stored offsite in a secure backup service or cloud storage.
- Database exports that match the same clean time window as the file backup.
- Known-good copies of wp-config.php, themes, plugins, and uploads.
If you maintain incremental backups, identify the last known clean restore point.
For many sites, this is the safest path because it limits the amount of content that must be manually rebuilt.
How to Restore WordPress Backup After Hack Safely
The exact process depends on your backup tool and hosting setup, but the core sequence is consistent.
Restore the site into a clean environment, verify the files, and only then reconnect it to live traffic.
1. Prepare a clean hosting environment
If the server itself is compromised, restoring the site onto the same infected environment can undo your work.
Ask your host to confirm whether the account, container, or server needs to be cleaned or rebuilt.
In serious cases, a fresh WordPress install on a clean account is the safest target for the restore.
2. Restore the database and files from the clean backup
Use your backup plugin, hosting panel, or manual restore process to import the database and upload the WordPress files.
Restore both components together when possible, because mismatched files and database versions can break the site or leave fragments of the attack behind.
If restoring manually, prioritize these items:
- Database for posts, pages, users, settings, and menus.
- wp-content/uploads for media files.
- Themes and plugins from verified sources or official repositories.
- wp-config.php only after checking for unknown keys, salts, or injected code.
3. Replace core WordPress files
Never assume WordPress core files are clean after a hack.
Replace the wp-admin and wp-includes directories with fresh copies from the official WordPress release that matches or exceeds your version.
This removes tampered core files while preserving your content.
4. Scan for hidden malware before going live
Review the restored site for suspicious PHP files, obfuscated JavaScript, unusual redirects, and unfamiliar administrator accounts.
Malware often hides in wp-content, especially inside plugin folders, theme files, and uploads directories where file execution may be possible.
Use a reputable security scanner and compare the restored files against a trusted backup or known-good checksums.
Look for base64-encoded strings, eval calls, unexpected remote requests, and recently modified files that do not match your changes.
What to Clean Before Reopening the Site
Restoring a backup is not enough if access remains open to attackers.
Clean the credentials, permissions, and configuration points that could allow reinfection.
- Reset all WordPress passwords, especially administrator accounts.
- Remove unknown users and restore the principle of least privilege.
- Regenerate WordPress security salts in wp-config.php.
- Rotate database, FTP, SFTP, and hosting passwords.
- Check file permissions so PHP files cannot be edited by untrusted processes.
- Update WordPress core, themes, and plugins to supported versions.
Also review scheduled tasks and cron jobs.
Attackers often use cron to reinject malware, phone home, or recreate deleted backdoors.
Should You Restore Files, the Database, or Both?
In most cases, restoring only part of the site creates problems.
A file restore without a database restore may leave malicious users in place.
A database restore without file cleanup may leave infected plugins or themes active.
Restore both when:
- The hack touched site content, admin users, or settings.
- Malware appeared in theme or plugin files.
- You cannot verify which component was first compromised.
Restore only one component when:
- You know the attack was limited to a specific media file or plugin file.
- The database contains newer legitimate content you cannot afford to lose.
- You plan to merge clean content manually after restoring the core system.
For eCommerce sites using WooCommerce, test orders, customer accounts, and transactional settings carefully after restoration.
For membership sites, verify access rules and subscription records before opening checkout or login pages.
How to Verify the Restore Worked
After the site is restored, test it like a visitor, a logged-in user, and an administrator.
A website can appear fine on the homepage while hidden redirects or malware still affect other pages.
- Load the home page, login page, and several deep URLs.
- Check whether search engines or browsers still flag the site as unsafe.
- Review server error logs for repeated file access or suspicious requests.
- Confirm contact forms, checkout, and email delivery work correctly.
- Inspect mobile and desktop versions for injected scripts or pop-ups.
If you use Google Search Console, review security issues and manual actions.
If the site was blacklisted, submit a review request only after confirming the infection has been removed.
Common Mistakes to Avoid During Recovery
Many site owners make the same errors during hack recovery.
Avoiding them can save hours of cleanup later.
- Restoring an unverified backup. A dirty backup can reintroduce the attack.
- Skipping password resets. Old credentials can let attackers return.
- Leaving outdated plugins active. Vulnerable extensions are a common entry point.
- Ignoring the hosting environment. A compromised server can infect a clean site again.
- Failing to remove hidden admin accounts. Backdoor access is often the reason a site is re-hacked.
Best Practices to Prevent the Next Incident
Once you recover the site, use the opportunity to strengthen your backup and security workflow.
The best time to prepare for the next incident is immediately after this one.
- Keep automated daily backups with offsite storage.
- Retain multiple restore points, not just one recent copy.
- Test restore procedures periodically so you know they work under pressure.
- Use a web application firewall and login protection.
- Remove abandoned plugins and themes.
- Enable file integrity monitoring and uptime alerts.
- Restrict admin access by IP where practical.
For agencies and site owners managing multiple properties, document the restore process in a runbook.
Include backup locations, hosting access details, security contacts, and the steps for verifying a clean recovery.