WordPress Recovery: Restore Pages + Fix Hacked Sites

WordPress Recovery Scenarios

Almost every WordPress recovery job falls into one of four buckets: a single page was deleted, the whole site was compromised, the database is damaged, or the hosting account itself failed. Each bucket has its own tools, its own order of operations, and its own clock. A single missing page is usually a half-hour job. A hacked site is measured in days, because you have to stop the bleeding before you rebuild anything.

Work out which bucket you are in before you install anything; the symptom tells you almost everything. If one URL 404s and the rest of the site is fine, you are in the first. If the home page renders but shows spam, injected links, or a login prompt you did not build, you are in the second. If every page throws a database error, you are in the third. If the domain stops resolving or the host has suspended the account, you are in the fourth, and nothing you do inside WordPress will change that.

Single page deleted. One URL 404s, everything else works. Start with the trash, then revisions, then archives.
Site compromised. You see content, redirects, or admin users you did not create. Take the site offline first, restore second.
Database damage. Errors like “Error establishing a database connection.” Repair the tables or restore the database dump, then rebuild from the files on disk.
Hosting failure. The domain resolves to a suspension notice or nothing. Only your host can fix this.

WordPress powers well over a third of the websites tracked by W3Techs, so the recovery tooling around it is mature and the failure modes are well documented. The hard part is choosing the right tool without destroying the evidence while you look for it. Before you change a setting, take a full copy of the database and the wp-content directory, because a mistaken overwrite is far more destructive than the problem you started with.

Restore a Single Deleted Page (3 Methods)

Work through these in order. Each one is faster and more complete than the one after it, and the first two cost nothing but a few minutes.

Trash bin. Log in to /wp-admin and go to Pages → Trash. WordPress moves deleted pages and posts to a trash state rather than destroying them immediately, and keeps them there for 30 days by default. Click Restore, then open the page on the front end to confirm the permalink. If 30 days is not enough margin, raise it before the next round of deletions by adding define( 'EMPTY_TRASH_DAYS', 90 ); to wp-config.php.
Revisions. WordPress stores a copy of the previous state each time it saves a post or a page, and how many it keeps is controlled in Settings → Writing. If you emptied the trash, the content frequently survives as a draft or as an earlier revision. Open the Pages list, find the entry, click Edit, and use the Revisions control in the editor sidebar to step backwards until you see the version you lost, then restore it. Restoring a revision does not bring back a page that was hard-deleted, which is why the trash check comes first.
Wayback Machine. If the page is genuinely gone and no local copy survives, the public archive is usually the last option that still holds the words. Open web.archive.org, enter the full page URL, and pick the snapshot closest to before the deletion. Our Wayback Machine guide covers the interface step by step. The short version is that you read the archived text, paste it into a new draft, and rebuild the layout, menus, and images by hand.

Method 3 is lossy, and it is worth being honest about that up front. The archive stores the rendered output a visitor saw, not your editor state, so custom fields, block settings, and styling are gone. What you get back is the text, the headings, the links, and the URL, which is what search engines and inbound links care about. For a service page or a post other sites link to, rebuilding it from an archive is usually worth the hour it takes.

Before rebuilding, check whether anyone else holds a copy. Search your inbox for the URL, ask whether it was shared in chat, and run a free crawler such as Screaming Frog in link mode to see who links to it. The content often also exists in a spreadsheet or an old PDF.

Restore a Full WordPress Site from Backup

A full restore only works if you have a backup you have never tested. The most common failure is not a missing backup; it is one taken after the site was already compromised, or a file that no longer downloads. Check the backup date, and check the state of the site on that date. Restoring a snapshot from last Tuesday will faithfully re-import last Tuesday’s hacked files and put you back where you started.

Log into your backup provider. If you run a backup plugin, the provider’s dashboard is where both the file backups and the database backups live. Download both. A site without its database is a folder of images with no posts in it.
Confirm the backup is complete and clean. Check the date, the file count, and that the archive actually contains wp-content/uploads. A backup that stops before your media folder is a partial backup, and you will discover that during the restore rather than before it.
Decide where the restore lands. The safest approach is a clean install in a scratch folder or on a staging subdomain, with the old database pointed at it. You get a working copy to compare against without putting the live site at risk. Once it looks right, point the live install at the restored database.
Use your host’s snapshots if you have no plugin backup. Most hosts keep daily or weekly server-side snapshots, sometimes self-service under a Backup or Snapshots heading in the control panel, and sometimes available only on request. If there is no self-service option, open a support ticket and give them the exact date and time you want restored so there is no ambiguity.
Re-point the domain and clear the caches. If you restored into a new folder, update the document root or the site address, then clear your caching plugin and the host’s page cache. Log in and visit Settings → General a second time so WordPress rewrites its internal URLs.
Rotate credentials afterwards. A restored database contains the old user table, and wp-config.php still holds the old security keys. Change every password and replace the salts before you reopen the site. Removing a malicious admin user is not enough if the attacker still holds your hosting password.

If the restore is part of a compromise cleanup rather than an accident, follow the order of operations in our step-by-step hacked-site recovery guide instead. Restoring first and cleaning afterwards is one of the most common reasons sites get reinfected within hours of coming back online.

If you have no backup at all, the realistic options are the archive route described below or rebuilding by hand. Content is recoverable; database settings and custom theme work generally are not.

Recover from a Hacked WordPress Site (10 Steps)

Take the site offline. Put it into maintenance mode using a plugin or your host’s control panel, or rename the wp-content folders so nothing renders. This stops visitors loading malware from your domain and stops the attacker re-installing their files while you work.
Change all credentials from a clean device. Hosting account, WordPress admin, FTP and SFTP, database user, the security keys in wp-config.php, and any reused passwords. Do this from a device that has never been used to log into the compromised site.
Preserve evidence before you clean. Make a full copy of the database and wp-content, and export the Site Health report from Tools → Site Health. Hosts and search engines are far more responsive when you can show them what happened.
Audit what actually changed. Check Settings → Users for admin accounts you do not recognise, scan the post list for injected content, check the modification dates on your plugin and theme folders, and look for stray PHP files in wp-content/uploads. Compare .htaccess and wp-config.php against a fresh install of the same version.
Restore from a known-clean backup, or rebuild. Restore files and database together into a clean directory. If no clean backup exists, the honest alternative is a fresh install of core, your theme, and a minimal plugin set, with content brought across from the archive.
Reconstruct the lost pages. Use the Wayback Machine to recover the text of any page that no longer exists, then rebuild it in the new install. This is the step people skip, which is why so many recovered sites end up with a working home page and nothing else.
Patch the way in. Work out how the attacker got in: an outdated plugin, an abandoned theme, weak FTP credentials, a leaked hosting password, or a nulled plugin from an unofficial source. Delete every plugin and theme you are not actively using. Unused code is attack surface that costs nothing to remove.
Install a security plugin and harden the server. A reputable firewall and malware scanner plugin gives you visibility you will want later. On the server side, run a current PHP version, lock down permissions on wp-config.php, serve everything over HTTPS, and enable two-factor authentication wherever the host offers it. Our security plugin comparison covers the WordPress options side by side.
Ask Google to re-evaluate the site. Sign in to Google Search Console, check Security and Manual Actions, and request a review once the site is genuinely clean. Submitting a sitemap at the same time helps you confirm the site is being crawled as you expect.
Watch for thirty days. Run scheduled scans, keep daily backups running, check the site on a real browser profile periodically, and watch for the reappearance of redirects you did not set. Compromised WordPress sites are frequently reinfected within weeks if the entry point was never closed.

If you cannot tell how far the attacker got, or the backups are unusable, that is the point to hand it to a specialist rather than improvise. Our site recovery service takes on the cases where the normal restore path has already failed, and it is cheaper than the weeks of unpaid work that follow a botched cleanup.

Use the Wayback Machine for WordPress Pages

The Wayback Machine is an unusually good backup source for WordPress specifically, because WordPress URLs are predictable. Depending on your permalink settings, posts live at /YYYY/MM/post-slug/, and pages keep a stable slug. That means you can enumerate a whole site rather than searching page by page.

Start with your own sitemap. WordPress generates one at example.com/wp-sitemap.xml on current versions, and most sites also publish a classic /sitemap_index.xml through their SEO plugin. If you know the slug, go straight to the archive and check whether that exact URL has a snapshot.

If you want every archived URL for a domain at once, use the CDX API, which returns a list of captures as JSON. This is the same endpoint covered in our Wayback Machine API tutorial, in more detail:

curl 'https://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&fl=timestamp,original,statuscode,mimetype&filter=statuscode:200&collapse=urlkey&limit=5000'

Narrow it to a section of the site and to a date range when you are hunting for the version closest to a specific deletion. The collapse=urlkey parameter gives you one row per URL instead of one row per capture, which is what you want for a site inventory:

curl 'https://web.archive.org/cdx/search/cdx?url=example.com/blog/*&from=2023&to=2024&output=json&fl=timestamp,original&filter=statuscode:200&collapse=urlkey'

Two practical warnings. Not every URL was ever captured, and some captures are only a redirect, a 404 page, or an empty shell, so filter on statuscode:200 and open a few before you assume a page is really there. And the archive stores what a visitor received, so images and stylesheets sometimes resolve and sometimes do not.

If you want the whole process rather than just the WordPress specifics, our step-by-step restoration guide covers recovering content from public archives for any kind of site.

Database Recovery with phpMyAdmin

If your database tables are damaged, you can often repair them without a full site restore. First find the table prefix, because it is frequently not the default wp_ — check the $table_prefix line in wp-config.php. Using the wrong prefix is the most common reason a recovery query appears to do nothing.

Before you touch anything, export the current database from phpMyAdmin so you have a copy of the broken state. Then select the WordPress database, tick every table, and choose Repair table. This fixes most crashes caused by an interrupted write, a full disk, or a server killed mid-query.

If the site throws “Error establishing a database connection” and repair does not help, the cause is usually one of three things: the database was emptied, the credentials in wp-config.php no longer match the host’s record, or the database is over its size quota. Check the host’s database panel first, because credential mismatches are far more common than corruption.

To recover content that was hard-deleted but whose rows still exist, query the posts table directly. Set post_status to trash to find recently trashed content, or change it back to publish to bring a page back. Replace wp_ with your real prefix:

SELECT ID, post_title, post_status, post_date
FROM wp_posts
WHERE post_type = 'page'
ORDER BY post_date DESC;

UPDATE wp_posts SET post_status = 'publish' WHERE ID = 1234;

If you have SSH access and your host supports WP-CLI, the same jobs are quicker and less error-prone from the command line:

wp db export backup.sql
wp db import backup.sql
wp search-replace 'https://old.example.com' 'https://example.com' --all-tables
wp core verify-checksums

That last command compares your core files against the checksums published by WordPress, which is the fastest way to confirm that nobody edited WordPress itself. For recovering individual deleted rows, a recent database export is the only realistic source. If you do not have one, the archived version of the page in the Wayback Machine is where you get the content instead.

Best WordPress Recovery Plugins (Compared)

Four tools cover almost every case. Prices and storage allowances change often, so treat the descriptions below as what each one is for rather than as a price list, and confirm details on the vendor’s site before you buy.

UpdraftPlus — the sensible default. A free core handles scheduled backups to a remote destination such as Google Drive, Dropbox, or S3-compatible storage; a paid premium add-on adds more destinations, file-level restore, and encryption. The one-click restore is genuinely one click, which is what you want at two in the morning.
BlogVault — a paid, managed service that takes continuous incremental backups off-site. Worth it for e-commerce sites or busy publications where the gap between scheduled backups and an incident matters.
Jetpack Backup — bundled into a Jetpack subscription rather than sold as a standalone plugin. Sensible if you already use Jetpack; the storage allowance depends on your plan.
BackupBuddy — a paid plugin from the same company behind iThemes, licensed per site or for multiple client sites. Popular with developers who manage a portfolio of builds under one purchase.
Your host’s built-in backups — not a plugin, and easy to overlook. Shared hosts commonly include daily snapshots with the plan, sometimes stored on the same server, which will not save you from a compromised host account. Use them as a second layer, not the only one.

Most sites should start with the free option above and only move up when it fails them. The deciding question is not how many features a plugin has, it is whether you can restore from it. Set up the backup, then try restoring into a scratch folder: a backup you have never restored from is a hope, not a plan. Test the restore each quarter, and check the file listing when a backup completes, because a silently failing backup looks exactly like a successful one.

FAQ: WordPress Recovery

How do I restore a WordPress page that was deleted months ago?

After a few months the trash is empty and revisions have usually been pruned, so your realistic sources are an external archive or a copy someone else made. Search the exact page URL on web.archive.org and pick the snapshot captured closest to before the deletion date, because later ones may already show a 404 page. Save the text, then rebuild the page in a new draft: the archive gives you the wording, headings, and links, but not your block settings, custom fields, or styling. Before you rebuild from scratch, check your inbox, your chat history, and any old exports for a cleaner copy. If other sites link to that URL, recreating it at the same address matters more than making it look identical, so keep the slug exactly as it was.

Can I recover a WordPress site without a backup?

Partly, and it helps to separate content from configuration. Page and post text can usually be reconstructed from the Wayback Machine, and if the files are still on disk you can recover uploads, your theme, and your plugins. What you generally cannot recover without a database backup is your settings, menus, widget layout, custom field values, and any site-specific code. If your host keeps server-side snapshots, ask for the last clean date first, because that is by far the fastest route. Otherwise a staged rebuild on a clean install is the standard approach: reinstall core, add the theme and a minimal plugin set, then import the recovered content one page at a time.

What’s the fastest WordPress recovery plugin?

For most sites, UpdraftPlus is the fastest path because it is free to start, familiar to most hosts, and restores in one click. Install it, schedule daily backups to a remote destination you control rather than the same server, and keep a copy in a second location. The speed advantage is real, but only if a restore has been tested. Install the plugin, take a backup, and try restoring it into a scratch folder before you need it. If you run a high-traffic or e-commerce site where the window between the last backup and the incident matters, a managed continuous backup service such as BlogVault is the better answer.