WordPress Backup and Recovery Plan: What to Do After a Hack
After a WordPress hack, do four things in order. Take the site out of public view, keep a full copy of the infected files and database, find a backup made before the first sign of trouble, and restore it into a clean environment. Then close the hole the attacker used. A backup alone does not fix a hack, because the vulnerability is still open and the attacker can walk straight back in.
The failure that hurts most is simple. An owner restores last week’s backup, relaxes, and gets hacked again days later.
This guide walks through the whole process, from the first panicked hour to a written plan you can follow next time. If you want a second opinion on the basics, the official WordPress.org guide to hacked sites is worth reading alongside this one.
What Should You Do Immediately After Your WordPress Website Is Hacked?
Confirm the hack, shut the public door, tell your host, write down what you see, and copy everything before you touch a single file. Cleaning first and thinking second is how evidence disappears.
Recognizing malware infections, redirects and unauthorized website changes
Most hacks do not announce themselves. A defaced homepage is the rare, loud case. The common one is quieter: visitors on phones get bounced to a pharmacy or casino page while you, sitting at your desktop, see nothing wrong at all.
Attackers hide redirects from logged in administrators on purpose, so your own browser is the worst test you can run. Open the site on a phone, on mobile data, logged out. That one check catches a lot.
Other signs are easy to miss. Look for administrator accounts you never created, posts stuffed with foreign language keywords, plugins you never installed, and warning emails from your host about outbound spam or a sudden spike in resource use. A Google Search Console security alert or a red browser warning page means the problem is already public.
One honest caution. A clean looking site is not proof of a clean site. A backdoor script can sit quietly for weeks before anyone uses it.
Isolating the compromised website to protect visitors
The goal is to stop harming visitors and stop the attacker working while you investigate. Put the site into maintenance mode, or better, restrict access so only your own IP address can load it.
A maintenance plugin is itself PHP code running on an infected site, so it is a weak lock. A server level rule, or a request to your host to suspend public access, is much stronger. Do not delete the site. You need it intact for the next steps.
Speed matters here for a reason beyond the visitors. A site that serves malware can land on browser and search engine blocklists, and getting off those lists takes days. Every hour the doors stay open makes the reputation cleanup longer. Pause newsletters and automated posts to social media too, so the infection does not spread through your own channels.
Contacting your hosting provider and reviewing server activity
Your host can see what you cannot. That includes raw access logs, error logs, which IP address posted to which file, and whether other accounts on the same server show the same malicious files.
Ask for specific things. Request the raw access logs for the last 30 days, a list of files changed recently, and confirmation of whether any neighbouring accounts are affected. Do it early, because logs rotate and old entries disappear without warning.
If you host with us, our end user support team works 24/7. Open a ticket, name the account, and give the date you first noticed a problem. A precise first message saves a round of back and forth when time is short.
Documenting suspicious activity before making changes
Write it all down now. By tomorrow you will not remember which plugin looked odd or what time the redirect started.
Take screenshots with timestamps. Save the redirect destination URLs. List every administrator account, with the unknown ones marked. Note your plugin and theme list with version numbers, the suspicious file paths, and the date of the last change you made yourself.
This record does real work later. In the next section you will use it to pick a backup that predates the attack. In section five you will use it to work out how the attacker got in. Plain text notes are fine. Neatness is not the point.
Preserving a complete copy of infected website files and databases
Before any cleanup, copy everything. Compress the full set of site files and download the archive. Export the database through phpMyAdmin or the command line. Grab the logs as well.
Store the copy outside your hosting account and label it clearly: INFECTED, DO NOT RESTORE. This matters for two reasons. It gives you evidence for finding the entry point, and it is your safety net if a cleanup deletes something legitimate, such as orders placed after your last good backup.
This is the key distinction in the whole article. An infected copy preserved for investigation is not a backup. A verified clean backup, tested and dated before the compromise, is the only thing you should ever restore. Keep the two in separate folders and never mix their names. Never upload the infected archive to another live server.
How Do You Identify a Clean WordPress Backup After a Security Breach?
A clean backup is one created before the attacker got in, and you only know that date after you find when they got in. Work backward from the earliest sign of compromise, then verify the files and database yourself instead of trusting the backup’s label.
Finding backup versions created before the earliest signs of compromise
The earliest sign is almost never the day you noticed. Attackers often arrive days or weeks before they act.
Build a timeline from several sources. Check file modification dates, the registration date of any rogue administrator in the users table, the first suspicious entries in your access logs, and the first date Search Console flagged anything. The oldest date you can prove is your line in the sand.
Say the spam pages appeared on a Friday, but a rogue administrator was registered twelve days earlier. Friday’s backup is useless. So is everything created in those twelve days. Choose a restore point comfortably before the earliest date, not one that just touches it.
Checking backup dates, database records and file integrity
A backup’s date tells you when it was made, not what it contains. Check the contents.
For files, compare WordPress core against the official checksums. The WordPress command line tool does this with wp core verify-checksums, and wp plugin verify-checksums –all does the same for plugins hosted on WordPress.org. Any file that fails the check was changed after release, and you need to know why.
For the database, open the users table and look for accounts you do not recognize. Check the options table for odd values in siteurl, home and active_plugins. Search post content for injected script or iframe tags. A backup can look fine on the surface and still carry a planted administrator in the database.
Distinguishing infected backups from verified clean restore points
Sort every backup into one of two states. It is either infected and preserved for investigation, or verified clean.
Anything in between is unverified, and unverified means infected until proven otherwise. A backup earns the clean label only when it predates the earliest compromise, passes the file and database checks above, scans clean, and behaves normally on a staging copy.
Here is the limitation nobody likes to say out loud. No backup system, ours or anyone else’s, can tell you a backup is clean. It can only tell you the backup is complete. A backup taken after the intrusion copies the malware faithfully, and the backup plugin reports success either way.
Reviewing backup storage locations and retention policies
List every place a backup might live. Hosting level backups, plugin backups, manual exports, and copies on your own computer all count. You will forget one if you rely on memory.
Then check how far back each one goes. If a location keeps only seven days of history and the compromise began twelve days ago, that location has no clean restore point to offer. That is a retention policy problem, and section six fixes it for next time.
Look for backups stored inside the website folder itself. A backup archive sitting in the uploads directory can be downloaded by anyone who guesses the filename, and it has been the entry point in more than one hack. If you find one, remove it from public reach straight away.
Testing backup copies in an isolated staging environment
Never test a suspect backup on the live domain. Restore it somewhere private first.
A password protected subdomain works. A small VPS you control works even better, because it keeps the test completely apart from your hosting account. Block search engines from indexing it, and switch off outbound email so a staging copy cannot send mail to your customers.
Then run a malware scan, click through the main pages on a phone, and watch for redirects. If the staging copy misbehaves, that backup is infected. Move one restore point earlier and try again. An hour of testing beats a day of repeat cleanup.
How Do You Restore a Hacked WordPress Website From Backup?
Build a clean environment, install fresh WordPress core files, restore only the content you trust, then test and verify. Never restore on top of the infected files.
Preparing a clean hosting environment before restoration
Restoring over the top of an infected install is the single most common recovery mistake. Old malicious files survive the restore, because the backup only overwrites files that share a name with it.
Start from empty instead. Create a fresh directory, or better, a fresh hosting account such as a new shared hosting account, and move the site there. Check the old account for scheduled cron jobs and unfamiliar subdomains before you abandon it, because attackers hide things in both.
Update the PHP version while you are at it. Hosting panel passwords can change now, from a clean device. WordPress and database passwords wait for section five, after the site is verified.
Restoring WordPress core files from trusted sources
Do not restore core files from any backup, even a clean one. Download a fresh copy from WordPress.org and upload it. It costs five minutes and removes a whole category of doubt.
Use the same version your site ran, or the latest release if your theme and plugins support it. Build a new wp-config.php from the sample file instead of reusing the old one, since attackers like to hide code at the top of that file.
Regenerate the rewrite rules afterward by saving the permalink settings once. That rebuilds the .htaccess file from scratch, and any malicious rules in the old one stay behind.
Recovering the database, themes, plugins and media files safely
Import the database from your verified backup through phpMyAdmin or the command line. That is the content you are saving: posts, pages, settings, users.
Reinstall plugins and themes fresh from the official directory or the vendor’s own site. Do not copy them out of the backup. If you run a custom theme, read through the files before you copy it in. Premium plugins downloaded from unofficial sites are a known way in, and a restore will not protect you from a plugin you installed badly in the first place.
Media is the last piece. The uploads folder should hold images, documents and video, and nothing else. Run find uploads -name “*.php” and delete anything it finds. A PHP file in uploads has no legitimate reason to exist.
Checking website functionality after the restoration process
Test like a customer. Load the homepage, follow the menu, log in, submit a contact form, and send a test email. For an online store, place a test order and watch the payment flow through to the end.
Then deal with the gap. Anything posted between your backup date and the hack is missing: new articles, new orders, new customer accounts. Your preserved infected copy still holds that data.
Pull individual rows from it, never whole tables. Orders and posts can be reviewed and imported again carefully. Users and settings tables stay behind, because that is exactly where attackers plant their changes.
Verifying that malicious files and unauthorized changes are removed
Run the checksum verification again on the restored site. Scan it with a malware scanner. Review the administrator list, the scheduled events and the options table one more time.
Search the files for common obfuscation, such as base64_decode and eval in places they do not belong. Plenty of legitimate plugins use them, so treat a hit as a reason to read the file, not proof of guilt.
A scanner that comes back clean is evidence, not proof. Scanners miss things. Watch the access logs closely for the next 48 hours, and if the site is reinfected within days, stop restoring. That pattern points to an unclosed entry point or a server level problem, which the next two sections cover.
What Should You Do If You Do Not Have a Clean WordPress Backup?
Rebuild instead of restore. Replace WordPress core, plugins and themes with fresh official copies, keep only the content you have inspected, and remove every unknown user, scheduled task and script.
Rebuilding WordPress core files using official installation packages
Delete the wp-admin and wp-includes folders and every PHP file in the site root except wp-config.php. Upload fresh copies from the official package in their place.
If that feels risky, install a brand new copy in a separate directory using an auto installer such as Softaculous, then move your content across. Either way, run the checksum verification when you are done.
Open wp-config.php in a text editor and read it top to bottom. Injected code often sits above the first line of real configuration. Rotate the database password and the authentication keys once the site is clean.
Reinstalling plugins and themes from trusted sources
Delete every plugin and theme folder, including the inactive ones. An inactive plugin with a known vulnerability can still be attacked, because the files are on the server whether or not WordPress loads them.
Before you delete, copy your plugin list with version numbers. Then reinstall only what you actively use, from WordPress.org or the vendor’s own site. Replace anything abandoned by its author.
Custom code needs a human read. If a developer built a theme for you, compare it against their original copy or ask them to review it. Do not copy it back in unread.
Inspecting uploads, configuration files and suspicious database entries
Start with the places attackers favor. Look for PHP files in uploads, hidden files whose names begin with a dot, and anything inside the mu-plugins folder. Must use plugins load silently with no entry in the dashboard, so it is a popular hiding spot.
Read the .htaccess file for rewrite rules that send visitors to unfamiliar domains. Check the .user.ini file too.
In the database, search post content for injected markup with a query such as SELECT ID, post_title FROM wp_posts WHERE post_content LIKE ‘%<script%’;. Check widget text and options values for long encoded strings. Your table prefix may differ from wp_, so adjust the query to match.
Removing unauthorized users, scheduled tasks and backdoor scripts
Order matters here. Remove the backdoors first and the users second. If you delete a rogue administrator while the backdoor that created it is still alive, the account simply comes back.
Hunt for backdoors by modification date. Files changed recently in folders where nothing should change are suspects. Names that imitate core files, such as a file called wp-tmp.php, are a common disguise.
Then clear the persistence tricks. List WordPress scheduled events and delete the ones you do not recognize. Check cron jobs in your hosting control panel. Review application passwords on every user profile, since those let an attacker sign in without ever using the main password.
Seeking professional malware cleanup when the infection affects server infrastructure
There is a difference between a WordPress level compromise and a server level one, and the difference changes everything. If attackers reached the hosting account or other sites beside yours, restoring WordPress files alone will not be enough.
Warning signs include reinfection after a full rebuild, files owned by an unexpected system user, other sites in the same account carrying the same malware, and your host reporting spam leaving the server. When you see those, stop cleaning and get help.
Account structure plays a big part. Many agencies park a dozen client sites in one account, so one weak plugin exposes all of them. On reseller hosting each client can sit in their own control panel account, and a master reseller setup extends that separation to your own resellers.
After 20+ years of running servers and 700,000+ hosted websites, we hold to one rule. If the infection lives below WordPress, you need a person with server access. On a dedicated server you own that level, so budget for a sysadmin or a malware cleanup specialist before you need one.
How Do You Secure WordPress After Recovering From a Hack?
Rotate every credential, regenerate the authentication keys, patch whatever the attacker used, add multifactor sign in, and watch the site closely for weeks. Recovery is not finished until the entry point is closed.
Changing WordPress, hosting, database and SFTP credentials
Rotate credentials after the site is verified clean, not before. A live backdoor can read new passwords straight out of the configuration file, which makes an early rotation wasted effort.
Change every one of them: WordPress administrators, the hosting control panel, SSH and SFTP, the database user, and the email accounts that receive password reset links. If the attacker controls the email, they control the site.
Do it from a device you have scanned for malware. A stolen credential from an infected laptop is a common way a hack repeats. Use a password manager and give every account a unique password.
Regenerating authentication keys and revoking exposed access tokens
WordPress signs login cookies with secret keys and salts stored in wp-config.php. Replace them with fresh values from the official WordPress salt generator. Every existing session ends immediately, which is exactly what you want.
Then think about tokens that live outside WordPress. Revoke application passwords, WooCommerce REST API keys, and keys for payment gateways, email services and social accounts. Reissue them from the clean site.
Anything a plugin stored in the options table during the hack should be treated as exposed. That list is longer than most owners expect.
Updating vulnerable plugins, themes and WordPress core files
Go back to your logs and your notes from section one. Find the first suspicious request, then compare the plugin and theme versions you were running against public vulnerability databases. That is how you find the door the attacker used.
Update everything, remove what you do not use, and turn on automatic updates for security releases. The official WordPress hardening guide covers file permissions and other server settings worth checking.
Sometimes the logs rotated away and the entry point stays a mystery. Say so plainly, then assume the worst and tighten everything. Guessing a cause and moving on is how a second hack happens.
Enabling multifactor authentication and reviewing administrator permissions
Turn on multifactor authentication for every account that can publish or change settings. A stolen password alone then stops being enough.
Count your administrators. Most sites have more than they need. Editors and authors do not require admin rights, and every extra admin is another password that can leak.
Add define( ‘DISALLOW_FILE_EDIT’, true ); to the configuration file. It removes the theme and plugin code editor from the dashboard, so an attacker who steals a login cannot rewrite your files from the browser.
Monitoring malware alerts, suspicious activity and search engine security warnings
Set up file change alerts and a weekly malware scan. Keep an activity log that records who logged in and what they changed. Check the Security issues report in Google Search Console, and if Google flagged you, request a review once the site is clean.
Reviews can take days, so ask early and do not panic when the warning lingers. Plan to watch the site closely for at least 30 days after recovery.
A CDN layer such as our CloudFlare CDN integration sits between visitors and your origin server, which helps absorb junk traffic. It is not a substitute for cleaning or patching. It is one more layer, and layers are the point.
How Can You Build a WordPress Backup and Disaster Recovery Plan?
Automate backups of your files and database, keep an independent copy offsite, decide how often to back up and how long to keep copies, test your restores on a schedule, and write the recovery steps down so anyone on your team can follow them at two in the morning.
Scheduling automatic backups of website files and databases
A backup has two halves: the files, and the database. Miss either one and the site will not come back whole.
Manual backups get forgotten, so automate them. For a blog that publishes weekly, a daily backup is plenty. For an online store taking orders, the database needs backing up every hour or every few hours, because a day of lost orders is a day of lost money.
A sensible pattern is a full backup weekly with incremental backups in between, plus a fresh one before every major update. Hosting level backups are a convenience layer, and that includes ours. Treat them as one copy among several, never the only copy.
Maintaining independent offsite backup copies
At least one copy must live outside your hosting account, and outside the credentials that can reach it. An attacker who gets into the account can delete the backups kept inside it.
Use a separate provider or object storage, with a dedicated access key that is not reused anywhere else. Where the storage supports it, keep versioned copies so a deleted or corrupted file can be recovered.
Be careful with synced cloud folders. Sync copies mistakes faithfully, so an infected or deleted file replaces the good one everywhere within minutes. Sync is not backup.
Defining backup frequency, retention periods and recovery objectives
Two terms turn a vague plan into a measurable one. The Recovery Point Objective, or RPO, is how much recent data you can afford to lose. The Recovery Time Objective, or RTO, is how long the site can stay down.
A personal blog might accept an RPO of 24 hours and an RTO of one day. An online store might need an RPO of one hour and an RTO of two. Pick your numbers honestly, then set backup frequency to match them.
Retention matters just as much. Because hacks sit quietly, keep daily copies for at least 30 to 60 days, with monthly archives beyond that. Restore speed depends partly on disk speed, and our servers run Intel Dual Xeon processors with NVMe drives, which you can see on our NVMe VPS page. Large database imports are where that difference shows up.
Testing restoration procedures to verify backup reliability
An untested backup is a hope. Restore to a staging environment every quarter and time the whole process from start to finish.
Compare that time against your RTO. Check that the database imported without errors, the media files are present and the forms still work. A backup job can report success while the archive is missing the database, because a timeout cut it short.
Write down what went wrong, even small things. Those notes become the improvements to your plan.
Creating a documented recovery process for future security incidents
Put the plan on one page and store it somewhere outside the website. It should name who calls the host, where the backups live, where the credentials are kept, and the order of steps from this article: isolate, preserve, identify, restore, secure.
Add a clear rule for when to call a professional, such as reinfection after a rebuild or signs of a server level compromise. If you manage client sites, add a short template for telling customers what happened.
Review the page twice a year. The people, tools and passwords change faster than the plan does.
If you run client sites and want to see how a hosting plan supports security, uptime and backups, compare what each plan includes on our reseller features page. Pick the plan whose features match the recovery plan you just wrote.
