How to Restore a Hacked WordPress Site

Quick answer: To restore a hacked WordPress site from backup, take the site offline, preserve evidence, pick a backup from before the compromise, wipe the infected files completely (don't overwrite them), restore files and database from a clean offsite copy, rotate every credential, then re-scan before going live. The single most important detail is that the backup you restore from must be stored outside the compromised server — a backup sitting on the same hacked account is often infected, deleted, or encrypted along with everything else.

Getting hacked is not a rare event for WordPress site owners. WordPress powers a huge share of the web, which makes it the most automated-attack-targeted CMS in existence — and the overwhelming majority of those attacks are not personal. They're bots scanning for a known-vulnerable plugin version, a weak admin password, or an outdated PHP install. Nobody picked your site. A script found it.

What separates a two-hour recovery from a two-week nightmare is almost never the sophistication of the attack. It's whether you had a clean backup somewhere the attacker couldn't reach.

This guide covers how to tell whether you've actually been hacked, what to do in the first thirty minutes, the full step-by-step restore process from backup, the mistakes that turn a recoverable hack into permanent data loss, and the prevention setup that means you never have to do this twice.

Quick Answer: What Are the First Steps After a WordPress Hack?

If you've just confirmed a compromise, do these five things in order before anything else:

1. Take the site offline — enable maintenance mode or serve a temporary holding page. This stops the site serving malware to visitors and stops Google indexing spam pages.
2. Don't delete anything yet. Take a full snapshot of the compromised state (files + database) and label it clearly as infected. You may need it for forensics, for your host, or to recover content created after the last clean backup.
3. Change the hosting account password and enable two-factor authentication, before touching WordPress itself. If the attacker holds the hosting credentials, every cleanup step you take will be undone.
4. Identify roughly when the compromise started. File modification timestamps, unfamiliar admin users, and hosting access logs will bracket the date.
5. Locate a backup from before that date — and confirm it's stored somewhere the attacker never had access to.

Only after step 5 should you start restoring. Restoring first and investigating later is how site owners end up reinstating the backdoor along with the site.

How Do You Know Your WordPress Site Was Actually Hacked?

Not every broken site is a hacked site. These are the signals that reliably indicate compromise rather than a plugin conflict:

• Google flags the site with "This site may be hacked" or "Deceptive site ahead" in search results, or Search Console reports a Security Issue.
• Unknown administrator accounts appear under Users, often with plausible-looking names or gibberish email addresses.
• Spam pages or redirects — visitors from Google land on pharmaceutical, gambling, or counterfeit-goods pages that don't exist in your WordPress admin.
• Unfamiliar files in the site root — random-named PHP files, or files like wp-conflg.php or wp-load-old.php that mimic core filenames.
• Modified core files. WordPress core files should never differ from the official release. If wp-settings.php or index.php has a recent modification date you can't explain, that's a strong signal.
• Obfuscated code — long base64, eval(), gzinflate(), or hex-encoded blocks injected at the top of theme files, especially functions.php and header.php.
• Outbound spam — your host notifies you the account is sending mail, or your domain lands on a blacklist.
• Sudden unexplained traffic or resource spikes — a compromised site is often being used as someone else's infrastructure.
• Scheduled tasks you didn't create in WP-Cron, or new entries in the server crontab.

Is it a hack or just a broken plugin?

A useful distinction: plugin conflicts and update failures break the site for you — white screens, fatal errors, broken layouts. Hacks typically keep the site working for you while behaving differently for search engines and first-time visitors. If the site looks fine when you're logged in but strangers report redirects, assume compromise.

Why the Backup Location Decides Whether You Recover

This is the part most guides gloss over, and it's the part that actually determines the outcome.

When an attacker gains file-write access to a WordPress install, everything inside the hosting account is within reach — and backup archives generated by a plugin typically sit inside wp-content/, on the same filesystem, under the same user. Which means:

• Plugin-generated backups get infected too. If the compromise has been quiet for three weeks and your plugin keeps seven daily backups, all seven contain the backdoor. Restoring any of them restores the attacker's access.
• Attackers delete backups deliberately. Wiping local backup archives is a standard step in ransomware and extortion playbooks, precisely because it removes the victim's cheapest recovery option.
• Hosts suspend compromised accounts. When a host detects malware or outbound spam, suspension is common and often immediate. A suspended account can mean no dashboard, no FTP, and no access to host-side backups at the exact moment you need them.
• Host-side backups share the incident. A backup stored on the same infrastructure as the live site is exposed to whatever affects that infrastructure — including the compromise and the suspension that follows it.
• Retention windows are often too short. Compromises are frequently discovered weeks after they start. A host tier keeping one to seven days of backups may have no clean copy left by the time anyone notices.

The structural fix is simple: keep at least one backup copy outside the hosting account, on independent storage, with retention long enough to reach back past a slow-burn compromise. That's the specific gap BackupYourSite is built to close — backups are pulled over SSH to offsite storage, so they aren't sitting in a directory the attacker controls, and they don't disappear when the hosting account does.

Step-by-Step: Restoring a Hacked WordPress Site From Backup

Step 1: Take the Site Offline and Preserve Evidence

Put the site into maintenance mode or point the document root at a static holding page. This protects visitors, stops Google crawling injected spam, and freezes the scene.

Before you change a single file, take a complete snapshot of the compromised site — all files plus a database dump — and store it somewhere clearly labelled as infected. You are not going to restore from it. You may need it to:

• Identify the entry point so the same vulnerability isn't restored along with the site.
• Recover legitimate content (orders, posts, form submissions) created after your last clean backup.
• Provide evidence to your host, a client, or an insurer.

Step 2: Lock Down Access Before You Clean

Cleaning while the attacker still has credentials is wasted work. In this order:

• Change the hosting control panel password and enable 2FA.
• Change SSH/SFTP/FTP passwords, and rotate or replace SSH keys.
• Change the database user password (and update wp-config.php after the restore).
• Change all WordPress administrator passwords, and delete any admin account you don't recognise.
• Force-invalidate existing WordPress sessions by changing the salts in wp-config.php — new salt values log every user out immediately.
• Review third-party access: deploy keys, CI tokens, WooCommerce/payment API keys, and any agency or contractor accounts.

Step 3: Determine When the Compromise Started

You need a date to choose a backup against. Useful sources:

• File modification times — sort the whole install by modified date and find the oldest anomaly. Attackers sometimes backdate timestamps, so treat this as a floor, not proof.
• Hosting access and error logs — look for POST requests to unusual PHP files, or bursts of requests to wp-login.php and xmlrpc.php.
• WordPress user registration dates for the rogue admin accounts.
• Google Search Console — the date Google first flagged a security issue, or when spam pages first appeared in the Coverage/Pages report.
• Your own records — the date a client first reported "weird redirects" is often weeks before anyone investigated.

Pick a backup from comfortably before the earliest signal, not from the day before you noticed.

Step 4: Wipe, Don't Overwrite

This is the step people get wrong most often. Restoring files over an infected install leaves every attacker-added file in place — the restore only replaces files that exist in both sets. A backdoor named wp-cache-config.php in your uploads folder isn't in the backup, so nothing removes it.

The correct sequence:

• Delete the entire WordPress directory contents — core, wp-content, everything — after confirming you have both your clean backup and your infected snapshot.
• Drop the database (or restore into a freshly created, empty database).
• Check outside the web root too. Cron jobs, .htaccess files in parent directories, and files in the home directory above public_html are common persistence spots that survive a site-folder wipe.

Then restore into clean, empty space.

Step 5: Restore Files and Database From the Clean Backup

With a clean slate:

• Restore the files from the pre-compromise backup.
• Restore the database into the empty database you created.
• Update wp-config.php with the new database credentials and new salts — do not restore the old salts, or old sessions may become valid again.
• Reinstall WordPress core from an official copy rather than trusting the backup's core files. Core is identical for everyone; a fresh download removes any doubt about it.
• Reinstall plugins and themes from official sources too, at their current versions. Restore only your own custom code and uploads from the backup.

This "fresh core, fresh plugins, restored content" approach is what makes the restore trustworthy rather than merely fast. The backup supplies your data; official sources supply your code.

With an offsite SSH-based service, steps 4 and 5 collapse into a single guided restore — a one-click restore of files, database, or the full site, run from outside the compromised environment rather than assembled by hand over FTP while the client is calling.

Step 6: Patch the Entry Point

If you restore a site with the same vulnerable plugin version, the same bot will find it again — usually within days. Before going live:

• Update WordPress core, every plugin, and every theme to current versions.
• Delete every deactivated plugin and unused theme. Inactive code is still executable code sitting on disk.
• Check the PHP version — an end-of-life PHP release no longer receives security patches.
• Cross-reference your plugin list against a vulnerability database and remove anything abandoned or unmaintained.
• Review file permissions: directories 755, files 644, wp-config.php 600 or 640. Nothing should be 777.

Step 7: Verify Before You Go Live

• Scan the restored site with a reputable malware scanner and confirm it comes back clean.
• Compare core file checksums against the official WordPress release.
• Re-check the Users list for accounts you don't recognise.
• Search the database for injected script tags and suspicious entries in wp_options — particularly autoloaded options with encoded values.
• Test the site as a logged-out visitor, and specifically test what a visitor arriving from a Google search result sees, since many redirect hacks only trigger on search-engine referrers.
• Verify scheduled tasks — check WP-Cron and the server crontab for jobs you didn't create.

Step 8: Clean Up the Aftermath

Recovery isn't finished when the site loads correctly.

• Request a review in Google Search Console if the site was flagged, and resubmit the sitemap.
• Check for and remove indexed spam URLs, using removal requests for anything that shouldn't exist.
• Check domain and IP blacklists and request delisting where needed.
• Confirm email deliverability if the server was used to send spam.
• Take a fresh backup of the clean, patched site immediately — your current backup set still points at a pre-incident state, and you want a known-good baseline from right now.
• Tell affected users if personal data may have been exposed. Depending on your jurisdiction and what was stored, this may be a legal obligation rather than a courtesy.

Common Mistakes That Turn a Hack Into Permanent Data Loss

• Restoring over the infected install instead of wiping first. Leaves every attacker-added file untouched.
• Restoring from a backup taken after the compromise began. Reinstates the backdoor. Always restore from before the earliest evidence, not before the day you noticed.
• Deleting the infected site immediately. Destroys the only copy of content created since the last backup, and destroys the evidence needed to find the entry point.
• Cleaning before rotating credentials. The attacker simply walks back in.
• Skipping the patch step. A restored-but-unpatched site is a site waiting to be re-hacked by the same script.
• Trusting a single backup without testing it. An untested backup is a hypothesis. Restore-test to a staging environment on a schedule, while nothing is on fire.
• Assuming the host's backup will be there. If the host suspends the account for malware, host-side backups may be unreachable at exactly the wrong moment.

Prevention: The Setup That Means You Never Do This Twice

Backups that survive the incident

The non-negotiable: at least one backup copy stored outside the hosting account, with retention long enough to reach back past a compromise that went unnoticed for weeks. If every copy you have lives on the server being protected, you effectively have no backup against this specific class of failure.

BackupYourSite handles this by pulling backups over SSH to independent offsite storage:

• No plugin required — nothing installed inside WordPress, so there's no backup plugin for an attacker to disable, no plugin archive sitting in wp-content to infect, and no extra code on the site to become a vulnerability itself.
• Offsite by design — the backup isn't in the blast radius of a compromised hosting account or a suspension.
• One-click restore — files, database, or the entire site, without hand-assembling a recovery over FTP under pressure.
• Independent verification — you find out a backup didn't run from a summary generated outside the site, rather than discovering it during an emergency.

Hardening that closes the common entry points

• Keep everything updated, and enable auto-updates for minor core releases at minimum.
• Remove unused plugins and themes entirely rather than deactivating them.
• Enforce strong, unique passwords and 2FA on every administrator account.
• Limit login attempts and, where practical, restrict wp-admin access by IP.
• Disable file editing from the dashboard: add define('DISALLOW_FILE_EDIT', true); to wp-config.php.
• Disable PHP execution in the uploads directory — uploads should never run code.
• Use least-privilege roles. Not everyone who writes posts needs Administrator.
• Keep PHP on a supported version.
• Run a web application firewall to block known attack patterns before they reach WordPress.
• Monitor for file changes so an intrusion is detected in days rather than months — which also means your backup retention only needs to cover days, not months.

Test your restore before you need it

A backup is only real once you've restored it successfully. Pick a schedule — quarterly is a reasonable floor for client sites — and actually restore to a staging environment. You'll find out whether the database dump is complete, whether uploads are included, and how long the process takes, at a moment when none of those answers are expensive.

Frequently Asked Questions

Can I restore a hacked WordPress site myself?

Yes, in most cases. If you can identify roughly when the compromise started, you have a backup from before that date stored outside the hosting account, and you're comfortable wiping the install and restoring files and a database, the process in this guide is entirely doable. Bring in a specialist if the site handles payment or personal data, if the compromise has persisted for months, or if you restore cleanly and the site gets re-infected — that last one usually means a backdoor outside the web root.

How far back should I restore my WordPress site?

Restore from a point comfortably before the earliest evidence of compromise, not before the day you discovered it. Compromises are often quiet for weeks. Use file modification dates, hosting access logs, rogue admin account creation dates, and the date Google first flagged the site to bracket the start, then pick a backup from before that window.

Will restoring from backup remove the malware?

Only if you wipe first. Restoring over an infected install leaves every attacker-added file in place, because a restore only replaces files present in both the backup and the live site. A backdoor the backup doesn't know about simply survives. Delete the site directory and database completely, then restore into the empty space.

What if my only backup is also infected?

This is common with plugin backups stored on the same server, since they capture whatever was on disk at the time. If every copy you hold is post-compromise, options are: restore the infected backup to an isolated staging environment and clean it manually; rebuild core, plugins, and themes from official sources and import only your content (posts, pages, uploads, users) from the infected database after inspection; or engage a professional malware-removal service. All three are far more expensive than having had one clean offsite copy — which is exactly why the offsite copy matters.

Do I need a plugin to back up WordPress?

No. Backups can be pulled at the server level over SSH, entirely outside WordPress. BackupYourSite works this way — nothing is installed on the site, so there's no backup plugin adding attack surface, no archive sitting in wp-content waiting to be infected or deleted, and no PHP execution limits constraining large sites. See how it works for the mechanics.

How long does it take to restore a hacked WordPress site?

With a clean offsite backup and a one-click restore, the technical restore is typically minutes to under an hour depending on site size. The surrounding work — investigating the timeline, rotating credentials, patching the entry point, verifying the result, and clearing Google security flags — usually takes considerably longer than the restore itself. Without a clean backup, recovery moves from hours to days or weeks.

Should I tell my users the site was hacked?

If personal data may have been exposed — customer records, email addresses, order details, anything beyond published content — yes, and depending on your jurisdiction, notification may be a legal requirement with a deadline. Even where it isn't required, telling affected users promptly and advising them to change reused passwords is the right call, and handles far better than the disclosure surfacing later.

How do I stop my WordPress site from being hacked again?

Patch the entry point before going live, or the same automated scan will find you again. Update core, plugins, and themes; delete unused plugins and themes entirely; enforce strong passwords and 2FA; disable dashboard file editing and PHP execution in uploads; keep PHP on a supported version; and add file-change monitoring so any future intrusion is caught in days. Then make sure at least one backup lives offsite, outside the hosting account — so if it happens anyway, recovery is a restore rather than a rebuild.

Are host backups enough to recover from a hack?

Often not. Host-side backups sit on the same infrastructure as the live site and are tied to the account's status — if the host suspends the account for malware or outbound spam, those backups can become unreachable exactly when you need them. Retention windows are also frequently shorter than the time a compromise goes undetected. Host backups are useful for routine mistakes; an independent offsite copy is what covers account-level failures.

The Bottom Line

Restoring a hacked WordPress site is a procedure, not a crisis — provided one condition holds: you have a clean backup the attacker never had access to. Everything else in this guide is sequence and discipline. Take the site offline, preserve the evidence, rotate credentials, date the compromise, wipe rather than overwrite, restore files and data from before the intrusion, rebuild code from official sources, patch the entry point, verify, and only then go live.

The condition that makes it all work is decided long before the incident. A backup stored inside the account being attacked shares the account's fate — it can be infected, deleted, encrypted, or locked behind a suspension. A backup pulled over SSH to independent offsite storage, with no plugin installed on the site and a restore you can trigger in one click, is what turns a hack from an existential problem into an afternoon's work. If you're a freelancer or agency responsible for client sites, that difference is the whole job.