How to Restore a WordPress Site Safely (2026 Guide)

Last Updated September 6, 2026

Restoring a WordPress site means returning some or all of its files and database to an earlier working state. The safest method depends on what failed, what your backup contains, and what changed after the restore point. A broken plugin update, deleted page, compromised site, and failed migration should not all be handled the same way.

Quick Answer: If your host or backup service offers a tested one-click restore, use the newest clean restore point from before the problem began. First record what happened, create a copy of the current site when possible, and protect any new orders, form entries, comments, or content created after that restore point. On eligible WordPress.com plans, open the site’s Activity Log or Backup area, select the appropriate event or date, review what will be replaced, and start the restore. A manual restore normally requires a matching database and file set; a database alone will not restore uploaded media, themes, or plugins.

This guide explains how to choose a restore point, use a managed backup, recover through a hosting panel, restore files and a database manually, handle a database-only backup, and verify the site before returning it to normal use.

First: Decide What Actually Needs to Be Restored

A full rollback is not always the best first move. It can erase legitimate changes made after the backup. Start by identifying the scope of the problem.

Problem	Lowest-risk first option	When a full restore makes sense
One page or post was changed	Restore a WordPress revision	Rarely
Plugin or theme update broke the site	Deactivate or roll back the affected component	When the change damaged multiple files or the database
Site is showing a fatal error	Use recovery mode, hosting tools, or disable the suspected plugin	When targeted recovery fails
Files were deleted or corrupted	Restore the affected files	When the scope is unknown or widespread
Database content was deleted	Restore the relevant database or backup point	When selective recovery is unavailable
Site may be hacked	Preserve evidence and involve the host or security specialist	Only from a verified clean backup, followed by remediation
Migration failed	Keep the original site live and repair staging	When the destination must be returned to its previous state

For a single damaged page, WordPress revisions may be enough. The official WordPress revisions guide explains how to compare saved versions and restore one without rolling back the entire site.

Before Restoring: Protect the Current State

A backup restore is a write operation. It can overwrite files, database tables, settings, users, orders, and content. Before starting:

Write down the error, affected URLs, and the approximate time the problem began.
Confirm the backup date, time zone, retention period, and included components.
Create a current backup or server snapshot if the site is accessible.
Export recent orders, customers, form submissions, comments, and new content when relevant.
Place a store or membership site in an appropriate maintenance state so new transactions do not arrive during recovery.
Record DNS, CDN, PHP, database, and caching settings that may not be part of the backup.
Use staging first when the restore method allows it.

If the site may be compromised, keep a copy of the damaged state for investigation. WordPress’s guidance for a hacked site recommends preserving a snapshot even when it contains the infection. A clean-looking rollback does not prove that the original vulnerability, stolen credential, or hidden persistence has been removed.

Understand What a WordPress Backup Contains

A working WordPress site combines a database with files. The database typically contains posts, pages, settings, users, comments, product records, and plugin data. The files include themes, plugins, uploads, and configuration files. WordPress core can usually be downloaded again, but your uploads and customized code may be irreplaceable.

The official WordPress backup documentation recommends treating the files and database created around the same time as one backup set. Restoring a database from Tuesday with uploads from Friday can produce missing media, mismatched plugin data, or a site that appears functional until a specific feature is used.

Backup type	Usually contains	Does not necessarily contain
Full managed backup	Database plus covered WordPress files	DNS, external email, third-party platforms, or excluded directories
Database export	WordPress tables and stored content	Uploads, themes, plugins, and other files
Files-only copy	WordPress directories and configuration files	Posts, users, settings, orders, and other database data
WordPress content export	Portable posts, pages, taxonomies, and references	A complete site, theme design, plugin setup, or guaranteed media copy
Server snapshot	A wider hosting state at a point in time	External services and changes outside that server

Method 1: Restore Through Your Host or Backup Service

A managed restore is generally the simplest option because the provider knows its own storage, database, permissions, and server configuration. The exact buttons and coverage vary, so read the restore summary rather than assuming “one click” means risk-free.

Open the host or backup dashboard and locate backups or the activity log.
Select a point from before the failure began, leaving enough margin for the triggering event.
Review whether the restore includes the database, uploads, themes, plugins, or only selected components.
Protect changes made after that point.
Start the restore and let it finish. Do not close, repeat, or interrupt it unless the provider explicitly says that is safe.
Clear caches and complete the verification checklist later in this guide.

Restoring With Jetpack VaultPress Backup

Jetpack’s current documentation allows restores from Cloud.Jetpack.com or the WordPress.com dashboard, using a date, event, or selected files. Its restore guide also warns that a normal restore replaces the site database with the database from the chosen backup. New posts, pages, and other database content can therefore be lost unless preserved first.

Jetpack can also restore selected files or let you exclude files. If the site is completely down, a manual workflow or server credentials may be required. Our Jetpack Security review explains when its backup bundle fills a real gap and when your host may already cover the same need.

WordPress.com and Other Managed Hosts

Backup access and retention depend on the platform and plan. On WordPress.com, eligible sites can restore from the Activity Log or backup interface. On other managed hosts, the restore may live in the hosting control panel. Confirm whether a restore point covers the production environment, staging environment, database, and files. If the site is a WooCommerce store, ask specifically how the provider handles orders placed after the chosen restore point.

Managed hosting can simplify recovery, but it does not eliminate your responsibility to verify the result. Our Pressable hosting review discusses the value of backups, staging, and WordPress-focused support as part of the wider hosting decision.

Method 2: Restore a WordPress Site Through cPanel

cPanel is a hosting control panel, not a universal WordPress restore system. The available backup tools depend on the host. Some hosts expose a full account restore; others give you File Manager and phpMyAdmin but require support to restore server backups.

If your provider offers a supported restore tool, use its documentation. For a manual cPanel restore, the broad sequence is:

Confirm the destination directory and database. Do not overwrite the wrong site.
Back up the current files and database.
Upload and extract the matching WordPress file backup into the correct document root.
Create or empty the intended database only when the restore instructions require it.
Import the matching SQL backup through phpMyAdmin or a host-supported database tool.
Confirm that wp-config.php contains the correct database name, user, password, host, and table prefix.
Verify the site URL, permalinks, HTTPS, file permissions, and caches.

Do not treat those steps as a reason to improvise on a live site. Interfaces and limits differ, and large database imports may time out. Hosting support can often perform the server-level restore more safely.

Method 3: Restore Files and a Database Manually

A manual restore is appropriate when one-click recovery is unavailable, you are changing hosts, or you need control over individual components. You will normally need SFTP or SSH access, database credentials, and a compatible backup set.

1. Prepare a Clean Destination

Confirm the domain, document root, PHP version, database version, storage space, and HTTPS setup. If restoring to a different domain, plan a serialized-data-safe URL replacement after import. Keep the original site or backup untouched until the destination is verified.

2. Restore the WordPress Files

Upload the backup using SFTP, SSH, or the host’s file manager. Preserve wp-content, uploads, custom themes, must-use plugins, and configuration files according to the backup provider’s instructions. The WordPress handbook’s file-backup guide explains which directories hold your site-specific assets.

3. Restore the Database

Import the SQL dump into the intended MySQL or MariaDB database. A fresh destination is usually easier to reason about than mixing restored tables with an unknown existing state. Confirm the table prefix and credentials before connecting WordPress to it. Use the host’s import tool or command-line method for large backups.

4. Reconnect and Test

Update wp-config.php only when the database credentials or environment changed. If the domain changed, update the home and site URL using a method that preserves serialized data. Then regenerate permalinks, clear caches, and test while the site is still private or in maintenance mode.

What If You Only Have a Database Backup?

A database-only backup can recover valuable content and settings, but it is not a complete site. It normally does not contain uploaded images, plugin code, theme files, or custom server configuration.

Install a compatible WordPress environment.
Import the database into an empty destination database.
Connect WordPress with the correct credentials and table prefix.
Install clean copies of the required theme and plugins from trusted sources.
Recover the matching uploads directory from the host, archive, local computer, or another authorized source if available.
Test plugin data carefully; a database created by a newer or older plugin version may require a migration.

Do not promise a pixel-perfect recovery from an SQL file alone. The database may contain attachment records, but those records are not the image files themselves. A theme’s settings also cannot recreate theme code that is missing.

Restoring a Hacked WordPress Site

A hacked site is an incident-response problem, not just a rollback problem. Restoring a clean backup may remove visible damage, but the attacker can return if the entry point remains open.

Preserve the compromised state and logs when possible.
Confirm that the restore point predates the compromise—not merely the date you noticed it.
Rotate WordPress, hosting, database, SFTP, email, and relevant API credentials.
Replace WordPress core and extension files with trusted copies where appropriate.
Patch the vulnerable plugin, theme, credential, or server configuration.
Review administrators, scheduled tasks, must-use plugins, uploads, and database content.
Scan and monitor after the site returns to service.

Our WordPress malware-scanning guide covers the difference between a useful scan and proof of complete cleanup. For a revenue-producing or sensitive site, involve the host or a qualified incident-response specialist rather than deleting files based on guesswork.

Post-Restore Verification Checklist

A homepage that loads is not enough. Test the functions the site exists to perform.

Homepage, representative posts, service pages, archives, and 404 page
Administrator and regular-user logins
Contact, booking, newsletter, search, and account forms
WooCommerce product, cart, checkout, payment, tax, shipping, email, and order records
Images, PDFs, downloads, fonts, menus, and responsive layouts
Permalinks, redirects, canonicals, sitemap, and robots directives
HTTPS and mixed-content warnings; use our WordPress HTTPS troubleshooting guide if the secure version loads incomplete assets
Scheduled tasks, backups, security scans, CDN, caching, analytics, and Search Console verification
Recent content and transactions that may need to be reintroduced

Keep the current backup until the restored site has remained stable through normal use. Document the restore point, method, files, database, settings changed, and anything manually re-created.

Common Restore Problems

Symptom	Likely cause	Next check
Error establishing a database connection	Incorrect credentials, database host, permissions, or missing tables	`wp-config.php` and database user privileges
White screen or fatal error	Plugin, theme, PHP, or incomplete file mismatch	Error log and extension compatibility
Homepage works but inner pages return 404	Permalink or rewrite rules	Resave permalinks and review server rules
Images are missing	Uploads were not restored or URLs changed	`wp-content/uploads` and media URLs
Redirect loop	Conflicting site URL, HTTPS, CDN, or proxy settings	Home/site URL and redirect layers
Old version still appears	Browser, plugin, server, or CDN cache	Clear each cache deliberately
Users or orders are missing	Restore point predates the records	Preserved export, newer backup, or transaction records

How to Make the Next Restore Easier

Keep backups off the same server as the live site.
Match backup frequency to the amount of data you can afford to lose.
Retain more than one restore point.
Test restores on staging; a backup is not proven until it can be recovered.
Document who receives alerts and who can access the backup if the main administrator is unavailable.
Record external dependencies such as DNS, email, payment processors, forms, licenses, and API keys separately.

Frequently Asked Questions

Can I restore WordPress without dashboard access?

Yes. Depending on the backup system, you may restore through the host, Jetpack Cloud, cPanel, SFTP, SSH, or a database tool. Use the provider’s supported method and confirm that you are working on the correct site and database.

How long does a WordPress restore take?

There is no reliable universal time. Site size, file count, database size, server resources, connection speed, backup provider, and validation work all matter. A dashboard restore may be quick, while a large store or manual incident recovery can take much longer.

Will restoring WordPress delete recent changes?

It can. A full database restore generally returns database content to the selected point. Protect recent orders, posts, users, submissions, and settings before starting, and confirm whether your provider offers a more selective restore.

Can I restore only one page?

Often, yes. Try WordPress revisions first. Some backup products also support granular database or file recovery, but restoring one database table is more technical and can create relationships with missing data.

Is a database backup enough to restore WordPress?

It is enough to recover database content, but not a complete site. You still need compatible WordPress files, themes, plugins, uploads, and configuration. Use matching files from the same backup period whenever possible.

Should I delete a hacked site before restoring it?

Not without preserving evidence, confirming the backup, and planning the clean destination. Deleting first can remove logs and your only recoverable copy. Work with the host or a security professional when the compromise is material or the clean point is uncertain.

Final Recommendation

Use the narrowest restore that safely fixes the problem. Preserve the current state, choose a backup from before the failure, understand exactly what will be overwritten, and validate the restored site beyond its homepage. Managed restore tools are usually the best starting point; manual files-and-database recovery is the fallback when those tools are unavailable or insufficient.

Get Help Restoring Your WordPress Site

Disclosure: AH Web Works may earn a commission if you purchase through an affiliate link, at no extra cost to you. Recommendations are based on fit, not commission.