WordPress Site Recovery: How To Restore a Broken or Hacked Site Safely

The scariest part of WordPress site recovery is the first decision after the site breaks.

Your site may show a critical error, redirect visitors, lose wp-admin access, or even load a blank page. The wrong fix can make things worse. A blind restore can delete new orders. Random file changes can destroy evidence after a hack.

Reinstalling WordPress can hide the real problem without recovering the site.

TLDR: Start your WordPress site recovery by backing up the broken site, identifying what failed, and avoiding a blind full restore until you know what data could be lost. Use Recovery Mode for fatal plugin/theme errors, a clean backup for safe rollback, host/manual recovery when wp-admin is down, and WPRemote to make future restores faster and safer.

The safe pattern is simple: preserve the broken site, find the cause, then use the smallest clean fix that solves it.

This guide is for self-hosted WordPress sites where you control hosting, files, and the database. If your problem is a WordPress.com login, account, or ownership issue, use WordPress.com’s account recovery process instead.

Stabilize the site

Your first job is to keep your options open. Do not start by deleting plugins, reinstalling WordPress, or clicking restore because someone in a forum said it worked for them.

A restore replaces current data with older data. That may fix the visible error and quietly erase the most valuable thing the site did today. Before rolling back the database, export whatever recent content or business data you can still reach.

Choose the least destructive recovery route

Treat the symptom as a clue. It does not always mean the whole site needs to be rolled back.

What you see	Safest route
Critical error after an update	Use Recovery Mode or disable the faulty plugin/theme. Do not restore the full database first.
wp-admin will not load	Use host tools, SFTP, File Manager, backup dashboard, or logs. Dashboard access is not the only access.
Redirects, spam pages, browser warnings, or unknown admins	Treat it as a hack. Contain, clean, rotate passwords, and verify any backup before restoring.
Failed update, broken layout, or bad edit	Roll back the changed part or restore a clean backup after saving recent data.
Missing files, database errors, or fresh install screen	Restore files and database together. Check database details and table prefix.
No usable backup	Salvage what remains from the host, old tools, staging copies, files, database tables, and public archives.

The important choice is not “restore or do not restore.” It is which restore path loses the least data and fixes the real problem.

Use Recovery Mode

Recovery Mode helps when WordPress hits a fatal error. A fatal error means WordPress stopped because a plugin, theme, code snippet, or PHP version conflict broke something it needed to run.

Recovery Mode is not a backup. It does not bring back deleted pages, repair a damaged database, or clean malware. It gives an admin a safer way into wp-admin so the broken part can be disabled or fixed.

Tip: Do not break a live site on purpose to test Recovery Mode. Test recovery drills on staging, which is a copy of the site used for safe testing.

Restore from backup when rollback is safe

A backup restore works best when the failure is ordinary breakage: a failed update, bad theme edit, migration mistake, deleted file, or change you can place in time.

Before you restore, check three things:

Use staging when you can. Restore there first, check the site, then move carefully to production. If one plugin update broke checkout, a selective rollback is usually safer than replacing the whole database.

For WooCommerce, booking, membership, and lead-heavy sites, daily backups may still be too old. A store can lose paid orders in a few hours. Real-time backups matter because they reduce the gap between the last safe restore point and the moment the site failed.

Warning: Do not restore a hacked site from an old backup unless you can verify the backup is clean. Otherwise you may put the same backdoor back online.

Recover when wp-admin is unavailable

Losing wp-admin feels like losing the site. Usually, you lost one entrance, not every entrance.

Use tools outside WordPress:

This is where outside-admin recovery matters. WPRemote Emergency Connector is useful when wp-admin is unreachable but you still need a way to connect, inspect, and recover the site. If every recovery path depends on wp-admin, the first serious crash can remove your main tool.

When a theme is part of the failure, the recovery goal is to make sure WordPress has a working default theme to fall back to.

Manually restore files and database

Manual restore is the hands-on route. Use it when dashboards are unavailable or when you need tight control over what gets replaced. You need both parts:

Use this order:

If WordPress shows the installation screen after a restore, it usually cannot see the expected database tables. Check the database name, import result, table prefix, and whether the backup included the full database. Manual restore can save a site. It can also break one quickly. If the site handles payments, personal data, subscriptions, or client business, restore on staging or get help before guessing in production.

Treat hacked-site recovery as a security incident

A hacked site is not just a broken site with worse symptoms. The job is to remove the infection, close the entry point, and prove the attacker cannot walk back in. Common signs include redirects, browser warnings, Google warnings, host suspension, unknown admin users, spam pages in search results, strange files in uploads, or emails sent from your server.

The tricky part is timing. The redirect may appear today even if the weak password, vulnerable plugin, hidden admin user, or backdoor has been there for weeks.

That is why a backup is not automatically a cure. Use an old backup only if you can verify it is clean and old enough to predate the compromise. If the incident involved automated login attempts or spam injections, tighten WordPress bot protection before reopening the site.

Get professional help if customer data, payment data, repeated infection, multiple infected sites, host suspension, or legal reporting duties may be involved.

Recover without a backup

No-backup recovery is salvage, not a true restore. Some data may be gone. Start with sources that may still hold a copy:

Public archives can help rebuild what visitors saw. They cannot recover private orders, form entries, users, plugin settings, checkout data, or media that was never archived. After salvage, set up offsite backups before relaunch. A rebuilt site without a tested backup is still fragile.

Check the site before you call it recovered

The homepage loading once is a good sign. It is not the finish line.

Test the workflows that matter:

For a store, follow the money. For a lead site, follow the form. For a membership site, log in as a normal user. If the business flow fails, the site is not recovered.

WPRemote’s WordPress backups, monitoring, and emergency access are useful after this point because they turn recovery into a prepared workflow. They do not replace triage, but they make the next outage less dependent on memory and luck. A recovered site should be checked from the public side too, using real pages visitors rely on.

If restored URLs return 404s, the permalink settings screen is the common first repair checkpoint.

Prevent the next recovery crisis

Recovery is easier when the plan exists before the failure.

For a small brochure site, daily offsite backups and a careful update routine may be enough. For a revenue-generating site, recovery needs to be part of normal site operations.

Know when to get help

Some recovery work is reasonable for a careful site owner. Some is not worth learning during an outage. Get help when:

The practical test is simple: if the cost of guessing is higher than the cost of expertise, escalate.

FAQs

What should I do first when my WordPress site breaks?

Stop making changes and back up the broken site if you can. Then identify whether the problem is a fatal error, hack, failed update, missing file or database, or access problem.

How do I recover WordPress if I cannot access wp-admin?

Use tools outside WordPress, such as your host panel, backup dashboard, File Manager, SFTP, phpMyAdmin, server logs, SSH, WP-CLI, or an outside-admin recovery tool such as WPRemote Emergency Connector.

Should I restore a hacked WordPress site from backup?

Not as the first fix. The backup may already include malware, a backdoor, an unknown admin user, or infected database content. Clean the site, rotate passwords, patch the entry point, and restore only from a backup you can verify as clean.

When should I use WordPress Recovery Mode?

Use Recovery Mode for fatal errors caused by a plugin, theme, code snippet, or PHP conflict. It helps you enter wp-admin and disable the faulty part. It does not clean malware or restore deleted content.

Can I recover a WordPress site without a backup?

Sometimes, but usually only partly. Ask the host for snapshots, check old backup tools and staging copies, salvage remaining files or database tables, and use public archives to rebuild visible content.

Conclusion

WordPress site recovery starts with a calm first move: preserve what still exists before you replace anything. Once you know whether the issue is a fatal error, failed update, hacked site, missing database, or no-backup loss, the safer route becomes much clearer.

Do the smallest clean fix that solves the real problem, then verify the workflows that matter. A recovered site should load, take orders or leads, send emails, pass security checks, and have a tested backup path for the next emergency.