How to Reset a WordPress Site to a Fresh Install (Safely)

A WordPress “fresh install” can mean three very different jobs: deleting content while keeping the installation, replacing the entire database, or rebuilding both the database and files. Choose the smallest scope that achieves your goal. A content reset is usually reversible only through a backup and leaves users, settings, plugins, and themes in place; a database reset removes every WordPress table; a full rebuild also requires deliberate file replacement or review.

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

Back up and verify both the database and the complete site files before running any destructive command. The procedures below use WP-CLI because its scope is explicit, but the same decisions apply when your host provides a control panel or database tool instead of SSH.

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Choose the reset scope before deleting anything

Write down what you want to keep and what must disappear. The word “reset” is often used for operations with radically different consequences.

In a multisite network, scope changes again. wp site empty can target one site with --url, while wp db reset destroys the shared database for the entire network. Do not use a database reset on a multisite unless you have planned the network reconstruction, not just one site.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Back up the database and files first

Neither a content wipe nor a database reset has an undo button. Recovery depends on having a usable backup, not merely on having clicked “backup” in a hosting panel.

Export the database

From the WordPress installation directory, create a SQL export before changing anything:

wp db export pre-reset.sql

Keep the export outside the live document root and download it. Open or otherwise validate the file so you know it is readable. For a high-stakes rebuild, restore it into a separate database or staging installation and confirm that it contains the expected tables and content; a file that cannot be imported is not a recovery plan.

Copy the complete site files

Save the entire document root or the equivalent host backup, including:

• wp-content, especially uploads, themes, plugins, and any must-use plugins;
• wp-config.php, with database name, user, password, host, salts, and table prefix;
• custom PHP, JavaScript, CSS, build artifacts, and deployment files;
• server-specific files such as .htaccess or host configuration snippets.

Download the archive and check that it can be opened. If the site may contain malware, preserve the original copy for investigation but do not blindly restore every file into the rebuilt site.

Record the installation details

• Confirm the document root and the URL at which WordPress is installed.
• Record whether this is single-site or multisite.
• Note the database name, table prefix, and the account that owns the files.
• List administrators, active plugins, active themes, custom tables, scheduled integrations, and external caches that must be recreated or deliberately discarded.

This inventory prevents a common mistake: resetting the database while forgetting that important data lives in a plugin-specific table or in files rather than in standard WordPress tables.

Reset content while keeping the installation

Use this path when you want an empty editorial site but intend to retain the current users, settings, themes, plugins, and plugin configuration. WP-CLI’s wp site empty truncates the standard content tables and flushes the object cache; it does not remove themes or plugins.

Empty posts, pages, comments, terms, and links

1. Change to the WordPress directory, or otherwise point WP-CLI at the correct installation.
2. Run:

wp site empty --yes

The confirmation switch is intentional: it authorizes the destructive operation without an interactive question. The command removes content records, including attachment records, but leaves the site configuration and user accounts in place.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

Remove uploaded media files too

If the new site must not retain the old media files, use:

wp site empty --uploads --yes

This adds the uploads directory cleanup to the content wipe. It does not remove arbitrary files elsewhere in wp-content, custom code, themes, plugins, or server files. Review those separately.

Target one site in a multisite network

Supply the URL of the intended site:

wp site empty --url=https://example.com/subsite --yes

Use the exact site URL configured by the network. A mistaken URL can select the wrong site, while omitting the target can cause the command to operate on the installation you are currently pointing at. Do not substitute this command for a network-wide database reset.

What this method does not reset

• WordPress options, including site configuration and plugin settings;
• all user accounts and their roles;
• installed and active themes and plugins;
• custom tables created by plugins or bespoke code;
• non-upload files in the document root or wp-content.

Those leftovers are intentional behavior, not evidence that the command failed. If the reason for the reset is malware or a compromised administrator, a content wipe is too narrow: credentials, executable files, and malicious options can remain.

Reset the database for a blank WordPress installation

Choose a database reset when every table in the current database must go and you are ready to run the standard installation process again. This is more destructive than deleting content because it removes users, options, plugin tables, and multisite tables together.

Export, then remove every table

With the backup completed and the credentials in wp-config.php confirmed, run:

wp db export pre-reset.sql
wp db reset --yes

wp db reset removes all tables from the database and recreates the database structure needed for a subsequent installation using the credentials in wp-config.php. It does not clean the filesystem. Any plugin, theme, upload, custom PHP file, malware, or old .htaccess remains on disk until you inspect or replace it.

Understand the boundary of the operation

• The database named in wp-config.php is the one affected; verify that value before pressing Enter.
• On a multisite, the shared database includes the network and all sites, so this operation is network-wide.
• Custom tables are removed along with standard WordPress tables; restoring only core tables will not restore application data.
• The SQL export is your recovery path. Do not assume a hosting snapshot or an untested dump will work when needed.

Install WordPress tables and the first administrator

After the database has been reset, ensure that the WordPress files and wp-config.php point to the intended database. Then run the standard installation command for a single site:

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

wp core install 
  --url=https://example.com 
  --title="New Site" 
  --admin_user=admin 
  [email protected] 
  --locale=en_US

The command creates the WordPress tables and the initial administrator. Replace the example URL, title, account name, email address, and locale with the values for the new site. If WordPress is installed in a subdirectory, include that path in --url; an installation at https://example.com/blog must not be initialized as the root URL.

Protect the administrator password

Do not put a real password directly in a command that will be saved in shell history or appear in process listings. Use WP-CLI’s documented prompt mechanism, such as --prompt=admin_password, or another secure secret-injection method provided by your environment. Use a unique, high-entropy password and plan to remove any temporary shell history that contains sensitive values.

Multisite caution

wp core install runs the standard single-site installation process. A multisite network requires its own network-install and domain/path decisions, so do not treat this command as a complete network recreation. Rebuild the network only after confirming the intended multisite architecture and database backup.

Rebuild the files for a genuinely fresh installation

A blank database with an old filesystem is not a fresh installation. The database reset leaves executable code and configuration files untouched. For a full rebuild, separate files you trust from files you merely happen to have.

Replace WordPress core

Use a fresh WordPress core package or the host’s supported clean-core deployment process. Do not copy unknown core files from the old site simply because their names look familiar. Preserve wp-config.php only after checking its database settings, salts, table prefix, and for unexpected code.

Review wp-content selectively

• Restore uploads only if they are needed and have been scanned or otherwise reviewed.
• Install fresh copies of themes and plugins from sources you trust rather than copying arbitrary old plugin directories.
• Reintroduce custom code one component at a time, documenting why each file is needed.
• Check must-use plugins, drop-ins, cache files, and writable directories, which can survive ordinary plugin cleanup.

Inspect server-level leftovers

Review .htaccess, web-server includes, cron jobs, deployment scripts, environment files, and any files outside the WordPress directory that route traffic to it. The exact delete-and-replace sequence varies by host, so follow that host’s file-management procedure rather than applying a generic recursive deletion command to a live server.

If compromise is a possibility, change database, hosting, SSH, SFTP, and administrator credentials after containment. Restoring an old credential set can give an attacker a route back into an otherwise clean database.

When you do not have SSH or WP-CLI

Many hosts provide a file manager, database interface, or one-click installer instead of shell access. The labels differ, but the safety rules do not.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

1. Use the host’s backup feature to export the database and download the files.
2. For a content-only reset, use a WordPress administration tool that explicitly says it removes content while preserving users and settings. Do not choose a tool labelled “uninstall” or “delete installation” unless that is your intended scope.
3. For a database reset, export first, then drop the WordPress tables in the database tool. Confirm the database name and table prefix so you do not affect another application sharing the account.
4. Use the host’s clean WordPress installer or upload a reviewed core package, then complete the initial administrator setup.

If a panel does not clearly state what it deletes, stop and obtain its documentation or support instructions. Ambiguous “reset” buttons are not equivalent to wp site empty or wp db reset.

Verify the new site before handing it back

Verification catches wrong URLs, stale files, and incomplete restores while the recovery path is still available.

• Open the front page and /wp-admin over the intended HTTPS URL.
• Sign in with the new administrator and confirm the account email and role.
• Check that the configured site URL and home URL use the correct domain, scheme, and subdirectory.
• Visit a sample page and test navigation, permalinks, forms, and any required API callbacks.
• Upload a small test image, view it, and confirm that its URL resolves.
• Review the plugin, theme, user, and media lists. A content reset should show the retained items; a database rebuild should show only what you intentionally installed.
• Inspect the filesystem for unapproved plugins, themes, PHP files, drop-ins, and server rules.
• Flush WordPress object cache after a content reset. If the site uses a persistent external page, object, CDN, or reverse-proxy cache, purge that cache through its provider as well.
• Check error logs and scheduled tasks before directing real traffic to the site.

Troubleshoot the common failure branches

WP-CLI says it cannot find WordPress

You are probably in the wrong directory or pointing at the wrong document root. Confirm the location of wp-config.php, run the command from that installation, and make sure the URL or path selects the intended site rather than a staging copy.

The database reset reports an access or connection error

Check the database name, host, username, password, and table prefix in wp-config.php. The database account must be allowed to remove tables. Do not keep retrying destructive commands until you know which database the credentials identify.

The old site appears after a database reset

A database reset does not delete files, and browser, object, or reverse-proxy caches can serve old output. Confirm that the new database is configured, inspect the remaining themes and plugins, and purge external caches. If old users or settings are present, you may have run a content reset rather than a database reset, or the web server may be serving another document root.

Pages return 404 errors

Verify the site URL and subdirectory first. Then refresh the permalink configuration through the new administration area and check server rewrite rules. A stale .htaccess or an incorrect web-root mapping can break otherwise valid WordPress routes.

Uploads or custom data are missing

If --uploads was used, the old upload files were intentionally removed. Restore them from the verified file backup only if they are trusted. Plugin data in custom tables is not part of the standard content reset and is destroyed by a database reset; recover it from the database export or reinstall the application and import its data using that plugin’s supported process.

The new administrator cannot sign in

Confirm that wp core install completed against the intended database, that the email and username were entered correctly, and that no security or must-use plugin restored from the old files is blocking authentication. If the site was meant to be multisite, stop and use the network installation process instead of repeatedly running a single-site install.

Which method should you use?

Use wp site empty when the installation itself is trustworthy and you only need new content. Use wp db reset followed by wp core install when you need a blank single-site database but intend to review or reuse the existing files. Choose a full rebuild when you need confidence that old code, malware, plugins, themes, and server configuration are not being carried forward. In every case, the complete database-and-files backup comes first, and the final verification determines whether the result is actually ready for use.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.