How to Reinstall WordPress Without Losing Your Content, Media, or Settings

Reinstalling WordPress does not have to erase your pages, posts, media, users, settings or search visibility. The safe version of the job replaces WordPress core while deliberately preserving the database, the wp-content directory and the configuration files that connect everything.

That distinction matters. Many rushed “reinstall” attempts are actually resets, fresh installations or hosting-account rebuilds. Those procedures can create empty databases, broken media paths, lost customizations and a second site competing with the original.

What a WordPress reinstall should—and should not—replace

A core reinstall replaces the standard files supplied by WordPress. It is useful when core files are incomplete, corrupted, modified, stuck after an update, or fail checksum verification. It does not need to replace your content database or the files that make the site uniquely yours.

• Preserve the database containing posts, pages, users, settings, comments and most plugin data.

• Preserve wp-content, including uploads, plugins, themes and any custom content directory.

• Preserve wp-config.php, which contains database credentials and site-specific constants.

• Preserve custom .htaccess rules, robots.txt and server configuration after reviewing them.

• Replace WordPress core directories and root core files with a clean, matching package.

If your goal is to erase the site, start over with an empty database or close the hosting account, that is not a core reinstall. Use Webcurry’s safe WordPress deletion guide to separate the website from the domain, email and backups before removing anything.

When reinstalling WordPress is the right fix

Reinstallation is appropriate when there is evidence that WordPress core is damaged. Typical signals include missing files, checksum mismatches, a failed core update, unexplained changes inside wp-admin or wp-includes, or an administrator screen that offers to reinstall the current release.

It is not the first fix for every critical error. A broken plugin, incompatible theme, exhausted PHP memory, database outage or bad custom snippet will remain broken after clean core files are installed. WordPress Recovery Mode and server logs may identify the real component faster.

Before touching core, write down the failure precisely: which URL fails, the exact message, when it started, whether the dashboard works, and what changed immediately beforehand. If the problem followed a version or plugin update, work through the WordPress update recovery checklist first.

Step 1: Confirm that the database and files belong to the same site

Shared hosting accounts often contain multiple WordPress installations, staging copies and databases. Open the live installation’s wp-config.php and record the database name, database host and table prefix. Match those values to the hosting panel before creating a backup or changing files.

Also confirm the WordPress version and locale. A manual or command-line reinstall should use the correct release package. Moving to a different major release at the same time turns a repair into an upgrade and introduces an additional variable.

Step 2: Build a recovery set before reinstalling

Create an offsite backup of both the database and the WordPress files. A file archive by itself does not contain the live MySQL or MariaDB database, while a database export does not contain uploads, themes, plugins or configuration files. A recoverable site needs both.

Download or snapshot the entire installation, including hidden files such as .htaccess. Export the database to a dated SQL or compressed dump. Keep the two parts together, record their creation time and store them outside the hosting account.

Open the archive, confirm that wp-content/uploads exists, and check that the database export is not empty. For a business-critical site, restore the set to an isolated staging environment. A successful backup notification is not proof that the files can be recovered.

If an existing archive will not restore, pause the reinstall and follow the WordPress backup restore diagnostic. Continuing without a verified recovery path makes a non-destructive repair unnecessarily risky.

Step 3: Diagnose before replacing anything

If WP-CLI is available, wp core verify-checksums compares installed core files with WordPress.org checksums for the detected version. Run it from the correct installation path and specify the correct version or locale when necessary. A failed checksum is evidence of a changed, missing or unexpected core file; it does not automatically prove malware.

Check PHP and web-server logs at the same time. An error naming a plugin or theme points away from core. If the site became slow after one extension was added, isolate that extension using Webcurry’s plugin performance diagnostic instead of reinstalling WordPress.

If the frontend works but wp-admin is slow, a core reinstall is also unlikely to solve scheduled jobs, slow database queries or external API calls. Use the slow WordPress admin troubleshooting guide to test those layers.

Method 1: Reinstall from Dashboard → Updates

This is the simplest method when the dashboard is accessible and the site is already on the desired WordPress version.

1. Put the site into a planned maintenance window and stop new orders or form submissions if consistency matters.

2. Go to Dashboard → Updates and confirm the displayed WordPress version.

3. Choose the option to reinstall the current version.

4. Wait for the download, verification, installation and database checks to finish.

5. Do not close the browser or interrupt PHP while files are being replaced.

6. Clear application, server, CDN and browser caches after the success message.

This process refreshes core files. It is not supposed to delete the database or wp-content, but the backup is still essential because filesystem permissions, timeouts and low disk space can interrupt the operation.

Method 2: Reinstall core with WP-CLI

WP-CLI is efficient when the dashboard is unavailable but shell access works. First confirm the installation path and version. Then download the matching core package with overwrite enabled while skipping the default content bundle.

The important flags are --force, which overwrites existing core files, and --skip-content, which avoids downloading default themes and plugins into wp-content. Use the correct --path, --version and --locale for the installation. Do not copy a command from another server without resolving those values.

After replacement, run the database update command only if WordPress reports that the schema needs it. Then run core checksum verification again. A clean result confirms the standard core files match the official package; it does not validate plugins, themes, uploads or custom server files.

Method 3: Replace WordPress core manually

Use this method when automatic reinstalling fails and FTP, SFTP or a hosting file manager is available. Download WordPress only from WordPress.org and unpack it locally.

1. Deactivate plugins when the dashboard is available.

2. Keep wp-config.php, wp-content, custom .htaccess rules and any intentional robots.txt file.

3. Delete the existing wp-admin and wp-includes directories.

4. Upload fresh wp-admin and wp-includes directories from the official package.

5. Upload the fresh root core files, allowing them to replace their old versions.

6. Merge only the files inside the package’s wp-content directory if required; never replace or delete the existing wp-content directory.

7. Remove a stale .maintenance file if a failed update left the site stuck in maintenance mode.

8. Visit /wp-admin and complete the database upgrade only if WordPress requests it.

Do not preserve modified core files simply because they contain custom code. Core edits are overwritten by legitimate updates and are difficult to audit. Move required behavior into a child theme, custom plugin or properly managed configuration after the site is stable.

What can still go wrong after a clean reinstall

A successful file replacement can expose the original problem rather than solve it. If a plugin caused the fatal error, the error returns when plugins load. If the database credentials are wrong, clean core still cannot connect. If DNS points to another server, you may be repairing an installation visitors never reach.

• A blank site or critical error returns because a plugin, theme or custom code is incompatible.

• Media URLs break because wp-content/uploads was incomplete or permissions changed.

• Pretty links return 404 because rewrite rules or .htaccess need regeneration.

• Visitors still see the old error because a CDN, host cache or service worker serves stale content.

• The site loads on one hostname but not another because DNS or SSL configuration is separate from WordPress core.

• Malicious files return because the compromised credential, plugin or server account was never secured.

For stale content after a repair, use Webcurry’s website cache diagnosis rather than repeatedly reinstalling the same files.

Step 4: Verify the site like a customer

Do not stop at the homepage. Test a logged-out visit, administrator login, a recent post, an older post, images, search, contact forms, password reset, mobile navigation and any checkout or booking path. Check that scheduled jobs run and transactional email arrives.

Review the browser console, network requests, PHP logs and WordPress Site Health for new errors. Confirm the canonical URL, robots directives and XML sitemap did not change. A core reinstall should not create new URLs or alter search intent.

Run checksum verification once more, update vulnerable plugins and themes, rotate credentials if compromise was suspected, and remove unused administrator accounts. Delete temporary archives from public directories after storing the final recovery copy securely.

A safe reinstall checklist

• The exact live installation, database and table prefix are confirmed.

• A matched database-and-files backup is stored offsite and has been checked.

• The current WordPress version and locale are recorded.

• Logs and checksums indicate that core replacement is justified.

• wp-content, wp-config.php and intentional server rules are protected.

• Only an official matching WordPress package is used.

• The database is upgraded only when WordPress requests it.

• Caches are cleared after the replacement, not before the final backup.

• Forms, email, logins, media and revenue paths are tested.

• Checksums, logs, security credentials and monitoring are reviewed afterward.

Replace the core, not the identity of the site

The safest WordPress reinstall is narrow: replace known core files, preserve the content layer, and verify the same website still works at the same URLs. If the database or wp-content is removed, the job has crossed from reinstalling into rebuilding or restoring.

When the site handles orders, bookings, memberships or important leads, take the recovery copy and test it before touching production. If you need a second technical review of the installation, backup and repair plan, contact Webcurry before the maintenance window begins.