Repair WordPress Installation Without Losing Your Website Content!

If your WordPress website is no longer working as expected, you may need to repair its installation rather than delete the site and start again.

A failed update, corrupted file, malware, server failure, database error, or incompatible plugin can damage the WordPress core and cause symptoms such as a blank screen, critical errors, missing features, or an inaccessible dashboard.

The good news is that repair WordPress installation problems can often be fixed without losing your website data. Protect the site with a full backup first, then use the repair method that matches the issue.

Do not reset WordPress unless you mean to erase the site. Repair keeps your content and fixes the broken part. Reset removes the site state and can wipe the data you came here to save.

Match the symptom to the fix

A broken WordPress installation can look like one big failure, but the cause is usually narrower. Use the symptom to decide where to start.

Backup before repair

Take a complete backup before you change anything. A useful backup must include the database and the files. The database stores posts, pages, users, comments, orders, form entries, plugin settings, and many site options. The files store uploads, themes, plugins, custom code, and WordPress core files.

Backup the site even if it is already broken. That copy may still contain the content, uploads, settings, and clues you need if a repair attempt makes the problem worse. At minimum, preserve:

• Database
• wp-content
• wp-config.php
• Uploads folder
• Active theme and child theme
• Plugins folder
• Custom files
• Existing .htaccess file or server rules, if present

BlogVault is useful here because it can create a full backup before repair and gives you a restore point if the next step fails. If you already have a clean backup from before the issue, restoring it may be faster than manual repair.

Use a staging site when the live site is important to revenue or leads. Staging is a private copy where you can test repairs before changing the live site. This matters for ecommerce, membership, booking, course, donation, and lead-generation sites because a restore can roll back new orders, users, form entries, and settings.

Know what not to overwrite

WordPress has several parts, and they do different jobs.

• WordPress core files run WordPress itself.
• wp-content holds themes, plugins, uploads, languages, and site-specific files.
• wp-config.php connects WordPress to the database and stores key settings.
• The database holds most of your actual site content and settings.
• .htaccess controls some Apache server rules, including permalinks.

You can often replace WordPress core files safely. You should not overwrite wp-content, wp-config.php, or the database during a normal repair.

This is the main difference between repair and reinstall advice. A core reinstall can keep content. A blank reinstall or reset can delete content.

Clear cache and update with care

If the dashboard still opens, start with simple checks.

• Clear every cache that can show an old error: Clear your caching plugin, host cache, CDN cache, and browser cache. Cache may not be the cause, but it can keep showing the broken version after you fix the real issue; Airlift has a deeper guide on how to clear WordPress cache without deleting site content.
• Check what changed before updating everything: If the site broke after an update, do not update every plugin and theme at once on the live site. Update one part at a time on staging when possible.
• Reinstall WordPress from the dashboard if core files look suspect: Go to the Updates screen and reinstall the current WordPress version. This replaces WordPress core files. It does not fix damaged themes, bad plugins, malware, wrong database details, or server problems.

Disable plugins safely

Plugin conflicts are common, and this test is easy to reverse.

• Turn off every active plugin from the dashboard: Go to Plugins, select the active plugins, choose Deactivate, and apply the change.

• Check the site before turning plugins back on: If the site works now, one plugin or a plugin pair caused the issue.
• Reactivate plugins one at a time: Turn on one plugin, test the site, then continue. The plugin that brings the error back is the first suspect.

• Decide what to do with the bad plugin: Leave it disabled, roll it back, update it, replace it, or contact the developer.

If you cannot access the dashboard, use SFTP or your host file manager. Open the WordPress folder, go to wp-content/plugins, and rename the plugins folder to plugins-disabled. Check the site. If it loads, rename the folder back to plugins, then rename individual plugin folders one at a time until you find the problem.

Switch to a default theme

A theme can break the frontend, the editor, or the dashboard, especially after a PHP, WordPress, or plugin update.

• Switch themes from the dashboard when you can: Go to Appearance, open Themes, and activate a current default WordPress theme.

• Test the pages that were broken: Check the homepage, posts, pages, menus, editor, and login screen.
• Protect theme changes before replacing anything: If the problem disappears, your active theme or child theme is likely involved. Save notes on custom code, tracking scripts, template edits, and layout changes before you replace or update it.

Without dashboard access, go to wp-content/themes and rename the active theme folder. WordPress will try to use another installed theme. This works best when a default theme is already installed.

Fix database connection errors

The message error establishing a database connection does not mean WordPress core is broken. It means WordPress cannot connect to the database it expects. Check these first:

• Database name in wp-config.php
• Database username
• Database password
• Database host
• Database server status
• Database user permissions
• Table prefix
• Whether the database was imported after a migration

After migration, also check the site URL and home URL in the database. Wrong URLs can cause redirects login loops, and broken paths that look like a failed repair. If the database details are correct and the database server is running, then check for damaged tables.

Repair the database

Repair the WordPress database when errors point to damaged tables, missing tables, failed imports, crashes, or a broken site after a failed update or migration.

• Use your host repair tool when available: Many hosts and cPanel setups offer a MySQL database repair option. This is the simplest route for many site owners.
• Repair tables in phpMyAdmin when you have database access: Open phpMyAdmin, select the WordPress database, export a backup, select the affected tables, and choose the repair option.

• Use WordPress repair mode only for the repair window: Add the repair setting to wp-config.php, open the WordPress repair page, run the repair, then remove the setting right away. That repair page can be opened without logging in while the setting is active.

• Run WP-CLI repair when your host supports it: WP-CLI is a command-line tool for WordPress. If you have shell access, the database repair command can repair tables without opening the dashboard. Optimization is different from repair. Optimization can clean overhead in tables, but it is not the same as fixing damaged tables.

Regenerate permalinks and check .htaccess

If the homepage works but posts or pages show 404 errors, the issue may be permalink rules.

• Save permalinks from the dashboard: Go to Settings, open Permalinks, confirm the structure, and save changes. Then clear cache and test several URLs.

On Apache servers, saving permalinks can update .htaccess, which is a file Apache uses for rewrite rules and redirects. Before editing it by hand, download a copy. It may include redirects, security rules, cache rules, or host rules.

If you cannot see .htaccess, enable hidden files in your file manager or SFTP client.

nginx servers do not use .htaccess. If your site runs on nginx, rewrite rules live in server settings. Use your host’s supported controls or ask the host to fix the rule.

Fix file permissions

File permissions decide who can read, write, and run files on the server. Wrong permissions can cause 403 errors, failed uploads, failed updates, failed plugin installs, and WordPress asking for FTP details when it should not.

repair WordPress permissions when you see:

• 403 Forbidden
• Permission denied
• Upload failures
• Plugin or theme update failures
• Core update failures
• Problems after a migration

Do not set every file and folder to broad write access. That may make the error disappear for a moment, but it can open a security risk. Ask your host to reset file ownership and permissions if you are unsure. This is often safer than guessing, because correct values depend on the host setup.

Reinstall WordPress core files safely

Replace core files when plugins, themes, database details, cache, and permissions do not explain the issue, or when a failed update left WordPress files missing or changed.

• Verify core files first when WP-CLI is available: WP-CLI can compare your WordPress core files with official WordPress files for the same version. This is better than blind replacement because it can show which core files are missing or modified.
• Download a fresh WordPress copy from WordPress.org: Extract it on your computer.
• Protect the site-specific parts before upload: Do not upload the bundled wp-content folder over your site. Do not overwrite wp-config.php. Do not replace the database.
• Upload only the core replacement files: Upload the remaining WordPress files and folders into the existing WordPress install folder. Allow them to overwrite old core files.
• Test the site before changing anything else: Check the frontend, dashboard, media library, forms, and any key business flow.

Modified core files should not be treated as normal customization. Custom features belong in plugins, child themes, hooks, or snippets because WordPress core updates can overwrite core edits.

Treat malware as a separate problem

If the site redirects visitors, shows malware warnings, displays injected links, creates unknown admin users, sends spam, or breaks again after you replace files, stop treating it as a normal repair.

A core reinstall can replace infected core files, but it does not prove the site is clean. Malware can live in plugins, themes, uploads, database records, hidden files, scheduled tasks, rogue users, stolen passwords, or backdoors that reinfect the site.

A hacked-site repair should include a full malware scan, file and database cleanup, clean plugin and theme replacement, admin user review, password changes, backdoor checks, updates, firewall protection, and warning review if browsers or search engines flagged the site.

Restore when repair is riskier

Manual repair is best when the cause is narrow or when you must preserve new data. Restore is better when the site broke after a known update, a clean backup exists, no important new data will be lost, or the damage is too wide to trust manual edits.

Before restoring, check what will roll back. WooCommerce stores, membership, booking, course, and donation sites may lose orders, renewals, users, form entries, downloads, and account changes created after the backup.

Test after each repair

After every repair step, test the parts of the site that matter.

Check:

• Homepage
• Important posts and pages
• Dashboard login
• Media library
• Plugin and theme screens
• Forms
• Search
• Redirects
• Cache behavior
• Error logs
• Malware warnings, if relevant

For ecommerce, test cart, checkout, payment, account pages, email receipts, and order creation. For membership sites, test login, protected content, renewals, and account updates. If the site works, stop making unrelated changes. Record what fixed it, replace or update the faulty part, and take a new clean backup.

Prevent the next failure

Prevention is simple, but it needs to be consistent.

• Keep WordPress core, plugins, and themes updated.
• Test updates on staging.
• Remove plugins and themes you do not use.
• Use strong unique passwords for WordPress, hosting, database, and SFTP accounts.
• Keep reliable backups away from the production server.
• Use a backup plugin so backups run without manual work.
• Watch PHP errors, resource limits, and host alerts.
• Use security monitoring if the site has had malware or handles customer data.

A backup stored only on the same server may fail when the server fails or gets hacked. Keep offsite backups so restore is still possible when the host account is not healthy.

FAQs

Conclusion

A safe WordPress repair starts with a backup, not a guess. Once the current files and database are protected, the repair becomes easier to control: match the symptom to the likely cause, try reversible fixes first, and avoid overwriting wp-content, wp-config.php, or the database.

If the site is hacked, tied to live orders, or too damaged to diagnose, do not keep experimenting on production. Restore a clean backup when that is safer, test risky fixes on staging, and ask your host or a WordPress repair expert for help when server access, malware, or data loss is part of the problem.

Written by

Shivani M

Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.