Website Backup & Restore
Website Down After Restoring Backup
Last reviewed
Direct answer
A site that goes down right after a restore almost always means the database and files are now out of sync — wrong wp-config.php credentials for the restored database, only one half of the backup was actually restored, or siteurl/home still points at the wrong environment — so check the database connection and URL settings before assuming the backup itself was bad.
Restoring a backup feels like it should be a clean rollback, but WordPress needs its files, its database, and wp-config.php's credentials to all agree at once. If a restore tool only handled one half, restored to a different host, or left the old site URL in place, the result looks like a fresh, unrelated failure — a blank screen, a database connection error, or a redirect loop — even though the backup archive itself was fine. This guide walks the restore in the same order WordPress needs it, so you find the mismatch instead of restoring again and getting the same result.
Key facts
Verifiable numbers and definitions — each claim links to its source.
- WordPress backup guidance covers restoring both files and the database so a partial restore does not leave the site half-working. (WordPress backups)
- wp-config.php holds database credentials and site constants that must match the restored environment. (Editing wp-config.php)
- WP-CLI's wp db import loads a SQL dump into the configured database for restore workflows. (wp db import)
What the error means
A full restore has three pieces that must match: the WordPress files (core, themes, plugins, wp-content/uploads, wp-config.php), the database (all wp_* tables with a consistent table prefix), and the URLs stored inside that database (siteurl and home in wp_options, plus any hardcoded links in post content or serialized plugin settings). Restoring files without the database — or the database without matching files — produces errors that look database-related ("Error establishing a database connection") or content-related (missing plugins, "no styling") depending on which half is stale. Restoring onto a different host means wp-config.php almost certainly has the old database name, user, password, or host value, since those are rarely portable between hosting accounts. And restoring a database that still contains the old domain's URLs onto a new domain will load fine locally but redirect visitors back to wherever siteurl points. None of this means the backup was corrupt — it means the restore did not finish reconnecting every piece, and the fix is to methodically verify each one rather than repeating the same restore.
Common symptoms
- Site showed "Error establishing a database connection" immediately after the restore completed
- White screen or "There has been a critical error on this website" right after restoring
- wp-admin login loops back to the login page, or shows a "cookies are blocked" message
- Homepage loads but CSS, images, or fonts are broken and return 404
- Site appears to load, but visiting the real domain redirects to the old host, a staging URL, or a parking page
- Plugins or a theme that were active before the restore now show as inactive or "not installed"
- Browser shows mixed content or "Not secure" warnings that were not present before the restore
- Content is frozen at the backup's date, which is expected, but combined with broken functionality suggests only a partial restore
Most likely causes
- 01 wp-config.php database credentials (DB_HOST, DB_NAME, DB_USER, DB_PASSWORD) do not match the database that was actually restored
- 02 Only the files or only the database were restored, not both, leaving WordPress core out of sync with its content
- 03 siteurl and home in wp_options still reference the old domain, host, or a staging/temporary URL
- 04 Database table prefix in wp-config.php ($table_prefix) does not match the prefix of the restored tables
- 05 Restored files are incomplete — missing plugins, mu-plugins, or the wp-content/uploads folder
- 06 File ownership or permissions are wrong after restore, so PHP cannot read wp-content or wp-config.php
- 07 The restore landed on a different PHP version than the backup was taken on, and a plugin or theme is incompatible
- 08 The database import was interrupted partway through, leaving some tables missing or truncated
What changed before the problem started
- Backup restored to a different host, server, or hosting account than it was taken from
- A migration or restore plugin handled files and database as separate steps, and one step was skipped or failed silently
- wp-config.php was regenerated or manually edited during the restore instead of being restored as-is
- PHP version on the restore target differs from the version the backup was created under
- Database was restored from a dump taken mid-backup or from an unverified/older archive
Troubleshooting steps
- 01
Confirm the database credentials actually match the restored database
In the hosting panel, check the real database name, username, password, and host (often localhost) for the restored database, then compare every value against wp-config.php exactly. A single mismatched character here produces "Error establishing a database connection." Success signal: a direct phpMyAdmin login with those same credentials succeeds.
- 02
Verify both files and database were restored, not just one
Check that wp-content/plugins, wp-content/themes, and wp-content/uploads are present and populated on the file system, and separately confirm in phpMyAdmin that wp_posts, wp_options, and other core tables have rows and reasonable row counts. Success signal: file listing and table row counts both look complete, not empty or default-install-sized.
- 03
Check siteurl and home against the domain you are actually using
In phpMyAdmin, open wp_options and check the siteurl and home rows. If they show the wrong domain, old host, or a staging URL, update them to match where the site is now being accessed — a temporary URL first if DNS has not moved yet.
- 04
Confirm the table prefix in wp-config.php matches the restored tables
If wp-config.php says $table_prefix = 'wp_'; but the restored tables use a different prefix (common after restoring into a database that already had tables), WordPress will behave as if it is not installed. Match the prefix to whatever the actual tables use.
- 05
Test on a temporary or staging URL before pointing the real domain at it
Use the host-provided temporary domain or a local hosts-file override to load the restored site without affecting live DNS. Fix database, URL, and file issues here first, then only update the real domain once the temp URL loads cleanly end to end.
- 06
Check file ownership and permissions after the restore
A restore performed by a different tool or user account can leave wp-content or wp-config.php owned by the wrong user, or with permissions PHP cannot read. Reset to the host's standard permissions (commonly 755 for directories, 644 for files) if you see permission-denied errors in the log.
When to stop troubleshooting
Stop and escalate if the restored database has tables missing entirely and you do not have a second verified backup to re-import from, if you cannot access the hosting panel or database credentials to compare against wp-config.php, if serialized content is widely corrupted from a bad find-replace, or if the site must be back online quickly and each fix attempt risks more downtime. Provide the restore method used, the exact error shown, and whether the temp URL loads before handing it off.
Information to collect before requesting help
- 01 Restore method used (plugin name, host one-click restore, manual file/database upload) and which steps it actually performed
- 02 Exact error message or blank-screen behavior immediately after the restore
- 03 Whether both files and database were restored, or only one
- 04 Database credentials in wp-config.php compared against the hosting panel (redact the password when sharing)
- 05 PHP error log excerpt from the time of the restore
- 06 Domain/URL used during restore versus the live production domain
- 07 Age and source of the backup — was it test-restored before, or is this the first attempt
- 08 Whether the restore was to the same hosting account/server or a different one
How a professional repairs the problem
We first confirm what the restore actually moved — files, database, or both — by comparing file listings and table row counts against expectations, then match wp-config.php credentials and table prefix to the real restored database. We correct siteurl/home and any leftover domain references with serialization-safe tools, never raw SQL replace, and validate everything on a temporary URL before touching live DNS. Where the database import itself was incomplete or a table is corrupted, we re-import from a verified clean dump and repair affected tables. Once the site loads fully on the temp URL, we regenerate permalinks, check PHP/plugin compatibility, and only then coordinate the switch to the live domain.
Frequently asked questions
Why does restoring the exact same backup twice not fix it? +
Is "Error establishing a database connection" proof the backup is corrupt? +
Why do images and CSS break even though pages load? +
Should I update DNS before confirming the restore worked? +
Do I need to change the database table prefix manually? +
Can a partial restore corrupt my original backup file? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.